Dokument 1.pdf - Opus - Friedrich-Alexander-Universität Erlangen ...

Q.E.D.
-
Ein Entwurfsprozess für statistische Tests
mit Betrachtung von Zeit- und Leistungsanforderungen
Der Technischen Fakultät der
Universität Erlangen-Nürnberg
zur Erlangung des Grades
DOKTOR-INGENIEUR
vorgelegt von
Dipl.-Inf. Matthias Beyer
Erlangen – 2008

II
Als Dissertation genehmigt von
der Technischen Fakultät der
Universität Erlangen-Nürnberg
Tag der Einreichung: 09. Mai 2008
Tag der Promotion: 26. Juni 2008
Dekan: Prof. Dr.-Ing. habil. J. Huber
Berichterstatter: Prof. Dr.-Ing. R. German
Prof. Dr.-Ing. D. Kips

Inhaltsverzeichnis
1 Einleitung .................................................................................................................... 1
1.1 Ziele der Arbeit.................................................................................................... 2
1.2 Beiträge der Arbeit .............................................................................................. 2
1.3 Aufbau der Arbeit................................................................................................ 3
2 Softwaretest ................................................................................................................. 5
2.1 Einführung........................................................................................................... 5
2.2 Modellbasierter Test............................................................................................ 9
2.2.1 Sichten ......................................................................................................... 9
2.2.2 Szenarien ................................................................................................... 10
2.2.3 Modellarten................................................................................................ 11
2.2.4 Model Driven Architecture (MDA)........................................................... 14
2.3 Testing and Test Control Notation 3 ................................................................. 16
2.3.1 Historie ...................................................................................................... 16
2.3.2 Der TTCN-3 Standard ............................................................................... 18
2.3.3 Verteilter Test............................................................................................ 20
2.3.4 Testkonfiguration ...................................................................................... 21
2.3.5 TTCN-3 Module........................................................................................ 22
2.3.6 TTCN-3 Verhalten..................................................................................... 23
2.3.7 INRES-Beispiel ......................................................................................... 25
2.3.8 TTCN Echtzeit- und Leistungserweiterungen........................................... 32
3 Die Unified Modeling Language 2............................................................................ 35
3.1 Historie .............................................................................................................. 35
3.2 Metamodell........................................................................................................ 36
3.3 Infrastructure ..................................................................................................... 38
3.4 Superstructure.................................................................................................... 39
3.4.1 Diagrammtypen ......................................................................................... 40
3.5 XML Metadata Interchange (XMI) ................................................................... 42
3.6 Sequenzdiagramme............................................................................................ 44
3.7 UML Profile ...................................................................................................... 50
3.7.1 UML Profile for Schedulability, Performance and Time.......................... 50
3.7.2 UML Profile MARTE ............................................................................... 55
3.7.3 UML Testing Profile ................................................................................. 57
III

IV
4 Q.E.D. – Testentwurfsprozess................................................................................... 59
4.1 Szenarienbasierte Anforderungsspezifikation................................................... 61
4.1.1 Use-Case-Diagramm ................................................................................. 61
4.1.2 Leistungsanforderungen ............................................................................ 63
4.2 Markov Chain Usage Model ............................................................................. 65
4.2.1 Einführung................................................................................................. 65
4.2.2 Eigenschaften ............................................................................................ 66
4.2.3 Erstellung eines MCUMs .......................................................................... 69
4.2.4 Software-Zuverlässigkeit........................................................................... 80
4.3 Testfallgenerierung............................................................................................ 84
4.4 Erzeugung der Testsuite .................................................................................... 87
4.5 Zusammenfassung ............................................................................................. 91
5 Anwendungsstudie DECT......................................................................................... 93
6 Zusammenfassung ................................................................................................... 101
6.1 Ausblick........................................................................................................... 102
Abbildungsverzeichnis .................................................................................................... 103
Literatur ........................................................................................................................... 105

Kurzfassung
Software nimmt an Größe, Komplexität und Qualitätsanforderungen stetig zu. Diesen
Herausforderungen stellt sich die moderne Softwareentwicklung u.a. mit verbesserten
Programmierkonzepten, abstrakteren Programmiersprachen und systematischeren Entwicklungsprozessen.
In diesem Zusammenhang ist die steigende Popularität der modellbasierten
Softwareentwicklung zu verstehen, deren Stärken in einer meist visuellen abstrakten
Notation und in erweiterten Validierungsmöglichkeiten liegen. In den letzten Jahren
hat sich dieser Trend auf die Testphase ausgeweitet, um gleichermaßen systematisch
und automatisch Testfälle aus Modellen generieren zu können. Die UML stellt als Sprachenfamilie
den populärsten Vertreter aller Modellierungsnotationen dar.
Ziel dieser Arbeit ist die Konzeption eines systematischen Testentwurfprozesses auf Basis
einer Softwareentwicklung mit der UML2. Dieser soll verbreitete Sprachstandards verwenden
und relevante Zeit- und Leistungsaspekte berücksichtigen. Aussagekräftige Testergebnisse
sollen eine Entscheidung zur Systemfreigabe ermöglichen. Außerdem soll der
gesamte Prozess praxisgerecht sein, also insbesondere niedrige Einsatzvoraussetzungen
besitzen und leicht anzuwenden sein.
In der vorliegenden Arbeit wird der Q.E.D. („QoS Enhanced test Development“) genannte
Testentwurfsprozess vorgestellt. Dessen Ausgangslage stellen Anforderungsszenarien
dar, die in der UML2 definiert sind. Außerdem können diese standardkonform Zeit- und
Leistungsanforderungen beschreiben. Mittels einer - in dieser Arbeit diskutierten - Menge
von Transformationsregeln wird ein Testmodell erzeugt. Dem Modell werden Benutzungsprofile
hinzugefügt, um Testfälle statistisch nach angenommenem Nutzungsverhalten
zu generieren. Eine Folge ist die Abschätzbarkeit der erreichten Softwarezuverlässigkeit
aus Benutzersicht, einer geeigneten Größe zur Entscheidung der Systemfreigabe. Als
Zielsprache für die Testausführung wurde die TTCN-3 gewählt, da sie eine verbreitete
und die einzige standardisierte Testnotationssprache darstellt. Aufgrund der weitestgehenden
Automatisierbarkeit ist der Testentwurfsprozess außerdem leicht anzuwenden.
Im Rahmen dieser Arbeit wurden alle benötigten Teilschritte des Testentwurfsprozesses
prototypisch implementiert. Die entstandene Werkzeugkette konnte an einer realen Fallstudie
erprobt werden. Dazu stellte die Projektgruppe CCIOS des Fraunhofer Instituts für
Integrierte Schaltungen sechs DECT-Funkmodule M5 aus eigener Entwicklung zur Verfügung.
Damit konnte die praktische Einsatzfähigkeit des Q.E.D.-Ansatzes gezeigt werden.
V

Abstract
Software is continuously increasing in size, complexity and quality demands. Modern
software engineering faces up to these challenges amongst others with improved programming
concepts, programming languages with higher degrees of abstraction and more
systematic development processes. In this context, the growing popularity of model based
software engineering is reasonable, which has its strengths in mostly graphical and abstract
notations and in extended validation possibilities. In the last years this tendency
dilated to the testing phase, to generate test cases both systematically and automatically
from models. The UML, as a family of languages, is the most popular representative of
all modelling notations.
The aim of this thesis is the conceptual design of a systematic test development process
based on a software design with the UML2. It should apply common language standards
and account for relevant time and performance aspects. Significant test results should
facilitate the decision to release software. Furthermore the whole process ought to be
practice-oriented, in particular with low prerequisites and easy appliance.
This thesis introduces a test development process called Q.E.D. (“QoS Enhanced test
Development”). It starts with requirements defined as scenarios in the UML2. Moreover
they may include standard conforming time and performance requirements. By applying a
set of transformation rules - as discussed in this thesis - a test model can be created. User
profiles are added to the model to generate test cases statistically to the expected software
usage. A consequence is the ability to estimate the achieved software reliability from the
user perspective, an appropriate measurement for the decision towards a software release.
TTCN-3 is chosen as the target language for test execution, both because of its popularity
and because it’s the only standardized test notation language. Due to the possible high
degree of automation the whole test development process is easily applicable.
For this thesis all necessary partial steps of the test development process were prototypically
implemented. The emerged tool chain could be validated by appliance within a real
case study. Therein six wireless DECT modules M5, developed and provided by the project
group CCIOS from the Fraunhofer Institute for Integrated Circuits, could be used as
the system under test. The realized case study demonstrates the practical applicability of
the Q.E.D. approach.
VII

VIII
Einleitung

1 Einleitung
Die wachsende Technisierung weiter Lebensbereiche und der allgemeine technische Fortschritt
erzeugen eine stetig wachsende Anzahl an immer größeren technischen Systemen.
Die mit ihr einhergehende steigende Komplexität dieser Systeme erhöht den Bedarf an
systematischen Vorgehensweisen für jede Phase des Entwurfsprozesses.
Vor diesem Hintergrund halten seit Jahren Modellierungssprachen und modellgestützte
Techniken in der Softwareentwicklung Einzug. Visuelle Modelle behalten auch bei höherer
Komplexität ihre Verständlichkeit, formale Modelle bieten zudem automatische Analyse-
und Validierungsmöglichkeiten. Fortgeschrittene Techniken ermöglichen werkzeuggestützt
die automatisierte Generierung von Implementierungscode. Die Modellierungssprachen
SDL [ITU99] und MSC [ITU96] wurden aus diesen Gründen in den vergangenen
drei Jahrzehnten sehr erfolgreich im Bereich der Telekommunikation eingesetzt.
Mitte der 90er Jahre trat die UML [OMG07a] ihren Siegeszug als allgemeine Modellierungsnotation
in der Softwareentwicklung an. Ihre in der Sprachenarchitektur verankerte
Erweiterbarkeit ließ die Anwendungsbereiche und die Zahl der Anwender stetig wachsen.
Seit Verabschiedung der neuesten UML-Version, in der alle wichtigen Konzepte der SDL
und MSC übernommen wurden, nimmt auch die Telekommunikationsbranche die Sprache
besser an. Zudem lässt sich die UML auf Grund ihrer Diagrammvielfalt in allen Phasen
der Softwareentwicklung einsetzen.
Eine der zeitaufwändigsten Phasen dabei ist das Testen, die damit verbundenen Aktivitäten
nehmen in der Praxis bis zu 40 Prozent der gesamten Softwareentwicklung in Anspruch.
Die Anwendung moderner Methodiken und formaler Verifikationstechniken können
diesen Aufwand reduzieren, überflüssig wird das Testen jedoch nicht. Die bei der
Verifikation notwendigerweise getroffenen Annahmen über das reale System bzw. die
Umgebung müssen auf ihre Korrektheit hin überprüft, d.h. getestet werden.
Ein oft vernachlässigter Aspekt sowohl beim Entwurf wie auch beim Testen sind Zeit-
und Leistungsanforderungen, die häufig im gleichen Maße für die Kundenakzeptanz verantwortlich
sind. Dies betrifft sowohl das Einhalten einfacher zeitlicher Schranken als
auch von Größen pro Zeiteinheit.
1

2
1.1 Ziele der Arbeit
Einleitung
Zwischen den Vorgehensweisen bei der Systementwicklung in der akademischen und der
industriellen Welt existiert eine Diskrepanz, welche nur schwer aufzulösen ist. Auf der
einen Seite werden formale Sprachen und Techniken entwickelt, die mitunter beweisbare
Korrektheit ermöglichen. Auf der anderen Seite dominieren informelle Sprachen und
Implementierungscode, dessen einzige Überprüfung durch Debugging und (mehr oder
weniger) unsystematisches Testen erfolgt. Die erreichte Akzeptanz der (semi-formellen)
UML im industriellen Umfeld stellt eine Chance dar, beide Welten einander näher zu
bringen.
Das Ziel dieser Arbeit ist es, auf Basis eines Entwurfsprozesses in der UML2 einen verbesserten,
d.h. systematischen Testprozess zu entwickeln. Dabei sind nachfolgende Bedingungen
zu erfüllen: (1) Der Prozess soll existierende und verbreitete Sprachstandards
verwenden. (2) Die Testergebnisse sollen die Entscheidung zur Systemfreigabe erleichtern.
(3) Die Tests sollen relevante Zeit- und Leistungsaspekte berücksichtigen. (4) Der
gesamte Prozess soll praxisgerecht sein, d.h. insbesondere niedrige Einsatzvoraussetzungen
besitzen und leicht anzuwenden sein.
1.2 Beiträge der Arbeit
Diese Arbeit setzt auf Vorarbeiten des europäischen IST Projekts „Markov Test Logic“
(MaTeLo) auf, welches sich mit dem Einsatz von markowkettenbasierten Testmodellen
beschäftigt hat. So wird in [BD03, BD04, DZ03] ein ähnlicher Ansatz wie in dieser Arbeit
beschrieben.
Im Unterschied zum Q.E.D.-Entwurfsprozess war die betrachtete Notationssprache jedoch
eine andere, „Message Sequence Charts“ (MSC) anstelle der UML. Musste für die
Repräsentation des Testmodells eine neue, proprietäre Beschreibungssprache entwickelt
werden, wird in dieser Arbeit konsequent – von der Anforderungsspezifikation bis hin zur
Testsuite – die UML genutzt. Lediglich für die Testausführung muss diese Sprache insbesondere
aufgrund fehlender Werkzeugunterstützung verlassen werden. Der Prämisse zur
Verwendung existierender Standards folgend, erfolgt hier die Abbildung auf die „Testing
and Control Notation version 3“ (TTCN-3).
In Erweiterung zu „MaTeLo“ wird zudem der gesamte Sprachumfang der Sequenzdiagramme
betrachtet. Alle – laut Spezifikation erlaubten – Elemente werden für eine mögliche
Abbildung auf das Testmodell diskutiert, insbesondere auch komplexere Szenarien,
die durch Kombination einfacher Sequenzen entstehen können. Außerdem wird für ver-

Aufbau der Arbeit
schiedene Zeit- und Leistungsanforderungen aufgezeigt, wie sich diese von der Anforderungsdefinition
über das Testmodell auf eine Erweiterung der TTCN-3 abbilden lassen.
Bei der Testfallgenerierung wird sowohl auf die Sonderfälle von nichtdeterministischem
und parallelem Verhalten, als auch auf die Notwendigkeit der Synchronisierung verschiedener
Testkomponenten eingegangen.
1.3 Aufbau der Arbeit
Diese Arbeit gliedert sich in sechs Kapitel. Nach der Einleitung führt Kapitel 2 in das
Thema des Softwaretests ein, wobei die zwei Schwerpunkte bei den modellbasierten Verfahren
und der Testsprache „Testing and Test Control Notation version 3“ (TTCN-3)
liegen. Letztere stellt die Zielsprache im Q.E.D.-Testentwurfsprozess dar. Neben einer
Beschreibung der in ihr enthaltenen Konzepte und deren Erläuterung anhand eines kleinen
Beispiels schließt das Kapitel mit existierenden Spracherweiterungen ab.
Das Kapitel 3 widmet sich dem Thema der „Unified Modeling Language version 2“
(UML2), einer Modellierungssprache, die die Grundlage des Q.E.D.-Prozesses bildet.
Neben unterschiedlichen Aspekten dieser Sprache werden zum Abschluss des Kapitels
ebenfalls verschiedene Spracherweiterungen (sog. Profile) beleuchtet, die für diese Arbeit
von Bedeutung sind.
Im anschließenden Kapitel 4 wird der entwickelte Q.E.D.-Entwurfsprozess beschrieben.
Den Ausgangspunkt des Prozesses stellen szenarienbasierte Anforderungsdefinitionen
dar, folglich startet das Kapitel mit deren Erläuterung. Aus ihnen wird ein Testmodell
erstellt, das sog. „Markov Chain Usage Model“ (MCUM). Es stellt die zentrale Struktur
im Entwurfsprozess dar, neben einer Beschreibung der Eigenschaften und Vorteile gibt
das Kapitel eine Abbildungsvorschrift für dessen Erstellung aus der Anforderungsspezifikation
wieder. Abschließend werden verschiedene Aspekte beleuchtet, die bei der Testfallgenerierung
aus dem MCUM und der Erzeugung einer Testsuite in der TTCN-3 zu
beachten sind.
Kapitel 5 enthält eine Anwendungsstudie mit Modulen für drahtlose Sprach- und Datenübertragung
(DECT). Der gesamte Entwurfsprozess wurde in Form einer Werkzeugkette
realisiert, welche in der Studie exemplarisch angewendet werden konnte. Damit konnte
die Anwendbarkeit von Q.E.D. auf reale Systeme demonstriert werden. Kapitel 6 fasst die
Ergebnisse der Arbeit noch einmal zusammen, den Abschluss bilden die Verzeichnisse
der in der Arbeit enthaltenen Abbildungen und der referenzierten Literatur.
3

4
Einleitung

2 Softwaretest
Das folgende Kapitel beschreibt den Softwaretest und die Konzepte der Testsprache
TTCN-3. Die Einführung ordnet das Testen in den Softwareentwurf ein, beschreibt dessen
Klassifizierung und erklärt die häufigsten Testarten. Im Anschluss werden modellbasierte
Testansätze vorgestellt, als Grundlage für den – im Kapitel 4 vorgestellten – Testentwurfsprozess.
Den Abschluss des Kapitels bildet eine Beschreibung der Testnotation
TTCN-3, der Zielsprache des entwickelten Q.E.D.-Ansatzes.
2.1 Einführung
Der Entwurf von Software gliedert sich in verschiedene Phasen. Er beginnt in der Regel
mit der Definition der Anforderungen und endet vor der Softwarefreigabe mit einer Testphase.
Dazwischen lassen sich je nach Detaillierungsgrad mehrere Entwurfs-, Spezifikations-,
Programmier- und Testphasen identifizieren. Ein Entwicklungsprozess regelt ihre
genaue Abfolge, Phasen können in Iterationen mehrmals durchlaufen, andere vernachlässigt
oder übersprungen werden.
Die Abbildung 1 stellt exemplarisch das V-Modell dar, ein Vorgehensmodell für die
Softwareentwicklung aus der Mitte der 80er Jahre. Trotz seines Alters und der Veröffentlichung
neuerer und moderner Methoden verdeutlicht es sehr gut das Vorhandensein unterschiedlicher
Testphasen und deren Testfallgrundlagen. Wie die Bezeichnungen schon
andeuten, werden beim Modultest einzelne Softwaremodule und beim Systemtest das
gesamte System geprüft. Von Ersterem bilden die detaillierten Entwurfsdokumente und
Modulspezifikationen die Grundlage der Testfälle, von Letzterem sind es die Anforderungsdefinitionen
und Grobentwürfe. Der Integrationstest zielt auf die Schnittstellen bei
der Interaktion verschiedener Komponenten, der Abnahmetest ist ein Systemtest aus Sicht
des Kunden und findet in dessen Systemumgebung statt.
Der Begriff des Softwaretests wird in der Literatur unterschiedlich weit gefasst. G. J.
Myers definierte Ende der 70er Jahre [Mye79] Testen als „Prozess, ein Programm mit der
Absicht auszuführen, Fehler zu finden“. Eine aktuelle Definition geben Spillner et.al. in
[SL03] mit einem Testobjekt, welches zur Überprüfung stichprobenartig ausgeführt wird.
Das Testobjekt ist hierbei unbestimmt und kann von einer einfachen Funktion bis zu einem
vollständigen verteilten System jegliche Komplexität besitzen.
5

6
Anforderungsdefinition
Grobentwurf
Feinentwurf
Modulspezifikation
Testfälle
Testfälle
Testfälle
Testfälle
Testfälle
Testfälle
Testfälle
Programmierung
Modultest
Integrationstest
Abbildung 1 V-Modell, nach [Bal98]
Systemtest
Abnahmetest
Softwaretest
Andere Definitionen beschreiben den Testbegriff umfassender und schließen Analyse-
und Reviewtechniken mit ein, die als statische Testverfahren klassifiziert werden, da das
Testobjekt nicht zur Ausführung gebracht wird. Balzert beschreibt in [Bal98] Testen als
„[…] jegliches Mittel mit dem Ziel, Fehler in einem Programm zu finden“.
Auch die letztgenannte Definition umfasst nicht die Klasse der statistischen Testverfahren.
Nach [Vee06] stellen diese ein Testentwurfsverfahren dar, „in dem das Modell der
statistischen Verteilung der Eingaben verwendet wird, um repräsentative Tests zu konstruieren.“
Musa benennt in [Mus98] den „anwendungsprofilorientierten Test“ und beschreibt
ihn als „statistischen Test unter Verwendung eines Modells von Systemoperationen
und ihrer typischen Nutzung“.
Bei statistischen Testverfahren werden die Testfälle demnach nicht mit dem Augenmerk
erstellt, möglichst viele Fehler aufzudecken und damit die Systemqualität zu erhöhen.
Vielmehr werden durch die Verwendung der statistischen Eingabeverteilung Testfälle
erzeugt, um die erreichte Systemqualität abzuschätzen.
Die Begriffsdefinition des Softwaretests, der sich diese Arbeit anschließt, findet sich in
[Vee06] wieder:
Definition: „Testen ist der Prozess, bestehend aus allen Aktivitäten des Lebenszyklus, der
sich, sowohl statisch als auch dynamisch, mit der Planung, Vorbereitung und Bewertung

Einführung
eines Softwareprodukts und damit verbundener Arbeitsergebnisse befasst, um sicherzustellen,
dass sie die festgelegten Anforderungen erfüllen, um zu zeigen, dass sie ihren
Zweck erfüllen, und um Fehler zu finden.“ [Vee06]
Qualitätssichernde Prüfmaßnahmen werden meist als Verfahren der Verifikation oder der
Validierung klassifiziert. Eine strenge Zuordnung des Testens ist allerdings nicht möglich.
Nach [IEE90] versteht man unter der Validierung den Prozess der Beurteilung eines
Systems oder einer Komponente während oder am Ende des Entwicklungsprozesses, mit
dem Ziel, festzustellen, ob die spezifizierten Anforderungen erfüllt sind. Betrachtet werden
Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische
beabsichtigte Anwendung. Es wird also geprüft, ob das richtige System realisiert wurde.
Unter einer Verifikation versteht man zwei Dinge [IEE90]. Zum einen ist sie der Prozess
der Beurteilung eines Systems oder einer Komponente mit dem Ziel, festzustellen, ob die
Resultate einer gegebenen Entwicklungsphase den Vorgaben für diese Phase entsprechen.
Demnach wird geprüft, ob das System richtig realisiert wurde. Zum anderen ist sie der
formale Beweis der Korrektheit des Systems. Letzteres wird auch formale Verifikation
genannt.
Der Großteil der Testaktivitäten findet zur Konformitätsüberprüfung statt, d.h. es wird
bestimmt, ob ein System die vorher festgelegten Forderungen erfüllt. Testen wird daher
im Allgemeinen der Verifikation zugeordnet. Werden die Testfälle jedoch hinsichtlich
Benutzeranforderungen mit dem Blick auf gewünschte Anwendungsfälle erstellt, findet
eine Validierung statt.
Folgende zwei charakteristische Eigenschaften besitzen alle Testverfahren: (1) Ein Test
entspricht immer einem Stichprobenexperiment, d.h. die Eingabedomäne ist in der Regel
auch bei kleinen Systemen zu groß, um sie vollständig zu testen. (2) Es existiert immer
ein Testorakel, welches beobachtete Ereignisse der Testdurchläufe auf ihre Korrektheit
überprüft. Ohne diese Aussagemöglichkeit wäre der Test sinnlos. Dabei ist es unerheblich,
woher das Orakel die Korrektheitsinformation erhält und wann die Überprüfung
stattfindet.
Testarten
Zur Kategorisierung der Testverfahren existieren verschiedene Dimensionen bzw. Unterscheidungsmerkmale,
die jeweils mehrere disjunkte Testklassen bilden. Die am häufigsten
verwendeten Kriterien werden im Folgenden vorgestellt:
7

8
Softwaretest
Eine Dimension stellt der Ursprung der Korrektheitsinformation für die Testfälle dar. Sie
klassifiziert Verfahren in „black-box“ bzw. funktionale und „white-box“ bzw. strukturelle
Tests. Bei der erstgenannten Gruppe werden Testfälle auf Grundlage der vorliegenden
Systemspezifikation, bei der zweiten auf Grundlage der Implementierung gewonnen.
Mischformen gehören der „grey-box“-Klasse an.
Beschränken sich die getesteten Anforderungen nicht nur auf das rein funktionale Verhalten,
so wird von nicht-funktionalen Tests gesprochen. Die Fragestellung des Testers lautet
nicht „Funktioniert es?“ sondern „Funktioniert es gut genug?“. Je nach betrachtetem Aspekt
lassen sich eine Vielzahl von Unterklassen benennen. Hier sind insbesondere Zeit-
und Leistungsfragen von Belang, die mit Leistungs-, Last- und Stresstests eine hohe Bedeutung
haben. Sicherheits- und Robustheitstests prüfen auf Sicherheitslücken bzw. auf
Negativfälle.
Entsprechend der zu testenden Einheit existieren unterschiedliche Testlevel. Beim Komponententest
werden einzelne Module bzw. Komponenten getestet. Der Integrationstest
prüft die Modulschnittstellen und das Zusammenspiel integrierter Module. Das gesamte
System ist im Fokus des Systemtests.
Eine weitere Dimension ist die Lokalität des Testsystems, die zwei weitere Klassen bildet.
Läuft es auf einem einzelnen Knoten, so findet ein lokaler, ansonsten ein verteilter
Test statt. Wird das zu testende System während des Tests ausgeführt, spricht man von
einem dynamischen Test, sonst von einem statischen Test. Die primäre Zielsetzung des
Tests kann das Auffinden von Fehlern sein (Fehlertest) oder die Abschätzung der Qualität
(statistischer oder Qualitätstest).
Neben vielen weiteren Unterscheidungsmerkmalen existiert eine Testklasse, die in den
letzten Jahren an Bedeutung gewonnen hat. Mit dem Begriff des modellbasierten Tests
wird zum Ausdruck gebracht, dass ein Modell die Grundlage der Testfallgenerierung
bildet. Das anschließende Kapitel gibt einen Überblick über existierende und laufende
Arbeiten in diesem Umfeld.
Zur Beschreibung eines Testverfahrens werden relevante Dimensionen ausgewählt und
die zutreffenden Testklassen genannt. Der in dieser Arbeit vorgestellte Testentwurfsprozess
ließe sich mit den hier vorgestellten Dimensionen als ein statistisches, dynamisches,
modellbasiertes, nicht-funktionales, black-box Systemtestverfahren bezeichnen.

Modellbasierter Test
2.2 Modellbasierter Test
Beim Systementwurf erfahren modellgestützte Ansätze seit vielen Jahren wachsende Bedeutung,
insbesondere ihre visuelle Notation und erweiterte Analyse- und Validierungsmöglichkeiten
sind dafür verantwortlich.
Eine Testsuite ist ein Stück Software, bei ihrer Erstellung treten demnach die gleichen
Herausforderungen und Fehlerquellen auf, wie sie bei jedem Softwareentwurf zu Tage
treten. Um gleichermaßen von den Vorteilen modellgestützter Herangehensweisen zu
profitieren, halten diese auch in der Testphase Einzug.
In modellbasierten Testverfahren werden Testfälle auf Basis eines Testmodells erstellt.
Der Begriff „Testmodell“ impliziert jedoch kein dediziertes Modell für das Testen, er
beschreibt nur den (möglicherweise zusätzlichen) Verwendungszweck.
Die grundsätzliche Vorgehensweise beim modellbasierten Testen ist die folgende: Ein
Modell des zu testenden Systems, des sog. „SUT“ (System Under Test), wird erstellt, um
anschließend daraus Testfälle zu generieren. Das SUT wird mit Eingabesignalen bzw.
-nachrichten stimuliert, um anschließend die Ausgaben des SUT mit denen des Modells
zu vergleichen. Dies impliziert die Forderung eines gültigen und korrekten Modells, d.h.
es muss die tatsächlichen Anforderungen an das System widerspiegeln.
Da ein Modell immer eine Abstraktion eines realen Systems ist, bei dem – für den Anwendungszweck
– unwichtige Aspekte weggelassen wurden, bleibt der Vergleich zwischen
Modell und SUT stets unvollständig. Für die Erstellung der Testfälle aus dem Modell
werden meist strukturelle Kriterien definiert, d.h. von den Testfällen wird ein bestimmter
Grad an Modellüberdeckung gefordert. Alternativ können ausgewählte „interessante“
Testfälle erzeugt werden.
Im Folgenden werden verschiedene Aspekte im Zusammenhang mit Testmodellen betrachtet.
2.2.1 Sichten
Testmodelle unterscheiden sich in ihrer Systemsicht und in ihren Abstraktionsniveaus.
Ein Testmodell kann die Sicht eines Systemmodells oder eines Benutzungsmodells besitzen.
Ersteres beschreibt die Systemdynamik, bestehend aus dem internen Verhalten und
der Schnittstellenkommunikation. Das Systemmodell beschreibt also, wie ein System sein
Verhalten realisiert. Das Benutzungsmodell besitzt eine externe Sicht auf das System, es
beschreibt ausschließlich das Kommunikationsverhalten mit der Umwelt, interne System-
9

10
Softwaretest
abläufe sind nicht enthalten. Das Modell enthält also lediglich Informationen darüber, was
in Reaktion auf Benutzungseingaben vor sich geht, nicht wie es realisiert wird.
2.2.2 Szenarien
Innerhalb des Entwurfsprozesses eines Systems können Testmodelle auf unterschiedliche
Weise eingesetzt werden, in [PP05] sind hierzu vier Szenarien beschrieben.
autom.
Erzeugen
Testfälle
Anforderungsdefinition
autom.
Erzeugen
Testfälle
Anforderungsdefinition Anforderungsdefinition
Spezifikation
Modell
manuelles
Überprüfen
Testmodell
autom.
Überprüfen
autom.
Erzeugen
Code
Spezifikation
Code
manuelle
Codierung
autom.
Erzeugen
Testfälle
Anforderungsdefinition
autom.
Erzeugen
Testfälle
Testmodell
manuelles
Überprüfen
Testmodell
autom.
Überprüfen
Abbildung 2 Modellbasiertes Testen – Szenarien, nach [PP05]
autom.
Erzeugen
Code
Implement.modell
Code
manuelle
manuelle
Codierung
oder autom.
Codierung
Eine Möglichkeit ist die Erstellung eines gemeinsamen Modells aus der Anforderungsspezifikation
für die Code- und Testfallgenerierung (Abbildung 2, l.o.). Der Vorteil ist die
Erstellung und Pflege eines einzigen Modells. Nachteil ist jedoch die fehlende Redundanz,
die für das Testen nötig ist, d.h. die unabhängige Erstellung des aktuellen Verhaltens
(in dem SUT) und des gewünschten Verhaltens (in den Testfällen). Damit sind in
diesem Szenario lediglich zwei Dinge testbar: der Code-Generator und getroffene Annahmen
über die Umgebung.
Im zweiten Szenario wird das SUT manuell implementiert und das Testmodell aus dem
Systemcode extrahiert (Abbildung 2, r.o.). Automatisch generierte Testfälle aus diesem
Modell besitzen jedoch den gleichen Nachteil wie im vorherigen Szenario: ihnen fehlt die
Redundanz.

Modellbasierter Test
Eine weitere Möglichkeit ist neben der manuellen Implementierung des SUT die manuelle
Erstellung des Testmodells aus der Anforderungsspezifikation (Abbildung 2, l.u.).
Durch die dabei entstehende Redundanz ist eine Testausführung mit automatischer Vergabe
von Testurteilen möglich.
Das letzte Szenario ist die Erstellung zweier verschiedener Modelle, eines Implementierungs-
und eines Testmodells (Abbildung 2, r.u.). Aus ersterem lässt sich Systemcode, aus
letzterem lassen sich Testfälle generieren. Durch das Vorhandensein zweier Modelle ist
die nötige Redundanz für das Testen gegeben.
2.2.3 Modellarten
Testmodelle werden insbesondere durch Transitionssysteme dargestellt. Die zwei wichtigsten
Vertreter sind die beschrifteten Transitionssysteme („labelled transition system“
(LTS)) und die endlichen Automaten („finite state machine“ (FSM)).
Beschriftete Transitionssysteme (LTS)
Beschriftete Transitionssysteme [Kel76] sind eine verbreitete Notation zur Beschreibung
von datenintensiven Systemen und von Hardwareschaltungen. Sie beschreiben in einem
zustandsbasierten System alle möglichen Zustände und Zustandsübergänge (Transitionen).
Formal ist ein LTS definiert durch ein Quadrupel (S, A, T, S0), mit der Zustandsmenge S,
dem Alphabet („labels“) A mit S∩A = ∅, der Transitionsrelation T ⊆ S×A×S und der
nichtleeren Menge an Startzuständen S0 ⊆ S. Im Gegensatz zu den endlichen Automaten
müssen in einem LTS die Zustandsmenge S, das Alphabet A und somit auch T nicht endlich
sein.
Die folgenden Arbeiten setzen das Vorhandensein eines präzisen und eindeutigen LTS-
Modells eines realen Systems voraus. Das bedeutet, dass Zustände und Transitionen im
LTS eindeutig entsprechenden Zuständen und Übergängen im SUT zuzuordnen sind.
Daraus folgt, dass die aus dem Modell erzeugten Testfälle das SUT genau auf die gewünschte
Eigenschaft hin, und nur auf diese Eigenschaft überprüfen. Diese Testfälle
nennt man beweisbar gültig („valid“).
Die wichtigste Theorie im Bereich der LTS-basierten Testmodelle ist die ioco-Theorie
[Tre96], welche nach der ioco-Implementierungsrelation („input output conformance
relation“) benannt ist. Die Relation ist ein abstraktes Konzept und beschreibt formal die
11

12
Softwaretest
Umstände einer korrekten Implementierung. Hierfür wird angenommen, dass für jedes zu
testende System ein eindeutiges korrektes Modell existiert, d.h. dass die zu testenden Systeme
formal behandelt werden können.
Die Konformität zwischen Spezifikation und Implementierung wird formal als Konformitätsrelation
zwischen zwei Modellen definiert, dem Modell der Spezifikation und dem der
Implementierung. Formal ist die ioco-Implementierungsrelation folgendermaßen definiert:
i ioco s =def ∀σ ∈ Straces(s) : out(i after σ) ⊆ out(s after σ)
Straces(p) : Mögliche Spurenmenge im LTS p
p after σ : Erreichbare Zustandsmenge nach Ausführung der Spur σ im LTS p
out(P) : Ausgabenmenge der möglichen Transitionen für die Zustandsmenge P
Informal bedeutet dies, dass eine Implementierung i ioco-korrekt zu einer Spezifikation s
ist, wenn nach allen möglichen Verhalten der Spezifikation jede Ausgabe der Implementierung
eine mögliche Ausgabe der Spezifikation ist. Dies soll auch für die spezielle Ausgabe
„quiescence“ gelten, die für die leere (keine) Ausgabe steht.
Testgenerierungsalgorithmen zur Überprüfung der ioco-Korrektheit erzeugen eine Test-
Suite mit folgenden zwei Eigenschaften: Ist das SUT korrekt implementiert, so wird kein
Testfall erzeugt, der zu dem Testurteil „fail“ führt (ein fehlerfreies Modell wird vorausgesetzt).
Eine Testsuite mit dieser Eigenschaft nennt sich sound. Ist das SUT fehlerhaft implementiert,
so kann ein Testfall generiert werden, der einen Fehler aufzeigt. Dies ist die
completeness oder Vollständigkeitseigenschaft der Testsuite.
Den Testgeneratoren vieler Werkzeuge liegt die „ioco“-Theorie zugrunde. Zu den wichtigsten
gehören das „Côte de Resyste“-Projekt mit dem Tool TorX [HD03], das TGV-
Tool von IRISA / Verimag 1 [JJ02] und das AGEDIS-Projekt mit dem gleichnamigen
Werkzeug [Har04].
Das „Côte de Resyste“-Projekt [TB02] begann 1998 mit dem Ziel, die formale ioco-
Testtheorie in einem Werkzeug umzusetzen und ihre Anwendbarkeit anhand mehrerer
akademischer und industrieller Studien zu demonstrieren. Das „TorX“ getaufte Tool unterstützt
die automatische Testgenerierung, -ausführung und -analyse in einem „on-the-
1 http://www-verimag.imag.fr/

Modellbasierter Test
fly“-Modus. Dies bedeutet, dass jeder erzeugte Testschritt sofort ausgeführt wird und
entsprechend der erhaltenen Antwort der nächste Testschritt gewählt wird. Unterstützte
Eingabesprachen zur Beschreibung des beschrifteten Transitionssystems sind LOTOS
[ISO88], PROMELA [Hol91], SDL [ITU99] und LTSA [MK99].
„TGV“, entwickelt von IRISA und Verimag [JJ02], ist ein Tool für Konformitätstests und
basiert ebenso auf der ioco-Implementierungsrelation. Bis auf eine zusätzliche Betrachtung
von Livelocks entspricht die Testtheorie der von TorX. TGV unterstützt mehrere
Eingabesprachen, darunter LOTOS [ISO88], SDL [ITU99], UML und IF [BFG+99], einem
von Verimag entwickelten Beschreibungsformat.
Das AGEDIS-Projekt [Har04] bestand zwischen den Jahren 2000 und 2003 aus sieben
akademischen und industriellen Partnern. Ziel war die Entwicklung von Methoden und
Tools zum automatischen Softwaretest. Einzige Eingabesprache ist die AML (AGEDIS
Modeling Language), ein Profil der UML 1.4. Das UML-Modell wird in die Zwischennotation
IF [BFG+99] übersetzt, aus der Testfälle generiert werden. Der Algorithmus dazu
setzt sich aus TGV und GOTCHA [FHP02] zusammen, einem Tool von IBM. Letzteres
erweitert den Algorithmus um die Möglichkeit, die Testfallauswahl anhand von
Einschränkungs- und Überdeckungskriterien zu steuern.
Endliche Automaten (FSM)
Endliche Automaten gehören zu den am stärksten verbreiteten Verhaltensmodellen. Neben
der Beschreibung von digitalen Schaltungen finden sie in allen Bereichen der Softwaretechnik
ihren Einsatz.
Ein FSM ist formal definiert durch ein 6-Tupel (I, O, S, s0, δ, λ). I und O entsprechen den
endlichen, nicht leeren Mengen des Ein- bzw. Ausgabealphabets, S und s0 der nicht leeren
Zustandsmenge bzw. dem Anfangszustand, δ ist mit δ: SxI → S die Zustandsübergangs-
funktion und λ mit λ: SxI → O die Ausgabefunktion.
Viele formale Notationen basieren auf den endlichen Automaten oder ähneln ihnen sehr,
so auch die Statecharts [Har87], die SDL [ITU99], ASM [GKO+00], Stateflow 1 , etc.
Der Verwendung von endlichen Automaten für die Testfallgenerierung kommen viele
Ergebnisse aus der klassischen Automatentheorie zu Gute. Der wichtigste Algorithmus ist
wohl der für das Auffinden des kürzesten Pfades zur Überdeckung aller Zustände bzw.
aller Transitionen (das sog. „Briefträgerproblem“).
1 http://www.mathworks.com/products/stateflow
13

14
Softwaretest
Weitere Ergebnisse aus der Automatentheorie, die eine sinnvolle Anwendung beim modellbasierten
Testen finden, sind z.B. Verfahren zur Identifizierung bzw. Überprüfung des
aktuellen Automatenzustands. Oder das Auffinden einer Eingabesequenz, die den Automaten
sicher in den Endzustand führt, unabhängig vom aktuellen Zustand, in dem sich der
Automat befindet (eine sog. „synchronizing sequence“). Weiterhin sind Eingabesequenzen
bestimmbar (sog. „homing sequences“), mit denen ein erreichter Zustand identifiziert
werden kann, indem die Ausgabesequenz betrachtet wird.
Zu den bekanntesten Testfallgeneratoren auf FSM-Basis gehören „Autolink“ und der
„TestComposer“ [SEG00]. Die Firmen Telelogic 1 und Verilog waren vor ihrer Fusion
Ende 1999 Hersteller der zwei führenden Tools für die SDL [ITU99]. Auch nach der Fusion
blieben deren Produkte „Tau“ und „ObjectGeode“ eigenständig, welche die zwei
genannten Testfallgeneratoren als Testkomponenten enthielten. Während der „TestComposer“
die „TGV“-Algorithmen [JJ02] zur Testfallerzeugung übernahm, wurden in „Autolink“
die Arbeiten des „SaMsTaG-Projektes“ [GNS+94] integriert. Dabei werden die
Testfälle durch die Exploration des Zustandsraums eines vorhandenen SDL-Modells erzeugt.
„PHACT“ und „TVEDA“ sind zwei weitere Testwerkzeuge auf Basis von endlichen Automaten.
Mit beiden wurden akademische Anwendungsstudien betrieben. Ersteres wurde
von Philips 2 im Jahre 1995 entwickelt und erzeugt aus einem endlichen Automaten Testfälle
in der TTCN-2 (siehe Kapitel 2.3). Letzteres ist ebenso aus dem Jahr 1995 von der
France Telecom 3 , es traversiert SDL-Modelle und erzeugt Testfälle in der TTCN-2.
Daneben existiert noch eine Reihe von kommerziellen Werkzeugen mit endlichen Automaten
als Eingabeformat, über deren interne Testfallgeneratoren jedoch nur wenig bekannt
ist (z.B. der Conformiq 4 „Test Generator“).
2.2.4 Model Driven Architecture (MDA)
Andere modellbasierte Testansätze adaptieren den Grundgedanken der „Model Driven
Architecture“ (MDA) [OMG03]. Die MDA repräsentiert die Vision der ausführbaren
1 http://www.telelogic.de
2 http://www.philips.de
3 http://www.rd.francetelecom.com
4 http://www.conformiq.com

Modellbasierter Test
Modelle und beschreibt im Wesentlichen drei Artefakte für unterschiedliche Sichtweisen
in der modellgestützten Systementwicklung.
Das „Computation Independent Model“ (CIM) stellt ein Benutzungsmodell dar. Es beschreibt
ein System innerhalb seiner Umgebung und fokussiert auf die Systemanforderungen.
Das Modell fungiert als Schnittstelle zwischen den Verantwortlichen für die Anforderungsspezifikation
und den Systemdesignern. Das „Platform Independent Model“
(PIM) spezifiziert die Funktionalität eines Systems, ohne Informationen über eine spezifische
Plattform zu enthalten. Es besteht aus den Spezifikationsteilen, die sich zwischen
verschiedenen Plattformen nicht ändern. Im „Platform Specific Model“ (PSM) findet sich
das PIM wieder, welches um Details einer bestimmten Plattform erweitert wurde.
[OMG03] beschreibt generische Möglichkeiten, Transformationen zwischen diesen drei
Artefakten automatisiert in beide Richtungen durchzuführen. Das PIM kann so je nach
Anwendungszweck durch unterschiedliche Regelsätze in verschiedene PSMs transformiert
werden. Die umgekehrte Richtung ermöglicht „reverse engineering“ und ist für die
Konsistenzhaltung und Verfolgbarkeit von Funktionalitäten zwischen Modellen von Bedeutung.
Es existieren zwei grundlegende Interpretationen, wie die Vision der MDA zu realisieren
ist, die „Ausarbeitungs-“ („elaborationist“) und die „Übersetzungsvariante“ (“translationist“).
Für beide Denkweisen existieren Literatur und Werkzeuge.
Im ersten Ansatz wird manuell ein PIM erstellt, aus der automatisiert das Grundgerüst der
PSM generiert werden kann. Diese muss manuell ausgearbeitet bzw. vervollständigt werden.
Daraus kann dann wiederum automatisiert der Hauptteil des Codes generiert werden,
welcher per Hand vervollständigt werden muss. Idealerweise soll auch die umgekehrte
Richtung automatisiert sein, d.h. die Modifikationen der ausgearbeiteten Modelle können
in die abstrakteren Modelle eingearbeitet werden.
In der zweiten Variante wird das PIM direkt in Code übersetzt. Das PSM existiert nur als
interner Zwischenschritt im Code-Generator, das weder sichtbar noch veränderbar ist.
Wesentlich hierbei ist, dass keine manuelle Änderung des PSM oder des Codes notwendig
ist. Es findet ein einziger Übersetzungsvorgang mit Hilfe des PIM und der Generierungsregeln
statt.
[ZDS+05] greift den Ansatz der MDA auf und überträgt ihn auf die Testentwicklung zum
„Model Driven Testing“ (siehe Abbildung 3). Es führt zum PIM und PSM korrespondierende
Testmodelle ein, das „Platform Independent Test design model“ (PIT) und das
„Platform Specific Test design model“ (PST). Zum einen sollen die Testmodelle aus den
entsprechenden Systemmodellen gewonnen werden, zum anderen soll nach dem MDA-
15

16
Softwaretest
Ansatz das PST aus dem PIT hervorgehen. Zur letztgenannten Aufgabenstellung beschreibt
[ZDS+05] eine konkrete Implementierung von Transformationsregeln. Als
Quellsprache kommt das „UML 2 Testing Profile“ (siehe Kapitel 3.7.3) zum Einsatz, als
Zielsprache dient die TTCN-3 (siehe Kapitel 2.3).
Abbildung 3 „Model Driven Testing“ [ZDS+05]
[SD04] beschreibt ebenso die Anwendbarkeit der MDA-Philosophie in der Testentwicklung.
Die plattformunabhängige Testbeschreibung erfolgt in proprietär erweiterten
UML1-Modellen. Aus diesen lässt sich automatisiert ausführbarer Python-Code generieren,
welcher die plattformabhängige Testspezifikation darstellt.
2.3 Testing and Test Control Notation 3
Dieses Kapitel gibt einen Einblick in die Konzepte der „Testing and Test Control Notation
version 3“. Es werden die Bestandteile einer TTCN-3 Testsuite, die Testarchitektur
und die Verhaltensbeschreibung erläutert. Im Anschluss soll eine Beispiel-Testsuite zum
besseren Verständnis beitragen. Den Abschluss bilden existierende Erweiterungen der
TTCN zur Spezifikation von Zeit- und Leistungsanforderungen.
2.3.1 Historie
Der Ursprung der TTCN-3 liegt beim Protokolltest. Kommunikationsprotokolle regeln
die Interaktionen zwischen verschiedenen Instanzen. Dabei ist es unerheblich, wo sich die
Instanzen befinden, ob innerhalb eines lokalen Systems oder verteilt auf Komponenten,

Testing and Test Control Notation 3
oder welches Übertragungsmedium zwischen ihnen genutzt wird. Protokolle legen die
Reihenfolge der auszutauschenden Nachrichten, deren Inhalt, Bedeutung und Format fest.
Beim Protokolltest liegt das Hauptaugenmerk auf dem Testen der Konformität zwischen
der Spezifikation und der Implementierung. Die Konformität gewährleistet, dass unterschiedliche
Implementierungen miteinander interagieren können. Für diverse Kommunikationsprotokolle
existieren schon von den Standardisierungsgremien veröffentlichte
Testsuiten zur Überprüfung auf Konformität.
Konformitätstests sind Black-Box-Tests, da die Testfälle aus der Spezifikation gewonnen
werden. Daraus folgt, dass der Formalismus der Spezifikation bedeutenden Einfluss auf
das Testen der Protokolle hat. Um die Mängel informaler Techniken zu umgehen, dominieren
insbesondere formale Beschreibungstechniken. Schon in den achtziger Jahren
wurden für den Protokollentwurf formale Sprachen wie Estelle [ISO89], LOTOS [ISO88]
und SDL [ITU99] verabschiedet.
1992 verabschiedete die ISO (International Standardization Organization) den „International
Standard 9646“ [ISO92], ein Rahmenwerk für den Konformitätstest von OSI-
Protokollen („Conformance Testing and Methodology Framework“ (CTMF)). Dieser
mehrteilige Standard beschreibt allgemeine Vorgehensweisen, Testarchitekturen und Methoden
zur Konformitätsprüfung von Kommunikationsprotokollen. Zusätzlich wurde eine
neue Beschreibungssprache für Testfälle eingeführt, die TTCN („Tree and Tabular Combined
Notation“). Die Bezeichnung deutet an, dass in der TTCN das Testfallverhalten in
Tabellen baumartig notiert wird (die Zeit verläuft von der Wurzel zu den Blättern, Verzweigungen
entsprechen Alternativen).
Stellte die zweite TTCN-Version noch eine Erweiterung der ursprünglichen Sprache dar
(hinzu kamen insbesondere die Unterstützung von verteilten Tests und Modularisierungsmöglichkeiten),
wurde mit der aktuellen dritten Version, der TTCN-3 [ETS07a],
eine komplett überarbeitete Fassung veröffentlicht. Mit zahlreichen neuen Sprachkonstrukten,
neuen Notationsmöglichkeiten und der Definition standardisierter Schnittstellen
wurden der TTCN-3 die Beschränkungen des Protokolltests genommen. Es entstand eine
universelle Testnotations- und Testimplementierungssprache. Auf Grund der neuen Notationsmöglichkeiten
und zur Verdeutlichung der vielfältigen Änderungen steht hinter dem
Kürzel TTCN nun die „Testing and Test Control Notation“. Im Jahre 2001 stellte die
ETSI (European Telecommunications Standards Institute) die erste Fassung der TTCN-3
vor. In den folgenden Jahren folgten mehrere Revisionen mit Ergänzungen und Detailverbesserungen.
Zum aktuellen Zeitpunkt gilt Version 3.2.1 vom Februar 2007.
17

18
2.3.2 Der TTCN-3 Standard
Softwaretest
Die TTCN-3 ist aktuell die einzige standardisierte Testsprache, ihre Verwendung bringt
demnach die Vorteile eines jeden Standards mit. Die Syntax und Semantik der Tests wird
von einem größeren Anwenderkreis verstanden und hängt nicht von einer bestimmten
Programmiersprache ab. Die Kosten werden gesenkt, da unterstützende kommerzielle
Werkzeuge zur Verfügung stehen und sich Ausbildungskosten reduzieren. Die Sprache
selbst wird gepflegt und an neue Anforderungen angepasst. Die erstellten Testsuites können
besser gewartet werden. Außerdem ist die TTCN-3 als dedizierte Testsprache speziell
für das Testen entwickelt worden. Als solche ist sie abstrakt gehalten, der Tester kann
sich auf das Entwickeln der Tests konzentrieren, ohne auf Details des getesteten Systems
Rücksicht nehmen zu müssen.
Im Speziellen zeichnet sich die TTCN-3 durch folgende Eigenschaften aus. Ihre Syntax,
ihre statische und ihre operationelle Semantik sind wohldefiniert. Die Sprache erlaubt das
Erstellen von dynamischen, d.h. zur Laufzeit veränderlichen Testkonfigurationen aus
nebenläufig agierenden Testkomponenten. Zur Kommunikation mit dem zu testenden
System stehen der Prozeduraufruf und der asynchrone Nachrichtenaustausch zur Verfügung.
Für die Datenbehandlung existieren sowohl CoDec-Mechanismen für die Kodierung
bzw. Dekodierung der Daten als auch Verfahren für das „Matching“, d.h. für das
Erkennen und Überprüfen des Datentyps ankommender Nachrichten. Des Weiteren fallen
die optionalen Notationsmöglichkeiten auf, die das einfachere Verständnis fördern und
dem Trend zu graphischen Designs Rechnung tragen.
Die aktuelle Spezifikation der TTCN-3 besteht aus acht Teilen. Die Kernspezifikation
(Teil 1) wird durch zwei weitere Notationsmöglichkeiten – einer tabellarischen (Teil 2)
und einer graphischen (Teil 3) – ergänzt. Die operationelle Semantik (Teil 4) definiert die
Bedeutung der Verhaltensanweisungen der Sprache. Die nächsten zwei Teile widmen sich
den Schnittstellen des ausführbaren bzw. interpretierbaren TTCN-3 Codes, das „TTCN-3
Runtime Interface“ (Teil 5) stellt das API zum „System Under Test“ (SUT) dar, das
„TTCN-3 Control Interface“ (Teil 6) das API zu weiteren Komponenten des Testsystems.
Die beiden letzten Teile beschreiben die Benutzung der abstrakten Datenbeschreibungssprache
ASN.1 (Abstract Syntax Notation One) (Teil 7) und der Schnittstellenbeschreibungssprache
IDL (Teil 8) innerhalb der TTCN-3.

Testing and Test Control Notation 3
Abbildung 4 Benutzersicht auf die TTCN-3 [ETS07a]
Abbildung 4 zeigt die Benutzersicht auf die TTCN-3. Die linke Hälfte deutet an, dass
neben den TTCN-3-eigenen Datentypen auch andere Sprachen zu ihrer Definition erlaubt
sind. Neben der ASN.1 dürfte insbesondere die XML als weitere Möglichkeit folgen.
Die rechte Seite stellt zum einen die standardisierten Präsentationsformate dar, d.h. die
textuelle, tabellarische und die graphische (MSC-ähnliche) Notation. Zum anderen lässt
der Standard weitere Formate zu, die für bestimmte Anwendungsbereiche geeigneter erscheinen.
Abbildung 5 Allgemeine Struktur eines TTCN-3 Testsystems, nach [ETS07c]
In Abbildung 5 ist die Gesamtstruktur eines Testsystems zu erkennen. Das Kernstück
stellt der ausführbare TTCN-3-Code dar (TTCN-3 Executable), welcher in kompilierter
oder interpretierbarer Form vorliegen kann. Aufgrund des abstrakten Charakters fehlen
diesem implementierungsspezifische Informationen über das zu testende System (SUT).
Die Kommunikation erfolgt daher über den „System Adaptor“ (SA), der die benötigten
19

20
Softwaretest
Kommunikationsmechanismen und Protokollstapel enthält. Im „Platform Adaptor“ stehen
weitere systemspezifische Funktionen bereit, beispielsweise werden hier spezielle Timer
und externe Funktionsaufrufe realisiert. Die Schnittstellen zu den zwei letztgenannten
Komponenten sind im sog. „TTCN-3 Runtime Interface“ (TRI) [ETS07b] festgelegt, dies
gibt Toolherstellern größere Freiheiten bei der Entwicklung von Werkzeugen zur Testausführung.
Die zweite Schnittstelle ist das „TTCN-3 Control Interface“ (TCI), sie regelt die Aufrufsyntax
zu vier logischen Komponenten. Im Test Management (TM) werden alle organisatorischen
Aufgaben der Testausführung geregelt inkl. diverser Modulparameter und externen
Konstanten. Eine optionale graphische Benutzeroberfläche zur einfacheren Testausführung
wäre hier angesiedelt.
Die Test Logging (TL) Komponente realisiert alle Operationen zum Abrufen von Informationen
über die Testausführung. Die Ergebnisliste kann gefiltert werden, um den benötigten
Detaillierungsgrad zu beeinflussen.
Über das „Coding/Decoding Interface“ (CoDec) wird auf benötigte Kodierer und Dekodierer
zugegriffen, um zu sendende und empfangene Daten entsprechend bearbeiten zu
können.
Das „Component Handling“ (CH) realisiert Operationen zum Management der Testkomponenten,
d.h. zu deren Erstellung, Auflösung und zum Aufbau der gewünschten Komponentenverbindungen.
Ebenso wird die gesamte Kommunikation unter den Testkomponenten
über das CH realisiert, gleich ob in einer lokalen oder verteilten Testkonfiguration.
2.3.3 Verteilter Test
Abbildung 6 zeigt die Struktur im Fall einer Testkonfiguration, bei der die TE auf mehrere
Knoten verteilt ist. Jeder Knoten besitzt neben der TE eine Entität von SA, PA, CD und
TL. Das TM und CH existieren nur einmal zur Überwachung des gesamten Tests bzw.
zur Steuerung der Testkomponenten auf den unterschiedlichen Knoten. Eine spezielle
TTCN-3 Executable startet einen Testfall und vergibt das finale Testurteil, ansonsten
werden alle TEs gleich behandelt.
Die Kommunikation zwischen den Testkomponenten wird von der CH-Komponente verwaltet.
Ganz gleich, ob die Empfängertestkomponente sich auf dem gleichen Testknoten
befindet oder nicht, oder ob die Kommunikation prozedural oder nachrichtenbasiert abläuft.
Die CH-Komponente empfängt den Kommunikationswunsch und adaptiert vor der
Weiterleitung das Signal bzw. die Nachricht auf die entsprechende Zielplattform. Den
Testkomponenten bleibt ihre örtliche Verteilung verborgen.

Testing and Test Control Notation 3
Abbildung 6 Allgemeines verteiltes TTCN-3 Testsystem, nach [ETS07c]
2.3.4 Testkonfiguration
In der TTCN-3 besteht eine Testkonfiguration aus einer Menge nebenläufig agierender
Testkomponenten, welche dynamisch spezifizierbar – also während des Testablaufs veränderbar
– ist. Ein Testsystem besteht immer aus einer „Main Test Component“ (MTC),
welche implizit beim Start eines Testfalls erzeugt wird und das in ihr spezifizierte Verhalten
ausführt. Alle anderen Testkomponenten sind parallele Testkomponenten (PTC), die
explizit durch die MTC oder anderen PTCs erstellt und zerstört werden.
Abbildung 7 Typische TTCN-3 Testkonfiguration [ETS07a]
Komponenten besitzen Ports, über die sie kommunizieren können. Jeder Port ist als potentiell
unendliche FIFO-Warteschlange für Nachrichten bzw. Prozeduraufrufe spezifiziert.
Das Überlaufen eines Ports in einem realen Testsystem soll zu einem Testfallurteil
21

22
Softwaretest
„error“ führen (siehe Kapitel 2.3.5). In Abbildung 7 ist neben den Komponenten das Test
System Interface (TSI) zu sehen. Es stellt die Kommunikationsschnittstelle zur SUT dar
und untergliedert sich wiederum in zwei Teile, dem abstrakten und dem realen TSI.
Das Abstrakte Test System Interface stellt die TTCN-3-interne Schnittstelle zur SUT dar
und ist nichts anderes als eine weitere Testkomponente mit dem reservierten Schlüsselnamen
„system“. Sie kommuniziert mit dem „realen“ TSI durch Aufruf der Funktionen,
die im TTCN-3 Runtime Interface (TRI) implementiert sind.
2.3.5 TTCN-3 Module
Eine Testspezifikation in der TTCN-3 besteht zunächst aus Modulen, welche die oberste
Struktureinheit darstellen. Sie sind parametrisierbar und können untereinander Definitionen
importieren. In ihnen werden alle benötigten Informationen spezifiziert, von den
Testkonfigurationen über das Testverhalten bis hin zu Anweisungen zur Testablaufsteuerung.
Letztere befinden sich im optionalen Kontrollteil des Moduls, welche lokale Variablen,
Konstanten und Timer enthalten. Ihre Hauptaufgabe liegt jedoch in der Festlegung der
Ausführungsreihenfolge der Testfälle durch die Verwendung von Bedingungen und
Schleifen. Fehlt der Kontrollteil, dient das Modul mit den enthaltenen Deklarationen und
Testfällen als Bibliotheksmodul.
Alle weiteren Anweisungen befinden sich im Definitionsteil. Zum einen sind dies datenrelevante
Informationen wie die Datentypen und die Vorlagen für die Testdaten. Neben
den üblichen Datentypen wie den primitiven, den benutzerdefinierten oder Typen für
Strings existiert ein spezieller Datentyp namens verdicttype. Jede Testkomponente besitzt
ein Objekt „verdict“ von diesem Typ zur Aufnahme des lokalen Testurteils. Dieses kann
eines von fünf Werten annehmen: none, pass, fail, inconclusive oder error. Zu Beginn
eines Testfalls ist der Wert none, während seiner Durchführung kann explizit ein pass,
fail oder im nicht spezifizierten Fall ein inconclusive Fall gesetzt werden. Treten Fehler in
der Testumgebung auf, wird implizit ein error gesetzt.
Datenvorlagen bzw. „Templates“ dienen zum einen zur Beschreibung der zu sendenden
Testdaten, zum anderen dienen sie beim Datenempfang als Grundlage eines Matching-
Verfahrens zu deren Korrektheitsüberprüfung. Das folgende Beispiel verdeutlicht das
Konzept, der folgende Codeabschnitt definiert einen Nachrichtentyp „MessageType1“:

Testing and Test Control Notation 3
type record MessageType1 {
integer field1,
boolean field2
}
Für den Empfang einer Nachricht dieses Typs wird ein Template definiert. Im Beispiel
fordert das „Template1“ für den zweiten Parameter den positiven Boolwert.
template MessageType1 Template1 := {
field1 := ?,
field2 := true
}
Aufgerufen wird die Empfangsoperation durch:
P1.receive(Template1);
Für die Versenden von Nachrichten werden ebenfalls Templates erstellt, z.B.:
template MessageType1 Template2 := {
field1 := 3,
field2 := false
}
Die Sendeoperation erfolgt dann durch:
P1.send(Template2);
2.3.6 TTCN-3 Verhalten
Wichtigste Aufgabe und Hauptbestandteil des Definitionsteils ist die Beschreibung des
gewünschten Testverhaltens. Dies geschieht in Testfällen und Funktionen, wobei erstere
in der TTCN-3 ebenso Funktionen sind, mit der Besonderheit der Rückgabe eines Testurteils.
Funktionen beschreiben entweder Testverhalten oder dienen der Strukturierung innerhalb
des Moduls, z.B. für wiederholende Aufrufe bestimmter Anweisungen.
Wird im Kontrollteil eines Moduls ein Testfall aufgerufen, so wird implizit die Haupt-
Testkomponente (MTC) dieses Testfalls erzeugt, bevor auf ihr die erste Anweisung ausgeführt
wird. Die MTC kann dann explizit weitere zu ihr parallel laufende Komponenten
(PTCs) starten und auf ihnen Funktionen aufrufen. Mit dem Ende eines Testfalls wird die
MTC gestoppt und mit ihr implizit alle weiteren existierenden Komponenten.
23

24
Softwaretest
Jede Testkomponente einschließlich der MTC berechnet ihr lokales Testurteil. Ist ein
Testfall beendet, wird aus ihnen nach einem definierten Schema das globale Testergebnis
gebildet, welches vom Testfall an den Kontrollteil des Moduls zurückgegeben wird. Der
Mechanismus zur Erzeugung des globalen Testurteils ist nicht spezifiziert.
Alternatives und verschränktes Verhalten
Eine genaue Erläuterung aller TTCN-3-Anweisungen kann in [ETS07a] nachgeschlagen
werden. Die Semantiken zweier Anweisungen wirken sich in besonderer Weise auf das
Zeitverhalten aus und werden hier näher erläutert.
Die Anweisung „alt“ stellt eine Verzweigung im Kontrollfluss aufgrund des möglichen
Empfangs verschiedener Nachrichten bzw. Signale dar. Die folgende Abbildung 8 stellt
links ein Beispiel in textueller TTCN-3 Notation dar, rechts als Sequenzdiagramm mit
Annotationen aus dem „UML2 Testing Profile“. Das Diagramm zeigt zwei Objekte, eine
Testkomponente und einen Port P1, welche Nachrichten austauschen. Die Zeit schreitet
im Sequenzdiagramm von oben nach unten voran, die umrandeten Alternativen sind jeweils
durch eine gestrichelte Linie voneinander getrennt. Die Angaben der „validationAction“
entsprechen dem Setzen eines Testurteils. Eine genaue Erläuterung des Diagrammtyps
und des Profils finden sich in Kapitel 3.6 bzw. 3.7.3 wieder.
alt {
}
[] P1.receive(Nachricht1) {
setverdict(pass);
}
[] P1.receive(Nachricht2) {
setverdict(fail);
}
[] t1.timeout {
setverdict(fail);
}
Abbildung 8 Anweisung für alternatives Verhalten

Testing and Test Control Notation 3
Die „interleave“-Anweisung beschreibt den möglichen Empfang verschiedener Nachrichten
in beliebiger Reihenfolge. Sie kann als eine Kurzschreibweise für eine größere Anzahl
verschachtelter „alt“-Anweisungen angesehen werden, so nehmen auch aktuelle Tools
diese Umwandlung intern vor. Der folgende Codeabschnitt beschreibt den möglichen
Empfang dreier Nachrichten in beliebiger Reihenfolge.
interleave {
[] P1.receive(Nachricht1);
[] P1.receive(Nachricht2);
[] P1.receive(Nachricht3);
}
2.3.7 INRES-Beispiel
Dieses Kapitel gibt für einen einfachen Testfall TTCN-3-Code in textueller Notation wieder.
Als Beispiel dient der einmalige Austausch von Daten inklusive dem Auf- und Abbau
der Verbindung zwischen zwei Instanzen, wie er im INRES-Protokoll [Hog91] beschrieben
ist.
Abbildung 9 INRES - Protokoll
Die Abbildung 9 stellt das zu testende Szenario dar: Der Sender fordert mit ICONreq eine
Verbindung an, die der Diensterbringer dem Empfänger mit ICONind anzeigt. Der Empfänger
antwortet mit ICONresp, der Sender erhält die Bestätigung mit ICONconf. Der
25

26
Softwaretest
Datenaustausch erfolgt mit der Nachricht IDATreq, welche als IDATind empfangen wird.
Mit der Nachricht IDISreq bzw. IDISind wird die Verbindung vom Empfänger wieder
geschlossen.
Abbildung 10 stellt den Testfall dar und zeigt den Nachrichtenaustausch zwischen Testsystem
und SUT. Ersterer besteht aus der MTC und zwei PTCs, die Sender und Empfänger
darstellen.
Zusätzlich werden Synchronisierungsnachrichten mit der MTC ausgetauscht, wie sie in
Kapitel 4.3 beschrieben sind. Diese dienen unter anderem der Sicherstellung der geforderten
Empfangsreihenfolge auf der Systeminstanz, die sonst aufgrund der partiellen Ordnungsrelation
der Ereignisse nicht gewährleistet ist. Da schon in Abbildung 9 eine totale
Ordnung der Ereignisse gegeben ist, dienen die Synchronisierungsnachrichten in diesem
Beispiel lediglich der Übermittlung des lokalen Testurteils (siehe Kapitel 4.3).
Abbildung 10 INRES - Testfall

Testing and Test Control Notation 3
Die oberste Ordnungseinheit in der TTCN-3 ist das Modul, darin sind alle folgenden Definitionen
enthalten.
module inres_module
{ …
}
Zu Beginn des Definitionsteils werden Porttypen mit den über sie austauschbaren Nachrichten
definiert. Über Ports kommunizieren die Testkomponenten untereinander, im Beispiel
sind das Ports für Nachrichten jeden Typs zwischen der MTC und den PTCs und
zwischen letzterem und der abstrakten SUT-Komponente.
/* Definitionsteil */
type port mtc2ptc_type message {
inout all ;}
type port ptc2mtc_type message {
inout all ;}
type port I_user_type2sut_type message {
inout all ;}
type port R_user_type2sut_type message {
inout all ;}
Unter Verwendung der Ports werden die Komponententypen definiert. Die Testkomponente
„inres_type“ stellt das Abstrakte Test System Interface dar (siehe Kapitel 2.3.4). Es
stellt intern die Schnittstelle zum SUT dar.
type component I_user_type {
port I_user_type2sut_type I_user_type2sut;
port ptc2mtc_type ptc2mtc; }
type component R_user_type {
port R_user_type2sut_type R_user_type2sut;
port ptc2mtc_type ptc2mtc; }
type component mtc_type {
port mtc2ptc_type mtc2ptc ;
var Sync PTCResult; }
type component inres_type {
port I_user_type2sut_type I_user_type2sut;
port R_user_type2sut_type R_user_type2sut; }
27

28
Softwaretest
Nach der Beschreibung der strukturellen Bestandteile des Tests folgt das Testverhalten.
Wie in Kapitel 2.3.6 beschrieben, wird zu Beginn eines Testfalls implizit die MTC erzeugt,
der Testfall „tc1“ startet auf der MTC des Typs „mtc_type“. Die abstrakte Testsystemschnittstelle
trägt stets den reservierten Schlüsselnamen „system“, welcher im Beispiel
vom Typ „inres_type“ ist.
/* MTC */
testcase tc1 runs on mtc_type system inres_type
{
var I_user_type I_user;
var R_user_type R_user;
I_user := I_user_type.create;
I_user.start(I_user_function());
R_user := R_user_type.create;
R_user.start(R_user_function());
Die MTC erstellt die PTCs, in diesem Fall die Sender- und Empfängerkomponente, und
startet auf ihnen Funktionen zur Testausführung, die im Anschluss an den Testfall definiert
sind. Im Anschluss startet der Nachrichtenaustausch, die Konstrukte „interleave“
und „alt“ sind in Kapitel 2.3.6 beschrieben. Nach Auslesen der – in den „sync“-
Nachrichten mitgeschickten – Testurteile setzt die MTC das globale Testurteil und protokolliert
die einzelnen Schritte mittels der „log“-Anweisung.
interleave{
[]mtc2ptc.receive(sync) from I_user {};
[]mtc2ptc.receive(sync) from R_user {};
}
mtc2ptc.send(sync_ack) to I_user;
alt{
[]mtc2ptc.receive(sync) from R_user -> value PTCResult{
if (PTCResult.report == “pass”){
setverdict(pass);
log(“I_user:ICONreq, pass”);
log(“R_user:ICONind, pass”); }
if (PTCResult.report == “fail”){
setverdict(fail);
log(“I_user:ICONreq, fail”);
log(“R_user:ICONind, fail”); }
}
[]mtc2ptc.receive from R_user {
setverdict(inconc);
log(“I_user:ICONreq, inconc”);

Testing and Test Control Notation 3
log(“R_user:ICONind, inconc”);
}
}
mtc2ptc.send(sync_ack) to R_user;
alt{
[]mtc2ptc.receive(sync) from I_user -> value PTCResult{
if (PTCResult.report == “pass”){
setverdict(pass);
log(“[R_user:ICONresp], pass”);
log(“[I_user:ICONconf], pass”); }
if (PTCResult.report == “fail”){
setverdict(fail);
log(“[R_user:ICONresp], fail”);
log(“[I_user:ICONconf], fail”); }
}
[]mtc2ptc.receive from I_user {
setverdict(inconc);
log(“[R_user:ICONresp], inconc”);
log(“[I_user:ICONconf], inconc”);
}
}
mtc2ptc.send(sync_ack) to I_user;
alt{
[]mtc2ptc.receive(sync) from R_user -> value PTCResult{
if (PTCResult.report == “pass”){
setverdict(pass);
log(“I_user:IDATreq, pass”);
log(“R_user:IDATind, pass”); }
if (PTCResult.report == “fail”){
setverdict(fail);
log(“I_user:IDATreq, fail”);
log(“R_user:IDATind, fail”); }
}
[]mtc2ptc.receive from R_user {
setverdict(inconc);
log(“I_user:IDATreq, inconc”);
log(“R_user:IDATind, inconc”);
}
}
mtc2ptc.send(sync_ack) to R_user;
interleave{
[]mtc2ptc.receive(sync) from R_user -> value PTCResult{
if (PTCResult.report == “pass”){
setverdict(pass);
log(“R_user:IDISreq, pass”); }
29

30
}
Softwaretest
if (PTCResult.report == “fail”){
setverdict(fail);
log(“R_user:IDISreq, fail”); }
}
[]mtc2ptc.receive(sync) from I_user -> value PTCResult{
if (PTCResult.report == “pass”){
setverdict(pass);
log(“[I_user:IDISind], pass”); }
if (PTCResult.report == “fail”){
setverdict(fail);
log(“[I_user:IDISind], fail”); }
}
}
stop;
In den folgenden zwei Funktionen ist das Testverhalten der PTCs beschrieben, zunächst
für den Sender, danach für den Empfänger. Mit den Anweisungen „connect“ und „map“
stellen die Testkomponenten gemäß der gewünschten Testkonfiguration die Verbindungen
zu der MTC und zur Testsystemschnittstelle her.
/* PTC I_user */
function I_user_function() runs on I_user_type {
connect(self:ptc2mtc, mtc:mtc2ptc);
map(self:I_user_type2sut, system: I_user_type2sut);
ptc2mtc.send(sync());
ptc2mtc.receive(sync_ack);
I_user_type2sut.send(ICONreq);
alt{
[]I_user_type2sut.receive(ICONconf){
ptc2mtc.send(sync(“pass”));
setverdict(pass) ;}
[]I_user_type2sut.receive {
ptc2mtc.send(sync(“fail”));
setverdict(fail) ;}
}
ptc2mtc.receive(sync_ack);
I_user_type2sut.send(IDATreq);
alt{
[]I_user_type2sut.receive(IDISind){
ptc2mtc.send(sync(“pass”));
setverdict(pass) ;}
[]I_user_type2sut.receive {
ptc2mtc.send(sync(“fail”));

Testing and Test Control Notation 3
}
setverdict(fail) ;}
}
disconnect(self:ptc2mtc, mtc:mtc2ptc);
unmap(self:I_user_type2sut, system: I_user_type2sut);
stop;
/* PTC R_user */
function R_user_function() runs on R_user_type {
connect(self:ptc2mtc, mtc:mtc2ptc);
map(self:R_user_type2sut, system: R_user_type2sut);
ptc2mtc.send(sync());
alt{
[]R_user_type2sut.receive(ICONind){
ptc2mtc.send(sync(“pass”));
setverdict(pass) ;}
[]R_user_type2sut.receive {
ptc2mtc.send(sync(“fail”));
setverdict(fail) ;}
}
ptc2mtc.receive(sync_ack);
R_user_type2sut.send(ICONresp);
alt{
[]R_user_type2sut.receive(IDATind){
ptc2mtc.send(sync(“pass”));
setverdict(pass) ;}
[]R_user_type2sut.receive {
ptc2mtc.send(sync(“fail”));
setverdict(fail) ;}
}
ptc2mtc.receive(sync_ack);
R_user_type2sut.send(IDISreq);
ptc2mtc.send(sync(“pass”));
disconnect(self:ptc2mtc, mtc:mtc2ptc);
unmap(self:R_user_type2sut, system: R_user_type2sut);
stop;
}
Nach Ausführung der Funktion trennen die Testkomponenten ihre Verbindungen zu anderen
Komponenten und stoppen.
Im Kontrollteil des Moduls wird der Testfall „tc1“ mit der Anweisung „execute“ gestartet.
31

32
/* Kontrollteil */
control{
execute(tc1());
}
2.3.8 TTCN Echtzeit- und Leistungserweiterungen
Softwaretest
Die TTCN wurde für den funktionalen Test entwickelt, so fehlen auch der neuesten Version
grundlegende Konzepte zum Test von zeitbezogenen Bedingungen.
In der TTCN-3 existiert lediglich ein Timerkonzept, welches das Einstellen einer maximalen
Wartezeit für das Eintreffen von Nachrichten ermöglicht. Durch den Einsatz eines
testfallweiten Timers lassen sich so effektiv blockierende Testfälle verhindern, die auf
eine (verloren gegangene) Nachricht warten. Für die Spezifikation von Echtzeitanforderungen
ist der Timer jedoch aus mehreren Gründen ungeeignet.
Die Geschwindigkeit der Konsumierung eines Timeouts hängt direkt von der in Kapitel
2.3.6 beschriebenen „snapshot“-Semantik ab. Hier kommt die Trägheit dieses Konzepts
zum Tragen, da das Bilden eines Schnappschusses eine unbestimmte Zeit braucht, diese
nur in nicht vorhersagbaren zeitlichen Abständen getätigt werden und die Reihenfolge der
Verzweigungen in der „alt“-Anweisung von hoher Bedeutung ist. Des Weiteren besitzt
jeder Testfall eine Timeout-Liste, in die sich ein ausgelaufener Timer einträgt und die bei
Bedarf durchsucht wird. Die Suchreihenfolge innerhalb dieser Liste ist nicht spezifiziert,
die benötigte Zeit daher nicht vorhersagbar.
Ein weiterer Nachteil des Timers ist die Begrenztheit auf eine Testkomponente. Eine
Echtzeitanforderung über mehrere Komponenten hinweg ist hiermit prinzipbedingt nicht
testbar.
PerfTTCN
Daher wurden schon für die Vorgängerversion TTCN-2 Vorschläge veröffentlicht, die
Sprache diesbezüglich zu erweitern. PerfTTCN [SSR97] beschreibt nötige Konzepte zur
Durchführung von Leistungstests mit der TTCN-2. Die Testkonfigurationen werden um
eine Beschreibung der vorherrschenden Last erweitert, welche in Hintergrund- und Vordergrundlast
unterteilt ist. Neu ist insbesondere die Erzeugung und Kontrolle der Hintergrundlast,
um das gewonnene Testurteil bezüglich der genauen Lastsituation bewerten zu
können. Zweitens wird ein mächtigeres Verkehrsmodell eingeführt, um diskrete und kontinuierliche
Datenströme zu beschreiben. Daneben kann für definierte Messpunkte die zu
messende Metrik deklariert werden, z.B. die Verzögerungszeit, der Jitter oder der Durch-

Testing and Test Control Notation 3
satz. Statistische Indikatoren (z.B. min, max, mean) ergänzen die Metriken. Abschließend
erweitert PerfTTCN das Testurteil für den Leistungstest. Die Beschreibung der PerfTTCN
blieb jedoch syntaktischer Natur und wurde nicht praktisch umgesetzt.
RT-TTCN
Ein weiterer Vorschlag zur Echtzeiterweiterung der TTCN-2 trägt den Namen RT-TTCN
[WG99]. Damit können die TTCN-2-Anweisungen um die Angabe eines Zeitintervalls
erweitert werden, welches die früheste und die späteste erlaubte Ausführung kennzeichnet.
Zusätzlich wurde die Sprache durch die Abbildung auf ein „Timed Transition System“
formalisiert. Bei praktischen Umsetzungen hat sich jedoch gezeigt, dass Benutzer
mit der Handhabung der Zeitintervalle Probleme hatten, da Zeitpunkte relativ zu vorherigen
Ereignissen angegeben werden. Dies führte zu einer schlechten Akzeptanz und verhinderte
einen größeren Erfolg der RT-TTCN.
TimedTTCN-3
Für die TTCN-3 existiert mit der TimedTTCN-3 [Neu04] ebenfalls eine Erweiterung zur
Beschreibung von Echtzeitanforderungen. Wie in der PerfTTCN wird das Testurteil um
einen neuen Wert erweitert, der im Falle eines funktionalen „pass“ und eines nichtfunktionalen
„fail“ gesetzt wird. Eine wesentliche Erweiterung stellt das Bereitstellen
einer Systemuhr dar, die das Abrufen der absoluten Zeit ermöglicht. Dies löst – zumindest
konzeptionell – das Problem der Überprüfung von Zeitanforderungen über mehrere Testkomponenten
hinweg. Ein Aufruf der Operation „now“ liefert die lokale Uhrzeit zurück,
die Operation „resume“ ermöglicht das Setzen von Wartezeiten. Sogar das Synchronisationsproblem
unterschiedlicher Systemuhren wird durch ein eingeführtes Attribut „timezone“
angegangen. Gemessene Zeiten dürfen nur dann in Relation gesetzt werden, wenn
sie der gleichen „Zeitzone“ entspringen. Dies ermöglicht die Kennzeichnung nichtsynchroner
Uhren.
Zur Evaluierung der Echtzeiteigenschaften bietet die TimedTTCN-3 zwei Möglichkeiten.
Eine Onlineüberprüfung muss in der Testsprache selbst durch Funktionen durchgeführt
werden, die z.B. in einer Funktionsbibliothek bereitgestellt werden können. Zur nachträglichen
(Offline-)Überprüfung können gesicherte Zeitstempel in Protokolldateien ausgewertet
werden. Das nur ungenau beschriebene Logging-Konzept der TTCN-3 wird daher
erweitert. Dies geschieht insbesondere durch eine stärkere Formalisierung der Syntax und
Struktur der Logdateien und durch Zugriffsmöglichkeiten aus den Testkomponenten bzw.
dem Kontrollteil heraus.
33

34
Softwaretest

3 Die Unified Modeling Language 2
Das folgende Kapitel gibt einen Überblick über die UML in der Version 2. Genauere Erläuterung
finden nur die in dieser Arbeit relevanten Teile. Umfassende Informationen
geben unter anderem [OMG06a-f, OMG07a-c, RJB04, JRH+04, Dou04].
Die UML ist eine Sprachenfamilie und dient in der Softwareentwicklung der Dokumentation,
Spezifikation, Modellierung und Visualisierung. Sie vereint verschiedene Notationsmöglichkeiten
sowohl für statische als auch dynamische Aspekte eines Systems. Die
Sprache ist bewusst allgemein gehalten, sie ist weder auf ein bestimmtes Anwendungsgebiet
noch auf einen bestimmten Entwurfsprozess hin ausgerichtet. Der Fokus liegt jedoch
auf objektorientierten Vorgehensweisen.
3.1 Historie
Die UML bekam ihren Namen erstmals 1996 mit dem Zusammenschluss dreier Modellierungsansätze
in der Softwareentwicklung. Rumbaugh und Booch vereinten 1995 ihre
OMT und OOD genannten Methoden zunächst zur „Unified Method“, ein Jahr später kam
OOSE von Jacobson dazu. Nach einem Vereinheitlichungsprozess veröffentlichten sie
1997 die UML 1.0 [JRH+04].
Bis zur Version 1.5 im Jahre 2003 hat die Sprache viele Erweiterungen und Veränderungen
erfahren. Die „Object Constraint Language“ (OCL) wurde in die UML 1.1 integriert,
um den Ausdruck formaler konsistenzsichernder Einschränkungen zu ermöglichen. Die
„XML Metadata Interchange“ (XMI) (siehe Kapitel 3.5) wurde Bestandteil der UML 1.3
und ermöglichte eine standardisierte textuelle Notation der graphischen Elemente. 1999
mit der Version 1.3 übergaben die drei Sprachgründer das Copyright an die „Object Management
Group“ (OMG 1 ), einem Industriegremium mit mehreren hundert Mitgliedern.
Nach der Version 1.5 verabschiedete die OMG im Jahre 2005 die finale Fassung der Version
2.0, welche eine große Überarbeitung darstellt. Wichtigste Ziele waren eine größere
Kompaktheit, die Präzisierung der Semantik [ECM+99] und die Abwärtskompatibilität.
Mit ersterem sollte der Vorwurf der zu großen Komplexität begegnet werden. In die Semantikpräzisierung
gingen insbesondere Arbeiten der „precise UML group 2 “ ein, einer
1 http://www.omg.org
2 http://www.puml.org
35

36
Die Unified Modeling Language 2
offenen internationalen Arbeitsgruppe zur Stärkung der UML-Semantik. Dies ist eine
Voraussetzung für die Realisierung der Idee ausführbarer Modelle, die sich bei der OMG
in der „Model Driven Architecture“ (MDA) manifestiert hat.
Im April 2006 veröffentlichte die „Revision Task Force“ der UML – die verantwortliche
Gruppe für die Pflege und Weiterentwicklung der Sprache – eine Vorabversion der UML
2.1 [OMG06a, OMG06f]. Sie enthält kleine Detailverbesserungen und Fehlerkorrekturen.
Im Februar 2007 folgte die endgültige Verabschiedung unter der Versionsnummer 2.1.1
[OMG07a, OMG07b].
Die UML2 besteht aus zwei Teilstandards, dem „Infrastructure“- [OMG07b] und dem
„Superstructure“-Dokument [OMG07a]. Die Infrastructure definiert Basisklassen und
grundlegende Sprachkonstrukte, die die Grundlage für die Superstructure bilden. Im letzteren
werden die Diagrammtypen, ihre Semantik und die Notation definiert.
Ergänzt wird die Sprachenspezifikation durch eine überarbeitete Version der OCL
[OMG06e] und eine gänzlich neue Spezifikation – die „Diagram Interchange“
[OMG06d]. Diese stellt ein Erweiterungspaket für das UML-Metamodell dar, welches
jedes Modellelement um die Fähigkeit erweitert, graphische Informationen zu beschreiben.
Dadurch ist es erstmalig möglich, UML-Modelle nicht nur durch ihre Modellinformationen,
sondern auch mit graphischen Informationen standardkonform mit der XMI
auszutauschen.
Um eine konsistente deutsche Namensgebung für die zahlreichen UML-Begriffe zu gewährleisten,
wird im Folgenden auf die englisch-deutsche Übersetzungsliste von Bernd
Oestereich et.al. 1 zurückgegriffen, der sich zahlreiche Autoren und Verlage angeschlossen
haben. Diese haben sich zur Verwendung der enthaltenen Namensgebung in ihren
aktuellen und zukünftigen Veröffentlichungen verpflichtet.
3.2 Metamodell
Die Metamodellierung ist ein grundlegendes Konzept der UML und unabdingbar für ihr
Verständnis. Ein Metamodell ist die Abstraktion eines konkreten Modells durch eine Instanz-Typ-Relation.
Dieser Abstraktionsvorgang ist beliebig häufig wiederholbar, das
Metamodell des einen Modells kann zugleich konkrete Ausprägung eines Meta-
Metamodells sein.
1 http://www.jeckle.de/uml.de

Metamodell
Um die Interoperabilität zwischen Metamodellen oder allgemeinen Metadaten zu gewährleisten,
stellt die „Meta Object Facility“ (MOF) [OMG06b] ein Rahmenwerk zur Verfügung,
das als Grundlage für die Entwicklung von modell- und metadatengestützten Systemen
dient. Zum Grundkonzept der MOF gehören das Objekt, die Klasse und die Navigierbarkeit
einer Instanz zu seiner Klasse. Damit lassen sich beliebig viele Metaebenen
beschreiben, mindestens jedoch zwei (repräsentiert durch die Instanz- und Klassenebene).
Seit 1997 mit der Version 1.1 ist die UML-Spezifikation ein MOF-Modell und in eine
Vier-Ebenen Hierarchie eingebettet, die mit M0 bis M3 nummeriert sind. Die MOF steht
als Meta-Metamodell (M3) an deren Spitze, darunter bilden Sprachenspezifikationen die
Metaebene (M2). Die UML-Spezifikation ist eine davon, das „Common Warehouse Model“
(CWM) eine weitere. Die Benutzerspezifikationen bzw. die Benutzermodelle (M1)
ordnen sich auf der Modellebene ein, während Laufzeit-Instanzen die sog. Objektebene
(M0) darstellen. Abbildung 11 stellt die vier Ebenen in einem Beispiel dar.
M3
(MOF)
M2
(UML)
M1
(Benutzermodell)
M0
(Laufzeit-Instanzen)
Class
Attribute Class Instance
Video
+Titel: string
einVideo
classifier
:Video
Titel=„Casablanca“
Abbildung 11 Vier-Ebenen Hierarchie der UML, nach [OMG07b]
Wie die deutsche Sprache in der deutschen Sprache beschrieben ist, so wird die UML in
der UML beschrieben. Die Semantik eines UML-Modells wird durch das UML-
Metamodell definiert, dies fördert das Verständnis und die Anschaulichkeit der Beschreibung.
Dieses Konzept ist für den Vorwurf der informalen Semantik zuständig, da es kein
rigoroses mathematisches Beschreibungsmittel darstellt wie ein ASM, Z, etc. Aus dem
37

38
Die Unified Modeling Language 2
UML-Lager wird diesem Vorwurf mit zwei Argumenten begegnet. Zum einen verhindert
das Metamodell nicht die Erstellung einer zusätzlichen vollständigen formalen Spezifikation.
Auf der anderen Seite sei diese Erstellung ein sehr komplexes Unterfangen, ohne
daraus bedeutende Vorteile zu gewinnen.
3.3 Infrastructure
Die Infrastructure [OMG07b] beschreibt die architektonische Grundlage der UML und
besteht aus zwei Teilen, dem „Core“- und dem „Profiles“-Paket. Letzteres beschreibt
Konzepte zur Erweiterung und Anpassung von Metamodellen. Das zentrale Gerüst der
Infrastructure-Spezifikation stellt jedoch das Core-Paket dar. Dieses dient einem wichtigen
Entwurfsziel der UML2, der Harmonisierung der Sprachenarchitekturen der UML
und MOF.
Dem wurde auf zweierlei Weise Rechnung getragen: Zum einen wurden Kernelemente
beider Sprachen zusammengefasst und im „Core“ definiert. Das Paket stellt ein kompaktes
und speziell auf Wiederverwendbarkeit ausgelegtes Metamodell dar. Andere Metamodelle
können Teile des Core-Metamodells importieren, spezialisieren oder instanziieren.
Nun basieren sowohl die MOF als auch die UML-Superstructure auf der Infrastructure-
Spezifikation, deren Verwendung jedoch unterschiedlich ist, da sie auf verschiedenen
Metaebenen (siehe Abbildung 11) angesiedelt sind. Die MOF importiert Infrastructure
Metaklassen, die UML Superstructure enthält Instanzen dieser Klassen und fügt neue
Eigenschaften hinzu. Damit stellt das Core-Paket das Kernstück der gesamten MOF-
Hierarchie dar. Die Abbildung 12 illustriert diesen Umstand und zeigt die Abhängigkeit
sowohl der Metasprachen UML und CWM als auch der Meta-Metasprache MOF und
weiterer Profil-Erweiterungen vom Core-Paket.
Abbildung 12 Die Rolle des „Core“-Pakets im MOF-Umfeld [OMG07b]

Superstructure
Die zweite Harmonisierungsmaßnahme war die Sicherstellung, dass die UML eine MOF-
Instanz ist. Jedes UML-Element ist die Instanz genau einer MOF-Klasse und die Instanz
eines Infrastructure-Elements.
Weiterhin beschreibt die Infrastructure nötige Metaklassen zur Erzeugung von Metamodellen.
Dies geschieht durch Instanziierung der Metaklassen aus der Infrastructure, d.h.
sie definiert Metaklassen zur Instanziierung von Elementen der UML, MOF, CWM und
der Infrastructure-Klassen selbst. Sie besitzt damit die selbstbeschreibende Eigenschaft.
Die MOF führt diese Instanziierungen durch, indem sie die Metaklassen der Infrastructure
verwendet und ist damit auch selbstbeschreibend. Damit kann sie die Vier-Ebenen-
Hierarchie nach oben abschließen, da sie alle Metaklassen enthält, um sich selbst zu definieren.
3.4 Superstructure
Für den Modellierer ist insbesondere das Superstructure-Dokument [OMG07a] von Bedeutung,
da es die Klassen der M2-Ebene beschreibt. Diese können in Benutzermodellen
instanziiert werden und mittels vorgegebener Notation graphisch angezeigt werden.
Die Spezifikation beschreibt das Metamodell strukturiert anhand von 13 Diagrammtypen,
die wiederum in sechs Struktur beschreibende Diagramme und sieben Verhaltensdiagramme
geordnet sind (Abbildung 13). Der Modellierer kann somit verschiedene Sichten
auf ein System beschreiben und die Diagrammtypen auswählen, die am besten geeignet
erscheinen.
Abbildung 13 UML2-Diagrammtypen, nach [JRH+04]
39

40
3.4.1 Diagrammtypen
Die Unified Modeling Language 2
Im Folgenden werden die Beschreibungsmöglichkeiten jeden Typs kurz erläutert, beginnend
mit den Strukturdiagrammen.
Das Klassendiagramm ist die meistgenutzte Modellsicht der UML. Der Aufbau eines
Systems wird durch die Gesamtheit aller Klassen und der Beschreibung ihrer Beziehungen
zueinander beschrieben. Neben den Strukturinformationen werden auch die Datentypen
definiert.
Das Objektdiagramm gibt eine konkrete Ausprägung eines Systems zur Laufzeit wieder.
Es stellt eine Momentaufnahme zu einem Ausführungszeitpunkt dar.
Das Paketdiagramm ermöglicht eine Strukturierung des Systems durch Bildung von Einheiten
(von z.B. mehreren Klassen oder Komponenten). Durch eine beliebig tiefe Hierarchiebildung
bleibt die Überschaubarkeit von komplexen Systemen erhalten.
Das Kompositionsstrukturdiagramm ist in der UML2 neu hinzugekommen und wird auch
als Architekturdiagramm bezeichnet. Damit wurde das „Capsule Collaboration Diagramm“,
das im UML RT-Profil eingeführt wurde, in den Standard übernommen. Die
Architektur bzw. der Aufbau eines Classifiers kann hiermit ähnlich der „Specification and
Description Language“ (SDL) [ITU99] in hierarchischer Form spezifiziert werden.
Das Komponentendiagramm stellt wie das Objektdiagramm das System zur Laufzeit dar,
abstrahiert jedoch von Details und fokussiert Kommunikationsbeziehungen der einzelnen
Komponenten.
Das Verteilungsdiagramm verdeutlicht durch die Darstellung von Hard- und Softwarekomponenten
deren Verteilung. Die Beziehungen zwischen den Hardwareknoten heben
die möglichen Kommunikationswege hervor.
Zur Verhaltsbeschreibung existieren folgende Diagramme in der UML:
Das Aktivitätsdiagramm veranschaulicht Prozessabläufe durch eine zeitliche Verkettung
von Einzelaktionen. Die Ablaufbedingungen sind durch eine Token-Semantik ähnlich der
von Petrinetzen gegeben.

Superstructure
Die Interaktionsdiagramme modellieren das Interaktionsverhalten von Objekten. Zur
Betonung unterschiedlicher Aspekte stehen folgende fünf Diagrammtypen zur Verfügung:
Das Sequenzdiagramm ist das meistgenutzte Interaktionsdiagramm und hebt die zeitliche
Reihenfolge der Kommunikation zwischen Objekten hervor. Es besitzt alle relevanten
Notationselemente der „Basic Message Sequence Charts (bMSC)“ [ITU96]. Das Kapitel
3.6 widmet sich dem Sequenzdiagramm im Detail.
Das Interaktionsübersichtsdiagramm ist neu in die UML2 hinzugekommen und gibt einen
Überblick über den Kontrollfluss von Interaktionen. Es stellt eine Variante des Aktivitätsdiagramms
dar und übernahm viele Konzepte der „High Level MSCs“ [ITU96].
Das Kommunikationsdiagramm entspricht dem einfachen Sequenzdiagramm mit einer
Betonung der Architektur und der inneren Struktur.
Das Timingdiagramm wurde aus der Welt der Digitaltechnik neu hinzugenommen, es
fokussiert die Zeit, Abläufe sind an einer Zeitachse aufgetragen.
Der Anhang der Superstructure-Spezifikation enthält eine weitere optionale Darstellungsform
für Interaktionen. In der Interaktionstabelle kann das Kommunikationsverhalten in
tabellarischer Form aufgetragen werden.
Das Anwendungsfalldiagramm (Use-Case-Diagramm) stellt Anwendungsfälle und die mit
diesen in Verbindung stehenden externen Kommunikationsteilnehmer dar. Das System
stellt eine Black-Box dar, dessen extern sichtbares Verhalten durch ein Statechart, ein
Aktivitäts- oder ein Interaktionsdiagramm beschrieben werden kann.
Das Statechart stellt eine Erweiterung der Mealy- und Moore-Automaten dar und geht auf
Arbeiten von D. Harel [Har87] zurück. Kurz gefasst stellen Statecharts konventionelle
Zustandsautomaten dar, die um drei Konzepte erweitert wurden.
Das erste ist die Hierarchie, also die Möglichkeit, hierarchische Zustände in beliebiger
Tiefe zu erstellen. Ein sog. zusammengesetzter Zustand kann also wiederum ein Statechart
enthalten. Die Nebenläufigkeit stellt die zweite Erweiterung dar. Dies ermöglicht
die Beschreibung von beliebig vielen nebenläufig agierenden Zustandsmaschinen. In der
UML wird das Konzept durch „Regionen“ realisiert. In einer Region befindet sich genau
ein Zustandsautomat, diese können in orthogonalen Zuständen zusammengesetzt werden
und nebenläufig agieren. Das dritte neue Konzept sind erweitere Kommunikationsmöglichkeiten,
insbesondere ein Broadcastmechanismus zwischen nebenläufigen Komponenten.
41

42
Die Unified Modeling Language 2
Eine spezielle Variante ist der Protokoll-Zustandsautomat, der speziell zur Spezifikation
von Kommunikationsprotokollen geeignet ist. Er beschreibt ausschließlich erlaubte Aufrufreihenfolgen
von Operationen, was der einfachen Definition eines Protokolls entspricht.
Der Protokollzustandsautomat unterscheidet sich von den Verhaltenszustandsautomaten
in zwei Punkten. Protokollzustände können neben ihren Namen zusätzlich Invarianten
enthalten, durch die sie definiert sind. Der zweite Unterschied ist das Fehlen jeglicher
Aktivitäten in den Zuständen.
Der Protokollzustandsautomat besteht also nur aus Zuständen, die durch Invarianten definiert
sind, und aus Operationen, die durch Vor- und Nachbedingungen eingeschränkt
sind. Abbildung 14 zeigt die Syntax der Protokolltransition.
Abbildung 14 Protokolltransition
3.5 XML Metadata Interchange (XMI)
Die XMI ist das Austauschformat für Modelle der MOF und aller von ihr abgeleiteten
Sprachen. Die Motivation war die Modellbeschreibung in einer herstellerunabhängigen
Notation zum Austausch zwischen beliebigen UML-Werkzeugen. Sie ist von der OMG
standardisiert und basiert auf der „Extensible Markup Language“ (XML) [W3C04a]. Mit
Hilfe der XML lassen sich beliebige hierarchische Auszeichnungssprachen beschreiben,
so sind z.B. die Namen der „Tag“-Bezeichner, deren Anordnung oder die Wertebereiche
von Daten frei wählbar.
Um einen sinnvollen Datenaustausch mit einer XML-Sprache zu ermöglichen, ist es notwendig,
diese Freiheiten einzuschränken und eine Grammatik zu definieren, die für einen
bestimmten Anwendungszweck „gültige“ Dokumente beschreibt. Das „World Wide Web
Consortium“ (W3C) sieht für deren Definition zwei Möglichkeiten vor, mit einer „Document
Type Definition“ (DTD) [W3C04a] oder mit einem XML-Schema [W3C04b]. Für
eine Diskussion der Vorteile letzterer und der konzeptuellen Unterschiede sei auf umfangreiche
XML-Literatur hingewiesen [W3C04b, BDD+01].
Da die XMI als Austauschformat für alle auf MOF basierenden Sprachen konzipiert ist,
enthält deren Spezifikation zwei Teile:
- Produktionsregeln zur Erzeugung von XML-DTDs bzw. XML-Schematas aus
XMI-kodierten Metadaten

XML Metadata Interchange (XMI)
- Produktionsregeln zur Erzeugung von XML-Dokumenten, um Metadaten in einem
XMI-kompatiblen Format zu kodieren
Abbildung 15 XMI in der Vier-Ebenen-Hierarchie, nach [Jec04]
Abbildung 15 zeigt die XMI in der 4-Ebenen-Hierarchie der UML. Auf jeder Ebene kann
nach der XMI-Spezifikation ein XML-Schema erzeugt werden. Diese können zur Konformitätsprüfung
der XML-Dokumente verwendet werden, in denen die Modelle serialisiert
sind.
Versionen
Die erste finale Version der XMI wurde im Jahre 2000 für die MOF 1.1 verabschiedet.
Die XMI 1.0 verzichtete fast gänzlich auf den Gebrauch von XML-Attributen. Die XMI
1.1 machte von ihnen stärker Gebrauch und führte die XML-Namespaces ein. Bis zur
XMI-Version 1.2, die für die MOF 1.4 aktualisiert wurde, wurden ausschließlich Produktionsregeln
für DTDs beschrieben. 2003 wurde mit der XMI 1.3 die Schema-
Unterstützung nachgereicht. Im gleichen Zeitraum wurde das Dokumentenformat stark
überarbeitet und inklusive Schema-Unterstützung der Versionssprung auf die 2.0 vollzogen
[OMG05c].
43

44
Die Unified Modeling Language 2
Für die MOF 2.0, welche das Metamodell der UML2 ist, wurde die XMI wiederum bezüglich
Struktur und Lesbarkeit überarbeitet. Anfangs bezeichnete man diese Version als
„XMI 2.0 für MOF 2.0“, was jedoch zur Verwechslung mit der früheren Fassung führte.
Die erste MOF 2.0 (und damit UML2) kompatible Version ist die XMI 2.1 [OMG05d].
3.6 Sequenzdiagramme
Die UML2 definiert Konzepte zur Beschreibung von Interaktionen, d.h. für die Kommunikation
von Instanzen, die ihrerseits Verhalten realisieren. Interaktionen sind im Allgemeinen
sowohl für Systementwickler als auch für Endnutzer verständlich, sie finden daher
in vielen Entwicklungsphasen Verwendung. Von abstrakt gehaltenen Situationsbeschreibungen
bis hin zur Darstellung präziser Interprozesskommunikation oder der Aufzeichnung
einer Ablaufspur werden Interaktionsbeschreibungen für verschiedene Ziele
eingesetzt.
Je nach Situation und Kontext sind gewisse Interaktionskonzepte von besonderer Bedeutung
oder im Gegenteil vernachlässigbar. Aus diesem Grund stehen dem Modellierer fünf
Diagrammtypen zur Verfügung, um die relevanten Teilaspekte zu verdeutlichen. Eine
Auflistung dieser Diagrammformen inklusive einer Kurzbeschreibung findet sich in Kapitel
3.4.1. Dieser Abschnitt beschreibt das Sequenzdiagramm, den wichtigsten und umfangreichsten
Vertreter zur Beschreibung von Interaktionen.
Das Sequenzdiagramm ist die am stärksten überarbeitete und erweiterte Diagrammart der
neuen UML-Version. Ein großes Manko der UML-1.x-Sequenzdiagramme war ihre Ausdrucksschwäche
durch das Fehlen wichtiger Konzepte. Sie konnte sich daher nie gegen
die „Message Sequence Charts“ (MSC) [ITU96] durchsetzen, die im Bereich der Telekommunikation
eine etablierte Spurenbeschreibungssprache ist. In der überarbeiteten
Version der Sequenzdiagramme sind nun alle relevanten Elemente der MSCs hinzugefügt
worden. Ein Vorteil der ITU-Sprache bleibt jedoch weiterhin ihre vollständig formale
Grammatik.
Ein Sequenzdiagramm beschreibt eine Spur, d.h. eine Folge von Ereignissen. Diese Spur
kann eine erlaubte oder eine verbotene Abfolge von Ereignissen des beschriebenen Systems
sein. Die Vereinigungsmenge der legalen und illegalen Spuren beschreibt die Interaktionssemantik,
sie umfasst jedoch nicht notwendigerweise die Gesamtheit aller möglichen
Interaktionen. Über nicht beschriebene Spuren kann keine Aussage getroffen werden,
sie können sowohl legale als auch nicht legale Ereignisabfolgen darstellen. Zwei

Sequenzdiagramme
Interaktionen sind dann äquivalent, wenn ihre Menge der legalen und illegalen Spuren
gleich sind.
Die Spuren besitzen eine „Interleaving“-Semantik, d.h. bei der Vereinigung zweier oder
mehrerer Spuren bleibt die Reihenfolge der Ereignisse pro Spur erhalten, die Ereignissequenz
verschiedener Spuren ist unbestimmt. Wichtig ist das Fehlen „echter“ Parallelität,
Ereignisse treten immer sequentiell auf. Die Beschreibung einer Quasi-Parallelität ist
durch die Angabe aller möglichen Reihenfolgen möglich.
Eine Spur beschreibt ohne Verwendung erweiterter Elemente eine partielle Ordnung der
Ereignisse, d.h. es sind nur zwei Aussagen über die Ereignis-Reihenfolge erlaubt:
Entlang jeder Lebenslinie sind Ereignisse strikt geordnet und der Empfang einer Nachricht
erfolgt stets nach deren Versenden. Aussagen darüber hinaus sind nicht möglich. Zur
Beschreibung alternativer Ordnungen ebenso wie zur Kontrollflusssteuerung stellt die
UML Beschreibungsmöglichkeiten zur Verfügung, sog. „Kombinierte Fragmente“. In
[HHR+05] findet sich eine genaue Betrachtung der Spurensemantik der Sequenzdiagramme
inklusive ihrer kombinierten Fragmente.
Kombinierte Fragmente
Interaktionsfragmente, d.h. Ausschnitte einer Interaktion, können unterschiedlich miteinander
kombiniert werden. Die Fragmente stellen die Operanden dar, ein Operator bestimmt
die Art der Kombination.
Die UML2 definiert folgende Operatoren:
• Die lose Ordnung („weak sequencing“) entspricht der partiellen Ordnungsrelation,
d.h. es sind lediglich zwei Aussagen über die Ereignisreihenfolge möglich: (1) ein
Sendeereignis findet immer vor dem korrespondierenden Empfangsereignis statt,
(2) entlang einer Lebenslinie sind die Ereignisse zeitlich von oben nach unten geordnet.
Die lose Ordnung kann explizit angegeben werden, bei Fehlen jeglichen
Operators gilt sie implizit.
• Die strenge Ordnung („strict sequencing“) modelliert einen chronologischen Ablauf
der Ereignisse, der durch ihre vertikale Position gegeben ist. Diese bestimmen
die Ereignisreihenfolge bezüglich des gesamten kombinierten Fragments, nicht
nur auf einer Lebenslinie.
45

46
Die Unified Modeling Language 2
• Ein paralleles Fragment („par“) stellt die parallele Verschmelzung dar und entspricht
einer Verschränkung der Operanden. Die Ereignisse verschiedener Operanden
können in beliebiger Reihenfolge auftreten, die zeitliche Ordnung innerhalb
der Operanden bleibt von der Verschränkung unberührt, d.h. ohne weitere
Angabe eines Operators gilt die standardmäßig geltende lose Ordnung. Beschränken
sich die Ereignisse, für die die zeitliche Reihenfolge nicht signifikant ist, auf
eine Lebenslinie, dann gibt es als graphische Kurznotation die Coregion. Jede Coregion
kann demnach auch als paralleles Fragment dargestellt werden, indem jedes
Ereignis der Coregion als eigener Operand eines parallelen kombinierten
Fragments dargestellt wird.
• Die Alternative („alt“) stellt den Auswahloperator dar, der nach Auswertung der
explizit bzw. implizit gegebenen Bedingungen maximal einen Operanden auswählt.
• Das optionale Fragment („opt“) stellt ein mögliches Verhalten dar und entspricht
semantisch einem alternativen Fragment mit nur einem Operanden.
• Das Abbruchfragment („break“) stellt zwei alternative Fragmente dar, mit der
Auswahl zwischen der Fortsetzung ohne Durchführung des Abbruchfragments,
oder das Ausführen des Abbruchfragments und anschließendem Beenden des umschließenden
Fragments.
• Die Schleife („loop“) bezeichnet die Wiederholung des Fragments, deren Anzahl
unbeschränkt oder durch eine untere und obere Schranke angegeben wird. Zudem
kann ein boolscher Ausdruck definiert werden, der nach Erreichen der unteren
Schranke vor jeder weiteren Iteration ausgewertet wird. Die einzelnen Schleifendurchgänge
sind mit einer losen Ordnung verbunden.
• Mittels der Negation („neg“) werden illegale Spuren beschrieben, d.h. der beschrieben
Ablauf ist nicht erlaubt.
• Der kritische Bereich („critical“) enthält eine Interaktion, die nicht verschränkbar
ist, d.h. die enthaltene Spur muss atomar behandelt werden
• Der Operator zum Ignorieren („ignore“) enthält eine Liste von Nachrichten, die
im Operanden nicht aufgeführt sind. Der UML-Standard beschreibt zwei unter-

Sequenzdiagramme
schiedliche Semantiken. Entweder gelten diese Nachrichten als unwichtig, was ihre
Ignorierung beim etwaigen Auftreten zur Folge hat. Alternativ kann dies bedeuten,
dass die Nachrichten in der Spur zu jedem Zeitpunkt auftreten können.
• Für relevante Nachrichten („consider“) kann eine Liste an Nachrichten erstellt
werden, die von Bedeutung sind. Der Operator stellt das Gegenstück zum letztgenannten
dar und ist äquivalent zu einer „ignore“-Liste aller nicht aufgeführten
Nachrichtentypen.
• Die Sicherstellung („assert“) betont die enthaltene Interaktion als einzig erlaubte
Fortsetzung der Spur, jede andersartige Ereignisabfolge ist illegal.
Weitere wichtige Konzepte
• Um zwei Ereignisse explizit in eine zeitliche Relation zu setzen, kann eine binäre
Ordnungsbeziehung („general ordering“) festgelegt werden. Der Pfeilkopf innerhalb
der gepunkteten Linke zeigt vom zeitlich früheren zum später auftretenden
Ereignis. Abbildung 16 beschreibt das Versenden der Nachricht „m1“ vor der
Nachricht „m2“.
Abbildung 16 Ordnungsbeziehung
Die folgenden zwei Konzepte dienen der besseren Übersichtlichkeit und unterstützen die
Wiederverwendbarkeit wiederholender Interaktionsfragmente.
• Die Interaktionsreferenz („interaction use“) substituiert eine Interaktion durch ihre
Referenz. Eine Interaktion kann an mehreren Stellen referenziert werden und bildet
durch die mögliche Angabe von Ein- und Ausgabeparametern einen synchronen
Operationsaufruf nach. Abbildung 17 referenziert das Sequenzdiagramm
„Login“ und setzt an dessen Ende mit der Nachricht „m1“ fort.
47

48
Abbildung 17 Interaktionsreferenz
Die Unified Modeling Language 2
• Die Verwendung von Sprungmarken („continuation“) ist nur in alternativen
Fragmenten erlaubt. Sie stellen eine syntaktische Möglichkeit dar, Operanden an
beliebiger Stelle fortzusetzen. Startmarken befinden sich an letzter, Zielmarken an
erster Stelle eines Operanden, wobei mehrere Start- auf eine Zielmarke weisen
dürfen.
• Der Dekompositionsoperator („part decomposition“) beschreibt eine Lebenslinie
mit einer internen Struktur. So kann durch die Zerlegung einer Lebenslinie die innere
Kommunikation beschrieben werden. Die Abbildung 18 links beschreibt einen
Nachrichtenaustausch mit einer Systeminstanz, welche aus mehreren Lebenslinien
des „Zugangsmoduls“ besteht (siehe Abbildung 18 rechts).
Abbildung 18 Dekomposition
• Zustandsinvarianten („state invariant“) werden auf Lebenslinien platziert und beschreiben
Bedingungen, die von den Kommunikationspartnern zur Laufzeit geprüft
werden. Die Auswertung findet unmittelbar vor dem Auftreten des nächsten
Ereignisses statt. Wird die Bedingung erfüllt, so gilt die Spur als erlaubt, eine unerfüllte
Bedingung kennzeichnet die sie enthaltende Spur als unerlaubt. Für die

Sequenzdiagramme
Zustandsinvarianten sind drei Notationsmöglichkeiten vorgegeben, in einem angehefteten
Notizfeld, als boolesche Bedingung in geschweiften Klammern und in
einem Zustandssymbol. Letzteres entspricht der Überprüfung des (internen oder
extern sichtbaren) Zustands des Objekts, welches durch die Lebenslinie dargestellt
wird. Abbildung 19 zeigt exemplarisch die zwei letztgenannten Darstellungsformen
von Zustandsinvarianten.
Abbildung 19 Zustandsinvarianten
• Der Ausführungsfocus („execution occurrence“) beschreibt die Ausführung eines
Verhaltens oder einer Aktion auf einer Lebenslinie. Typischerweise korrespondiert
der Empfang bzw. das Senden einer Nachricht mit dem Start bzw. Ende einer
Ausführungsspezifikation. Dargestellt wird er als ein dünnes Rechteck auf der Lebenslinie,
wie Abbildung 20 beispielhaft zeigt. Alternativ kann das Rechteck breiter
ausfallen, um die ausgeführte Aktion darin zu benennen.
Abbildung 20 Ausführungsfocus
49

50
3.7 UML Profile
Die Unified Modeling Language 2
Die UML besitzt Erweiterungsmechanismen, die es erlauben, dem Metamodell neue Elemente
hinzuzufügen, um dieses den eigenen Anforderungen anzupassen. Der Wunsch
bzw. die Notwendigkeit kann aus mehreren Gründen entstehen. Dies kann die Anpassung
der Terminologie an eine Zielumgebung sein, das Hinzufügen spezieller Notationssymbole
oder die Konkretisierung ungenügend spezifizierter Semantik. Ein weiterer häufiger
Verwendungszweck ist die Beschränkung der Anwendung existierender Konzepte bzw.
des gesamten Metamodells.
Explizit verboten ist die Modifizierung existierender Metamodelle durch Veränderung
von Metaklassen oder durch das Entfernen vorhandener Einschränkungen. Die UML besitzt
damit ein sog. leichtgewichtiges Erweiterungskonzept.
Erweiterungen für eine bestimmte Anwendungsdomäne oder einen Anwendungszweck
werden in Profilen zusammengefasst, die eine Referenz enthalten müssen, auf welches
Metamodell sie Bezug nehmen. Die konkreten Erweiterungen werden mit Hilfe folgender
dreier Konzepte beschrieben: Stereotypen, Eigenschaftswerten („tagged values“) und
Einschränkungen („constraints“).
Wie alle Konzepte waren auch diese Überarbeitungen unterworfen. In der UML 1.x waren
sie als textbasierte Elementannotationen sehr flexibel anwendbar. In der UML2 fand
eine Präzisierung statt, die Profil-Metaklasse erbt nun die Eigenschaften der Paket-Klasse,
für Stereotypen existiert eine Metaklasse, und Eigenschaftswerte stellen ausschließlich
(Meta-)Attribute dieser Stereotyp-Metaklassen dar. Beispiele für die Anwendung von
Stereotypen mit Eigenschaftswerten finden sich in Abbildung 28 bis Abbildung 31.
3.7.1 UML Profile for Schedulability, Performance and Time
Das „UML Profile for Schedulability, Performance and Time Specification“ (SPT)
[OMG05b] ist ein Profil für das UML-1.x-Metamodell und enthält leichtgewichtige Erweiterungen
für die Echtzeit-Domäne. Die im Jahre 2003 erstmals erschienene OMG-
Spezifikation dient der Beschreibung verschiedener Zeit- und Leistungsaspekte und von
Zuteilbarkeitseigenschaften.
Zielsetzung des Profils war die Definition einer standardisierten und damit einheitlichen
Notation von zeitbezogenen Eigenschaften, um die Kommunikation zwischen Entwick-

UML Profile
lern zu erleichtern und den einfachen Datenaustausch zwischen Werkzeugen zu ermöglichen.
In der Anwendung bedeutet dies konkret, dass der Modellierer zur Beschreibung von Zeit
und Nebenläufigkeit im System auf Annotationen des Standards zurückgreifen soll. Dies
ermöglicht Analysetools, die Modelle zu lesen und quantitativ auszuwerten. Die Spezifikation
beschränkt sich nicht auf eine bestimmte Analysemethode, sondern stellt Elemente
für allgemeine Konzepte zur Verfügung, die es für existierende und kommende Techniken
nutzbar machen sollen.
Abbildung 21 zeigt den modularen Aufbau des Profils. Erweiterungen für verschiedene
Aspekte wie die Modellierung von Zeit und Nebenläufigkeit wurden getrennt und bilden
ihrerseits eigene Subprofile. Dies ermöglicht die spezifische Nutzung nur einer Untermenge
des Profils.
Abbildung 21 SPT-Profil Struktur [OMG05b]
51

52
Die Unified Modeling Language 2
Die zwei genannten Profile und das Subprofil zur Ressourcen-Modellierung bilden zusammen
das „General Resource Modeling Framework“, welches die grundlegenden Modellierungselemente
für Echtzeitsysteme anbietet. Zentrales Element ist die Ressource,
die Dienste mit bestimmten Dienstgütemerkmalen anbietet. Dem gegenüber steht der
Klient, der diese Angebote in Anspruch nimmt und diverse Dienstgüte-Parameter verlangt.
Die zweite Paketgruppierung besteht aus Subprofilen für analytische Methoden. Das
„Schedulability Analysis“ (SA) Profil enthält Stereotypen, Eigenschaftswerte und Einschränkungen
für allgemeine Analysemethoden der Zuteilbarkeit, das PA-Profil für Verfahren
der Leistungsbewertung. Das RSA-Profil spezialisiert das SA-Profil hinsichtlich
Echtzeit-CORBA-Anwendungen. Das dritte übergeordnete Paket des SPT-Profils enthält
eine Modellbibliothek. Es stellt ein Infrastrukturmodell von Echtzeit-CORBA dar.
In dieser Arbeit sind insbesondere Annotationen des Zeit- und des Leistungsprofils relevant,
diese werden im Folgenden näher betrachtet. Die Konzepte des Zeit-Subprofils sind
in folgende Pakete unterteilt:
Abbildung 22 SPT - Time Modeling [OMG05b]
Das „TimeModel“-Paket beschreibt die physikalische Zeit als das kontinuierliche und
unbegrenzte Fortschreiten von Zeitpunkten. Diese unterliegen einer totalen Ordnung und
bilden eine dichte Menge, d.h. zwischen zwei beliebigen Zeitpunkten liegt immer mindestens
ein weiterer. Der Übergang zur technischen Welt findet durch Messung dieser Zeitpunkte
und einer Abbildung auf Zeitwerte (dicht oder diskret) statt.
Alle Zeitwerte besitzen eine Referenzuhr, die im Paket „TimingMechanisms“ beschrieben
ist. Das Profil definiert zwei Zeitmechanismen, die Uhr und den (periodischen oder nicht

UML Profile
periodischen) Timer. Beide besitzen spezifische Eigenschaften wie einen aktuellen oder
maximalen Zeitwert, eine bestimmte Auflösung oder eine Drift, d.h. die Abweichungsrate
gegenüber der Referenzuhr.
Das Paket „TimedEvents“ führt Stimuli und Ereignisse ein, die zu einem bestimmten
Zeitpunkt auftreten. Dazu lassen sie sich mit einem Zeitstempel assoziieren. Zusätzlich
führt das Paket die „TimedAction“ ein, eine Aktion mit Start- und Endzeit zur Beschreibung
einer Aktionsdauer. Hiermit lassen sich auch Verzögerungszeiten modellieren.
Das letzte Paket „TimingService“ stellt ein Konzept zur Verfügung, um zeitbezogene
Dienste zu beschreiben, wie sie z.B. in Echtzeitbetriebssystemen vorhanden sind. Das
Konzept dient zum flexiblen Umgang mit Zeitmechanismen.
Das Performance-Subprofil definiert verschiedene Anwendungsbereiche. Es dient zum
Erfassen von Leistungsanforderungen und zur Beschreibung von Leistungseigenschaften
ausgewählter Modellelemente. Weiterhin können annotierte Ausführungsparameter die
Berechnung der Systemleistung unterstützen. Zusätzlich eignet sich das Profil zur reinen
Darstellung errechneter oder gemessener Werte.
Der Analysekontext, in dem Leistungsmerkmale von Interesse sind, wird als Zusammenspiel
aus Ressourcen, der Arbeitslast, die auf sie einwirkt, und Performance-Szenarien
beschrieben.
Abbildung 23 SPT - Performance Modeling [OMG05b]
53

54
Die Unified Modeling Language 2
Abbildung 23 listet alle Beschreibungselemente inklusive ihrer Beziehungen zueinander
auf. Für die Last kann die Antwortzeit der Ressource, d.h. die Ausführungsdauer des Szenarios,
angegeben werden, die durch die Workload getriggert wird. Eine Prioritätsangabe
ist ebenso vorgesehen. Zudem unterscheidet der Standard nach offener und geschlossener
(gleich bleibende Last im Gesamtsystem) Workload mit folgenden Attributen: es können
die Populationsgröße (z.B. Paketanzahl), ein Verzögerungswert zwischen der Ausführung
zweier Szenarien und ein Muster für die Zwischenankunftszeiten spezifiziert werden.
Zur Beschreibung der beteiligten Ressourcen stehen dem Modellierer die Eigenschaften
Auslastung, Durchsatz und das Zugriffsverfahren zur Verfügung. Unterschieden wird
zwischen aktiven und passiven Ressourcen, wobei erstere Server mit Bedienzeiten darstellen
wie z.B. Prozessoren. Passive Ressourcen werden während einer Szenarienausführung
in Anspruch genommen und besitzen Wartezeiten. Typische Attribute aktiver Ressourcen
sind die Angabe eines Geschwindigkeitsfaktors, die Zeitangabe für den Kontextwechsel,
die Angabe der Prioritätsstufen und ob präemptive Verfahren unterstützt werden.
Für passive Ressourcen stehen folgende Attribute zur Verfügung: Die Wartezeit bis zur
Gewährung des Zugriffs, die Antwortzeit (die Zeit von der Anforderung bis zum Lösen
des Ressourcenzugriffs), ihre Kapazität und die Zugriffszeit.
Zudem enthält ein Performancekontext mindestens ein Szenario, um eine dynamische
Situation zu beschreiben, die bezüglich Leistungsparametern von Interesse sind. Das Szenario
kann mit der Ausführungszeit und seiner Gesamtanforderung bezüglich Ressourcen
annotiert werden. Ein Szenario ist eine Sequenz von zeitlich geordneten Einzelschritten.
Diese können folgende Eigenschaften besitzen: Die Ausführungswahrscheinlichkeit im
Vergleich zu alternativen Schritten, die Anzahl der Wiederholungen und eine Verzögerungszeit
innerhalb des Einzelschrittes. Weiter stehen die Angabe der ausgeführten Operation,
das Zeitintervall zwischen zwei Wiederholungen und die Verzögerungszeit zur
Ausführung des Schrittes zur Auswahl.
Die Syntax zur Angabe komplexerer Leistungsparameter ist durch eine BNF-Notation
vorgegeben. Die allgemeine Form der Eigenschaftswerte lautet:
mit
“(“ “,” “,” “)”
::= ‘req’ | ‘assm’ | ‘pred’ | ‘msr’

UML Profile
::= ‘mean’ | ‘sigma’ | ‘kth-mom’ , | ‘max’ |’percentile,’ | ‘dist’
::= ( | | | < metricTimeStr> ) [“,” ]
Neben den eigentlichen Werten sieht der Standard zwei Attribute für Performance-
Annotationen vor. Das erste gibt die Quelle an, d.h. ob es sich um einen geforderten, geschätzten,
vorausberechneten oder gemessenen Wert handelt. Das zweite beschreibt den
Typ bzw. die statistische Bedeutung der angegebenen Größe. Es kann sich hierbei um den
Mittelwert, die Varianz, das k-te Moment, das Maximum oder um eine Perzentilangabe
handeln. Zudem ist die Syntax zur Definition von neun Standard-Verteilungsfunktionen
angegeben. Die Syntax der Zeitwerte ist in Abbildung 24 zusammengefasst, Beispieldeklarationen
mit dem SPT-Profil finden sich in Kapitel 4.1.2 mit der Abbildung 28 bis
Abbildung 31.
::= [“:” [“:” [“:” ] ] ]
::= “00”..”23”
::= “00”..”59”
::= “00”..”59”
::= “00”..”99”
::= “/” “/”
::= “0000”..”9999”
::= “01”..”12”
::= “01”..”31”
::= “Mon” | “Tue” | “Wed” | “Thr” | “Fri” | “Sat” | “Sun”
::= “(“ [ | ] “,” ”)”
::= |
::= “ ’ns’ ”|“ ’us’ ”|“ ’ms’ ”|“ ’s’ ”|“ ’hr’ ”|“ ’days’ ”|“ ’wks’ ”|“ ’mos’ ”|“ ’yrs’
::= ‘TAI’ | ‘UT0’ | ‘UT1’ | ‘UTC’ | ‘TT’ | ‘TDB’ | ‘TCG’ | ‘TCB’ | ‘Sidereal’ |
‘Local’ |
::= “(“ | | | |
| | | | “,” ”)”
3.7.2 UML Profile MARTE
Abbildung 24 Syntax der Zeitwerte
Seit dem Jahre 2005 existiert ein „Request for Proposal“ (RfP) für eine Nachfolgeversion
des SPT-Profils, das Profil MARTE („Modeling and Analysis of Real-Time and Embedded
systems“) [OMG05e].
Das SPT-Profil war die erste UML-Erweiterung zur Beschreibung von Echtzeiteigenschaften.
In den ersten zwei Jahren nach Verabschiedung des SPT-Profils im Jahre 2003
hat sich eine große Liste an Veränderungswünschen angesammelt. Diese rühren teilweise
aus praktischen Erfahrungen im Umgang mit dem SPT-Profil her, teilweise haben sich
55

56
Die Unified Modeling Language 2
andere OMG-Standards wie die MOF und die UML weiterentwickelt, die einen Einfluss
auf das Echtzeitprofil haben. Der Anhang in [OMG05e] enthält eine Liste größerer Änderungswünsche
und nötiger Verbesserungen für das SPT-Profil.
Die zuständige Arbeitsgruppe, die sog. „Revision Task Force“ für die Pflege und Fehlerkorrektur
des SPT-Profils kommt im Jahre 2004 zu der Erkenntnis, dass die gewünschten
Änderungen zu gravierend für eine einfache Versions-Inkrementierung seien.
Einreichungen für das MARTE-Profil sollen die erstellte Verbesserungsliste berücksichtigen,
dabei jedoch kompatibel zum SPT-Profil bleiben bzw. Regeln für ein Mapping
bereitstellen. Zusätzlich sollen Vorschläge in Einklang mit den neuesten OMG-Standards
stehen, insbesondere mit der MOF, UML und der XMI in den Versionen 2.0 bzw. 2.1.
Konkret soll MARTE folgende Punkte berücksichtigen: Erstens sollen verbesserte Modellierungsmöglichkeiten
für Software- und Hardware-Aspekte angeboten werden. Zur Unterstützung
der MDA [OMG03] (siehe Kapitel 2.2.4) sollen plattformspezifische und
plattformunabhängige Modellsichten unterstützt werden. Des Weiteren sieht das Profil
nicht nur Echtzeitanforderungen vor, es soll die Modellierung allgemeiner Quality-of-
Service-Eigenschaften eingebetteter Systeme unterstützen. Dazu gehören u.A. Speichergrößen
und der Energieverbrauch. Außerdem betreffen MARTE-Erweiterungen komponentenbasierte
Architekturen und unterstützen die Modellierung von asynchronen, synchronen
und realen Zeitmodellen.
Das MARTE-RfP fordert explizit die Gliederung in drei Subprofile, ähnlich den Subprofilen
des SPT-Profils (siehe Abbildung 25).
Abbildung 25 MARTE – Subprofile [OMG05e]

UML Profile
Das TCR-Subprofil entspricht dem GRM-Framwork des SPT-Profils (siehe Abbildung
21), es soll demnach die grundlegenden Modellierungskonstrukte für allgemeine Ressourcen,
Zeit und Nebenläufigkeit enthalten.
Das SPA-Subprofil ist vergleichbar mit dem Paket „Analysis Models“ im SPT-Profil und
ist für Konzepte zur Beschreibung von Leistungs- und Zuteilbarkeitseigenschaften vorgesehen.
Im RTEM-Paket werden neue Anforderungen und Kategorien zusammengefasst, die die
Modellierung von eingebetteten Systemen unterstützen.
Das UML2-konforme MARTE-Profil ist jedoch noch nicht verabschiedet worden, eine
erste Betaversion wurde im August 2007 freigegeben [OMG07c]. In dieser Arbeit fand
das SPT-Profil in Kombination mit der UML2 Verwendung. Obwohl dies formal nicht
korrekt ist, da das Profil explizit für die UML 1.x entwickelt wurde, lassen sich die Konzepte
in dem hier benötigten Umfang problemlos auch auf die Nachfolgeversion anwenden.
Dies liegt insbesondere am einfachen Annotationskonzept, Anweisungen innerhalb
von Anmerkungsfeldern an UML Elemente zu binden. Diese Möglichkeit besteht auch in
der UML2.
3.7.3 UML Testing Profile
Das UML2 Testing Profile (U2TP) [OMG05a] erweitert die UML2 um testspezifische
Beschreibungsmöglichkeiten. Es definiert eine Sprache für den Entwurf, die Visualisierung,
die Spezifikation, die Analyse, den Aufbau und die Dokumentation von Bestandteilen
eines Testsystems.
Die enthaltenen Konzepte sind in vier logische Gruppen unterteilt. Die „test architecture“
enthält Erweiterungen zur Definition der Teststruktur und der Testkonfiguration. Neben
Stereotypen zur Kennzeichnung des zu testenden Systems und zur Beschreibung von
Testkomponenten wird der „Arbiter“ eingeführt. Dieser stellt eine Schnittstelle dar, um
Testurteile zu setzen oder abzufragen. Des Weiteren wird ein Scheduler für die Testablaufkontrolle
und ein Testkontext definiert, der Testfälle zu einer Gruppe zusammenfasst.
Die „test data“-Gruppe definiert Konzepte zur Behandlung der Daten für die Testfälle. Es
erweitert die UML-Datenkonzepte insbesondere um „Wildcards“ zur flexiblen Spezifikation
von Testdaten und um Kodierungsregeln zur Beschreibung der Datenübertragung.
Die verhaltensrelevanten Aspekte sind unter „test behavior“ zusammengefasst. Zu den
Erweiterungen zählen die Metaklassen für das Testurteil, den Testfall und die Beschrei-
57

58
bung eines „Default-Handlers“. Dieser wird bei Auftreten von nicht spezifiziertem Testverhalten
aufgerufen, er schließt demnach Spezifikationslücken der Testfälle. Weitere
Konzepte für die Testprotokollierung komplettieren diese Gruppe.
Für die Beschreibung des zeitlichen Verhaltens von Testfällen ist die „time“-Gruppe zuständig.
Zum einen wird eine Timerschnittstelle definiert, die zur Manipulation von Testverhalten
und zur Terminierung wartender Testfälle verwendet werden kann. Zusätzlich
können Zeitzonen beschrieben werden, identisch zum Konzept der TimedTTCN-3
[Neu04] (siehe Kapitel 2.3.8). Sie dienen der Kennzeichnung von Zeitwerten bei verteilten
Tests. Die Werte unterschiedlicher Zeitzonen stammen von nicht synchron laufenden
Uhren und dürfen nicht miteinander verglichen werden.
Das Kapitel 4.4 zeigt in der Abbildung 46 und Abbildung 47 exemplarisch eine „UML2
Testing Profile“-konforme Testkonfiguration und das Test-Package, welches den Testkontext
und die Testkomponenten enthält.

4 Q.E.D. – Testentwurfsprozess
Im Folgenden wird der im Rahmen dieser Arbeit entwickelte Entwurfsprozess für statistische
Tests beschrieben. Abbildung 26 gibt einen Gesamtüberblick über die erforderlichen
Teilschritte.
Abbildung 26 Q.E.D.-Testentwurfsprozess
59

60
Q.E.D. – Testentwurfsprozess
Der Q.E.D.-Entwurfsprozess (QoS-Enhanced test Development) beginnt mit einer Anforderungsspezifikation,
der Basis für Systemdesign und -implementierung. Kapitel 4.1
widmet sich diesem Ausgangspunkt für den Prozess. Die linke Seite der Abbildung 26
stellt den Systementwurf dar, der in verschiedenen Phasen zum zu testenden System
(SUT) führt.
Zusätzlich stellen die Anforderungen eine gute Grundlage für die Generierung von Testfällen
dar. Zur Unterstützung des Testprozesses und zur Gewinnung qualitativer Aussagen
über das System wird ein Testmodell generiert, aus dem Testfälle gewonnen werden
können. Das Testmodell stellt ein „Markov Chain Usage Model“ (MCUM) dar, einen
endlichen Zustandsautomaten, der um Informationen aus einem oder mehreren Operationsprofilen
erweitert wird. Diese beinhalten Wissen über die voraussichtliche Häufigkeitsverteilung
der Benutzeroperationen. Das vollständige MCUM besteht aus Benutzungszuständen
und Zustandstransitionen mit assoziierten Benutzungswahrscheinlichkeiten.
Ein Algorithmus zur automatischen Modellgenerierung aus szenarienbasierten Anforderungen
wird im Kapitel 4.2 vorgestellt.
Steht das Testmodell zur Verfügung, lässt sich automatisiert eine beliebige Anzahl an
Testfällen erzeugen (siehe Kapitel 4.3). Neben diversen Überdeckungskriterien sind aufgrund
der integrierten Profile insbesondere zufällige Modelltraversierungen von Interesse.
Die erzeugten Testfälle können in eine ausführbare Form übersetzt werden. Durch das
Ergänzen noch fehlender Dateninformationen stehen die wesentlichen Informationen zur
Erstellung einer Testsuite zur Verfügung (Kapitel 4.4).
Während der Testausführung werden die erzeugten Testurteile protokolliert, welche in
das Testmodell eingebracht werden können. Auf Basis dieser Informationen lässt sich
statistisch die erreichte Benutzungszuverlässigkeit des Systems abschätzen (Kapitel
4.2.4).
Dieses Kapitel beleuchtet die unterschiedlichen Aspekte des Entwurfprozesses. Zunächst
findet eine genauere Betrachtung der Anforderungsspezifikation statt, die den Startpunkt
des Ansatzes bildet. Dem Testmodell als zentrales Element im Q.E.D.-Ansatz ist das anschließende
Kapitel 4.2 gewidmet. Danach werden die Aufgaben während der Testerzeugung
dargelegt. Dies schließt die automatische Testfallgenerierung und die Erzeugung
einer Testsuite in ausführbarer Form ein.

Szenarienbasierte Anforderungsspezifikation
4.1 Szenarienbasierte Anforderungsspezifikation
Ganz gleich, mit welcher Entwurfsmethode Software entwickelt wird, eine Anforderungsspezifikation
stellt die Basis einer jeden Softwareentwicklung dar. Fehler in dieser Phase
ziehen im fortgeschrittenen Entwicklungsstadium den größten Aufwand zur Fehlerbehebung
nach sich.
Die Anforderungsdefinitionen stellen die Schnittstelle zwischen dem Kunden und dem
Entwickler dar. Die Wahl des Beschreibungsmittels sollte demnach dem Kompromiss
zwischen allgemeiner Verständlichkeit und formaler Eindeutigkeit folgen. In der Praxis
besteht dieser Kompromiss meist aus in Prosa formulierten Anforderungen, denen eine
gewisse Struktur vorgegeben ist. Neben der Baumstruktur ist die tabellarische Form der
wichtigste Vertreter, bei der vordefinierte Felder helfen, durch Angabe von Zusatzinformationen
und Randbedingungen Ungenauigkeiten zu vermeiden [Coc00].
Eine weitere beliebte Darstellung ist die Beschreibung in Szenarienform. Dazu eignen
sich z.B. „Use Case Maps“ [ITU03] oder insbesondere Sequenzdiagramme. Letztere bieten
eine einfache Darstellung der beteiligten Komponenten und Akteure mit dem Fokus
auf deren Kommunikation. Eine größere Bedeutung haben die „Life Sequence Charts“
[DH01], im Bereich der Telekommunikation die „Message Sequence Charts“ (MSCs)
[ITU96] und bei der allgemeinen objekt-orientierten Softwareentwicklung die Sequenzdiagramme
der UML [OMG07a]. Sie besitzen neben ihrer intuitiven Verständlichkeit eine
formale Basis zur Vermeidung mehrdeutiger Kommunikationsabschnitte.
4.1.1 Use-Case-Diagramm
Die UML bietet zur Anforderungsbeschreibung zudem eine eigene Diagrammart an, das
Use-Case-Diagramm. Die Aussagekraft hält sich jedoch in Grenzen, da es nur wenige
Modellierungselemente enthält. Es separiert Personen und externe Komponenten vom
eigentlichen System und benennt dessen Anwendungsfälle.
Das Use-Case-Diagramm besteht aus drei Konzepten. Das betrachtete System wird als
„Subjekt“ bezeichnet und als Rechteck visualisiert. Die Benutzer und andere externe
Komponenten, die mit dem Subjekt interagieren, sind „Akteure“ und werden standardmäßig
als Strichmännchen dargestellt. Anwendungsfälle werden benannt und elliptisch innerhalb
des Subjekts dargestellt. Das Beispiel in Abbildung 27 stellt als Use-Case den
Datentransfer zwischen einem externen Client und dem betrachteten Server dar.
61

62
Q.E.D. – Testentwurfsprozess
Anwendungsfälle stehen in Relation zu den beteiligten Akteuren. Eine Multiplizität am
Use-Case-Ende einer Assoziation bedeutet, dass der Akteur an mehreren Anwendungsfallinstanzen
beteiligt sein kann. Zusätzlich können Anwendungsfälle auch untereinander
in gerichteten Beziehungen stehen. Dies können die extend- oder die include-Beziehung
sein. Erstere gibt an, dass ein Use-Case einen zweiten an definierten Erweiterungspunkten
um bestimmte Aspekte erweitert. Entscheidend ist, dass der Use-Case auch ohne Erweiterung
sinnvoll ist. Die include-Beziehung zeigt an, dass ein Use-Case das Verhalten eines
zweiten Use-Cases beinhaltet, welches an geeigneter Stelle eingefügt werden muss. In
diesem Fall ist der Anwendungsfall nur in Kombination vollständig und sinnvoll.
Abbildung 27 Use-Case-Diagramm
Ein Use-Case spezifiziert geforderte Anwendungen des Systems, das gewünschte Systemverhalten
wird in ihnen aus Sicht der Akteure definiert. Zur eigentlichen Verhaltensbeschreibung
können alle dynamischen Diagrammarten der UML dienen, der UML2-
Standard schränkt an dieser Stelle nicht ein. Aufgrund der Betonung der kommunikativen
Wechselbeziehung zwischen dem modellierten System und vorhandenen Akteuren eignen
sich insbesondere Interaktionsdiagramme mit ihrem wichtigsten Vertreter: dem Sequenzdiagramm.
Anwendungsfallszenarien, also Sequenzdiagramme, die die Realisierung von Anwendungsfällen
beschreiben, stellen Interaktionen zwischen Systembenutzern und einem System
dar, welches nur durch seine extern sichtbaren Schnittstellen repräsentiert wird, also
als eine Art „black-box“. Sie eignen sich demnach hervorragend als Grundlage für den
Black-Box-Test.
Der Q.E.D.-Ansatz basiert auf einer UML2-Anforderungsspezifikation, welche durch ein
Use-Case-Diagramm und zugehörigen Anwendungsfallbeschreibungen durch Sequenzdiagramme
gegeben ist. Die Szenarien können durch Annotationen aus dem UML-SPT-
Profil [OMG05b] um nicht-funktionale Anforderungen erweitert werden.

Szenarienbasierte Anforderungsspezifikation
4.1.2 Leistungsanforderungen
Das UML-SPT-Profil [OMG05b] standardisiert die Syntax zur Beschreibung verschiedener
zeit- und leistungsbezogener Anforderungen (siehe Kapitel 3.7.1). Da beim Black-
Box-Testen ausschließlich Ende-zu-Ende-Zeitanforderungen überprüfbar sind, werden
beim Testentwurfsprozess lediglich drei SPT-Annotationen berücksichtigt. Systeminterne
Laufzeiten oder die Erfüllung modellierter Komponentenzuteilung können dagegen nicht
direkt getestet werden. Gemessene Zeiten können zwar Rückschlüsse zulassen, von primärem
Interesse sind jedoch die Ende-zu-Ende-Antwortzeiten, der Durchsatz und die
Latenzzeiten verschickter Nachrichten.
Die Abbildung 28 beschreibt eine geforderte Antwortzeit. Die Benutzerinstanz I_user
interagiert mit der Systeminstanz INRES, um eine Verbindung zu R_user aufzubauen.
Dazu verschickt sie ein ICONreq und erwartet die Bestätigungsnachricht ICONconf. Die
Zeitspanne zwischen dem Sendeereignis und dem erwarteten Empfangsereignis soll maximal
zehn Sekunden betragen.
Abbildung 28 Antwortzeit - Anforderung
Der Stereotyp „PAstep“ kennzeichnet allgemein Einzelschritte in Szenarien, die zur
Durchführung ihrer Funktion Ressourcen bzw. Zeit benötigen. Das Kürzel „PA“ ordnet
ihn innerhalb des SPT-Profils dem Subprofil „Performance“ zu. Die eigentliche Anforderung
an den Schritt wird mit dem Eigenschaftswert konkretisiert. Die gesamte Annotation
wird mit dem Ausführungsfocus („execution occurrence“) verbunden, welcher die relevanten
Sende- und Empfangsereignisse beinhaltet.
Die Latenzzeit, also die Verzögerungszeit zwischen Versenden und dem Empfang einer
Nachricht, wird nicht direkt durch ein Schlüsselwort unterstützt. Sie kann nur indirekt
über die Angabe eines „host execution demand“-Tags angegeben werden.
63

64
Abbildung 29 Latenz - Anforderung
Q.E.D. – Testentwurfsprozess
Allgemein gibt das Tag die vollständige Anforderung an seine Ressource wieder und wird
entweder direkt mit der Nachricht oder mit einem vorhandenen Ausführungsfocus auf der
Systeminstanz verbunden. Abbildung 29 ist ein Beispiel für die Forderung an den Einzelschritt,
höchstens zwei Sekunden zu benötigen.
Wird von einer Instanz ein bestimmter Durchsatz gefordert, so wird das Anmerkungsfeld
direkt mit der Instanz verbunden. Abbildung 30 zeigt den Austausch von zehn Nachrichten
zwischen den Instanzen I_user und R_user über die INRES-Instanz. Der Stereotyp
„PAhost“ kennzeichnet eine aktive Ressource, der Eigenschaftswert fordert einen Durchsatz
von zehn Nachrichten pro Zeiteinheit.
Abbildung 30 Durchsatz - Anforderung
Neben der Angabe harter Zeitgrenzen ermöglicht das SPT-Profil Eigenschaftswerte mit
weichen und statistischen Eigenschaften. Das Kapitel 3.7.1 listet die Möglichkeiten des
Standards auf. Abbildung 31 stellt eine Forderung an die auftretenden Antwortzeiten. Sie
sollen einer exponentiellen Verteilung mit dem Mittelwert von 0,5 Sekunden folgen.

Markov Chain Usage Model
Abbildung 31 Verteilungsfunktions - Anforderung
Für alle Szenarien, in denen Aspekte der Leistung relevant sind, sieht das Performance-
Subprofil die Zuweisung in einen sog. Performance-Kontext vor. Die Zugehörigkeit wird
durch die Angabe des „PAContext“-Stereotyps über den Szenarien deutlich. Dies vereinfacht
deren Identifizierung bei der automatisierten Verarbeitung der Sequenzdiagramme.
4.2 Markov Chain Usage Model
Die automatisierte modellgestützte Testfallgenerierung zur Unterstützung des Testprozesses
findet ihren Einsatz in einer Reihe von Projekten (siehe Kapitel 2.2). In dieser Arbeit
wird für diesen Zweck ein sog. „Markov Chain Usage Model“ (MCUM) erzeugt. Dieses
Kapitel gibt einen Überblick über dessen Eigenschaften und beschreibt eine Möglichkeit
zur automatischen Erstellung.
4.2.1 Einführung
Ein Markov Chain Usage Model findet in einem statistischen Testprozess Verwendung.
Als Usage-Modell stellt es alle möglichen Aktionen eines Systems aus Benutzersicht dar.
Dessen Benutzung als Testmodell legt den Schwerpunkt der Testfälle auf im Betrieb
wahrscheinliche Operationen. Nach der Testausführung kann auf Basis der Testergebnisse
eine Abschätzung gegeben werden, welche Zuverlässigkeit erreicht wurde.
Das MCUM wurde 1993 von Whittaker und Poore [WP93] eingeführt. Sie bemängelten
einen Umstand, den aktuelle Zuverlässigkeitsmodelle teilten [DN84, MMN+92]. Diese
betrachteten in der Regel die gesamte Eingabedomäne des zu testenden Systems und wiesen
jeder Eingabe eine vorausgesagte Auftretenswahrscheinlichkeit zu. Daraus gewonnene
Testergebnisse wurden zur Abschätzung der erreichten Zuverlässigkeit verwendet.
65

66
Q.E.D. – Testentwurfsprozess
Das Problem dieser Herangehensweise ist die Vernachlässigung der aktuellen Systemzustände.
Üblicherweise ändern sich die Eingabewahrscheinlichkeiten im laufenden Betrieb,
der aktuelle Zustand oder „Modus“ des Systems muss berücksichtigt werden. Das
MCUM ist daher ein Zustandsautomat, die Wahrscheinlichkeiten können individuell für
jeden Zustand angegeben werden.
Mittlerweise wurden MCUMs in zahlreichen Projekten [WT94, Say99, GM02, DZ03]
eingesetzt und verschiedene Facetten beleuchtet. Sie finden in der Softwareentwicklungsmethode
„Cleanroom“ [PTL+99] ihren Einsatz, beim Web-Testen [KT01] und beim
Partitionstest [SP00]. In [Gut97] werden seltene Ereignisse behandelt, [WP00] widmet
sich der Gewinnung der Transitionswahrscheinlichkeiten und mit der „TML“ steht eine
eigene Beschreibungssprache für MCUMs zur Verfügung [Pro00].
4.2.2 Eigenschaften
Ein MCUM ist eine zustandsendliche, zeitlich homogene, diskret parametrisierte und
nicht reduzierbare Markowkette [Say99]. Es besitzt einen Startzustand, welcher den Systemstart
bzw. Programmaufruf symbolisiert, einen für die Terminierung stehenden Endzustand
und Zustände, welche die Benutzung des betreffenden Systems repräsentieren
(einfaches Beispiel-MCUM in Abbildung 32).
Ein MCUM wird als gerichteter Graph G = (S, T) und einer Funktion p: S × S → [0,1]
mit folgenden Eigenschaften beschrieben [Gut00]:
S: Die nichtleere Knotenmenge, die Zustände der Systembenutzung repräsentieren
T: Die nichtleere Kantenmenge, bestehend aus Zustandstransitionen, die mit Benutzeraktionen
korrespondieren.
p(si, sj): Die Transitionswahrscheinlichkeit von Zustand si zu Zustand sj mit folgenden
Eigenschaften:
0 p ( s , ) ≤ 1
∑
s j∈S
≤ i s j
p( s , s ) = 1
i
j
Der Endzustand ist absorbierend, d.h. für den Endzustand sn gilt p(sn, sn) = 1. Die Transitionswahrscheinlichkeiten
p(si, sj) werden häufig in Matrixform mit (p(si, sj))i,j dargestellt.
Aus dem MCUM lassen sich Testfälle gewinnen, sie entsprechen Pfaden vom Start- zum
Endzustand.

Markov Chain Usage Model
Operationelles Profil
Abbildung 32 Einfaches MCUM
Die Transitionswahrscheinlichkeiten stammen aus einem operationellen Profil des Systems.
Es können mehrere Profile pro System existieren, für unterschiedliche Benutzertypen
(z.B. Systemadministrator/Systembenutzer) oder zum Testen unterschiedlicher Lastsituationen
[Wey03].
Nach [WP93] existieren drei Herangehensweisen für die Erstellung eines operationellen
Profils. Die erste wird „uninformiert“ bezeichnet, es steht keine Information über das
spätere Verhalten zur Verfügung. In diesem Fall wird die Gleichverteilung angewendet,
d.h. jede ausgehende Transition eines Zustands ist gleich wahrscheinlich. Bei der zweiten,
„informierten“ Methode stehen Felddaten zur Verfügung. Diese können von einem Prototypen
oder von einer früheren Version stammen. Beim Testen eines Webservers in
[KT01] wurde das Benutzerverhalten durch Analyse umfangreicher Weblogs vergleichbarer
Webserver abgeschätzt. In [VW98, WV00] war der Ausgabestrom eines bestehenden
älteren Systems gleich dem Eingabestrom des zu testenden Systems, da diese in einer
Reihenschaltung betrieben werden sollten. Zur Charakterisierung des Datenstroms wurde
das bestehende System einem Monitoring unterzogen.
Die dritte Methode ist der „vorgesehene“ oder „geplante“ Ansatz. Späteres Nutzerverhalten
kann angenähert vorhergesagt bzw. gewünschtes Verhalten angenommen werden. Für
diesen Ansatz beschreibt [WP00] ein regelbasiertes Verfahren zur Anpassung der Transitionsmatrix.
Den Ausgangspunkt bildet, wie beim uninformierten Ansatz, die Gleichverteilung.
Sowohl punktuelle Vorhersagen, also Wissen über einzelne Transitionswahrscheinlichkeiten,
als auch relative Aussagen, d.h. Wissen über die Auftretenswahrscheinlichkeiten
einzelner Transitionsaktionen in Relation zu anderen, werden in Regelform
definiert. [WP00] enthält dazu mehrere Beispiele und beschreibt, wie mit einer geringen
67

68
Q.E.D. – Testentwurfsprozess
Anzahl solcher Regeln die Ausgangsmatrix in großen Teilen angepasst werden kann, um
realistischere Matrixwerte zu erzeugen.
Statistische Aussagen
Als Testmodell dient das MCUM nicht nur der Generierung von Testfällen, es unterstützt
auch die Testplanungsphase. Einige Standardanalyseergebnisse für Markowketten ergeben
[WT94] (s0: Startzustand):
(1) Die Wahrscheinlichkeit für das Auftreten des Zustands sj in einem Testfall entspricht
der Wahrscheinlichkeit der Auswahl des Pfades vom Startzustand zum Zustand sj:
∑
sk
∈S
y s , s ) = p(
s , s ) + p(
s , s ) y(
s , s )
( 0 j
0
j
d.h. die gesuchte Wahrscheinlichkeit entspricht der Addition der Transitionswahrscheinlichkeit
vom Startzustand zum gesuchten Zustand und der Summe aller möglichen Pfade
vom Startzustand zum Zustand sj.
(2) Die mittlere benötigte Anzahl von Testfällen zum Auftreten des Zustands sj in einem
generierten Testfall ist der Kehrwert von y:
1
h ( s j ) =
y(
s , s )
(3) Die Wahrscheinlichkeit für das Auftreten der Transition von Zustand sj zu Zustand sk
in einem Testfall:
0 j
z ( s j , sk
) = y(
s0
, s j ) p(
s j , sk
)
(4) Die mittlere benötigte Anzahl an Testfällen zum Auftreten der Transition von Zustand
sj zu Zustand sk ist der Kehrwert von z:
1
h ( s j , sk
) =
z(
s , s )
Eine Reihe weiterer für die Testplanung interessanter Metriken sind in [Say99] zusammengefasst.
Die Berechnung der mittleren Testfalllänge gibt schon vor der Testdurchführung
einen Hinweis auf die zu erwartende Dauer. Die Kontrolle der Überdeckungsrate der
j
o
k
k
k
j

Markov Chain Usage Model
Modellzustände bzw. -transitionen erlaubt die Anwendung eines einfachen Haltekriteriums
[Wey03].
4.2.3 Erstellung eines MCUMs
Alle konzeptionellen Vorteile eines MCUMs kommen nicht zum Tragen, wenn es aufgrund
eines zu hohen Aufwandes nicht erstellt wird. In [DZ03] wird auf die Erzeugung
eines MCUMS aus einer Menge von MSCs („Message Sequence Charts“) eingegangen.
Es werden jedoch lediglich einfache Sequenzen betrachtet, die erweiterten Beschreibungsmöglichkeiten
oder komplexere Abläufe werden nicht berücksichtigt. Letztere entstehen
z.B. durch die Anwendung der sog. „inline expressions“, welche weitgehend den
kombinierten Fragmenten der UML2 entsprechen. Darüber hinaus wird in der Literatur
nur wenig auf den Erstellungsprozess eingegangen. Dieses Unterkapitel widmet sich dieser
wichtigen Aufgabe.
Im Q.E.D.-Ansatz stellt eine UML2-Anforderungsspezifikation das Ausgangsmaterial zur
Erstellung des MCUMs als Testmodell dar. Wie in Kapitel 4.1 beschrieben, besteht diese
aus Sequenzdiagrammen, die neben dem funktionalen Kommunikationsverhalten auch
zeitliche Anforderungen beschreiben. Optional kann ein Use-Case-Diagramm externe
Akteure darstellen und sie in Bezug zu Anwendungsfällen stellen.
Es folgt nun eine detaillierte Abbildungsvorschrift der Anforderungsspezifikation auf das
MCUM. Der Reihe nach werden alle Konzepte der Sequenzdiagramme diskutiert, ob und
wie sie behandelt werden.
Voraussetzungen
Aus dem Modell werden Testfälle für einen Black-Box-Test generiert, demnach ist ausschließlich
die extern sichtbare Systeminteraktion von Interesse. Die zu bearbeitenden
Sequenzdiagramme besitzen lediglich eine Systeminstanz, alle anderen Objektinstanzen
repräsentieren Benutzer des Systems. Sind mehrere Systeminstanzen vorhanden, müssen
die Diagramme zunächst durch den Dekompositionsoperator (siehe Kapitel 3.6) angepasst
werden.
In den Szenarienbeschreibungen bleiben einige Interaktionskonzepte unberücksichtigt, da
sie im verwendeten Kontext bedeutungs- oder sinnlos sind:
• Ordnungsrelation: Die Operatoren zur expliziten Angabe der strikten bzw. losen
Ordnung („strict“ und „seq“) können ignoriert werden, da ausschließlich die Ereignisreihenfolge
auf der Systeminstanz von Relevanz ist. Die lose Ordnung er-
69

70
Q.E.D. – Testentwurfsprozess
zeugt dagegen einen Freiheitsgrad bei den Sende- und Empfangszeitpunkten der
Benutzerinstanzen.
Die Abbildung 33 verdeutlicht diesen Umstand. Das Beispielszenario lässt offen,
ob zunächst User_1 oder User_2 seine Nachricht verschickt. Aus Systemsicht ist
jedoch festgelegt, dass die Nachricht m1 vor der Nachricht n1 empfangen wird.
Um diese Reihenfolge beim Testen garantieren zu können, wird eine totale Ordnung
in den Szenarienbeschreibungen angenommen (vgl. auch Kapitel 4.3 „Synchronisierung“).
Abbildung 33 Ordnungsrelation
• Ausführungsfocus: Auf der Systeminstanz modellierte Aktionssequenzen bleiben
unberücksichtigt, da systeminternes Verhalten bei Black-Box-Verfahren nicht
bzw. nur indirekt getestet wird.
• Der „consider“-Operator des kombinierten Fragments wird bei der MCUM-
Erstellung nicht betrachtet. Er zeigt an, dass alle nicht im Fragment aufgelisteten
Nachrichten ignoriert werden sollen. Da diese zu ignorierenden Nachrichten nicht
näher bestimmt sind, können zwei Fälle unterschieden werden:
(1) Beliebige nicht aufgelistete Nachrichten von Benutzer- zur Systeminstanz sollen
beim System zu keiner Reaktion führen. Dies führt zu keinem sinnvollen Testfall,
für die Automatisierung sollte der Freiheitsgrad der Nachrichtenwahl beschränkt
werden.
(2) Innerhalb des Fragments können beliebige Nachrichten von der System- zur
Benutzerinstanz auftreten, die irrelevant sind. Dieses Szenario ist für den Test bedeutungslos,
da es keinen negativen Testlauf gäbe. Jede Systemreaktion ist als
korrekt spezifiziert.

Markov Chain Usage Model
Andere Interaktionskonzepte werden nur teilweise berücksichtigt bzw. werden vor dem
Transformationsvorgang umgewandelt:
• Zustandsinvarianten: Zustandsinvarianten beschreiben Regeln, die zur Laufzeit
überprüft werden. Formal können u.A. bestimmte Attribut- bzw. Variablenwerte
oder Zustände gefordert werden. Nur bei einer gültigen Invariante wird ein erlaubtes
Szenario beschrieben. In dieser Arbeit werden nur Forderungen bezüglich des
erreichten Systemzustands berücksichtigt, da sich nur diese zur Verknüpfung von
Szenarien eignen.
• Sprungmarken („continuations“) stellen spezielle Verknüpfungspunkte in alternativen
Fragmenten dar (vgl. Kapitel 3.6). Für die nachfolgend beschriebene Transformation
können diese ähnlich den Zustandsinvarianten interpretiert werden, d.h.
sie stellen Verknüpfungspunkte verschiedener Szenarien dar.
• Zwei Operatoren des kombinierten Fragments, die Sicherstellung „assert“ und
der kritische Bereich „critical“, werden bei der Transformation zunächst ignoriert.
Beide betonen die enthaltene Nachrichtensequenz, die dargestellte Reihenfolge
ist wichtig bzw. nur in dieser gültig. Während des Abbildungsvorgangs werden
sie jedoch gesondert behandelt (siehe Transformationsschritt 3), die in ihren
Fragmenten enthaltenen Zustandsinvarianten werden daher eindeutig gekennzeichnet
(durch Hinzufügen eines Namenpräfixes).
• Die Negation „neg“ beschreibt Szenarien, die ungültig sind. Sie dienen der Erzeugung
illegaler Testfälle, d.h. sie beschreiben explizite Antwortnachrichten des
Systems, die zu einem „fail“-Testurteil führen, während alle anderen Nachrichten
gültige Systemantworten darstellen. Die Szenarien können zunächst wie legale
Szenarien auf das MCUM abgebildet werden. Aufgrund der gegensätzlichen Semantik
müssen diese Zustandsübergänge jedoch für die automatisierte Testfallgenerierung
erkennbar bleiben. Die enthaltenen Nachrichten werden daher durch
Hinzufügen eines Namenpräfixes kenntlich gemacht.
• Der „ignore“-Operator listet Nachrichten auf, die innerhalb des kombinierten
Fragments nicht dargestellt sind (vgl. Kapitel 3.6). Die gelisteten Nachrichten
können an jeder Stelle innerhalb des Fragments auftreten und sollen ignoriert werden,
d.h. sie dürfen keine Reaktion hervorrufen. Er stellt somit das Gegenstück
zum consider-Operator da, die für ihn genannten zwei Varianten gelten gleicher-
71

72
Q.E.D. – Testentwurfsprozess
maßen. Die Nachrichtenauswahl im ersten beschriebenen Fall wird jedoch durch
eine Liste eingeschränkt und ermöglicht damit eine sinnvolle Automatisierung.
Das folgende Beispiel zeigt, wie dieser Operator vor der Transformation aufgelöst
wird. Nach jedem Zustand des Fragments wird der Empfang jeden Elements der
Nachrichtenliste eingefügt, jeweils gefolgt durch den vorherigen Zustand.
Die Abbildung 34 links stellt ein Szenario dar, in der die Systeminstanz die Nachrichten
m1, m2 und m3 ignorieren soll. Rechts ist das bearbeitete Sequenzdiagramm
abgebildet, es stellt eine mögliche Empfangsreihenfolge der Nachrichten
dar. Da durch die nachfolgenden Transformationsschritte ein Automatenmodell
entsteht, kann ein daraus generierter Testfall dennoch jede beliebige Nachrichtenfolge
enthalten und prüfen.
Transformationsschritte
Abbildung 34 Auflösung des „ignore“-Fragments
Da die Anforderungen als Spezifikation in der UML2 vorliegen, liegt es nahe, das
MCUM ebenso in der UML2 darzustellen. Das Modell kann somit in der gleichen Werkzeugumgebung
betrachtet werden. Protokollzustandsautomaten eignen sich für diesen
Zweck, die erweiterten Beschreibungsmöglichkeiten von Verhaltenszustandautomaten
werden nicht benötigt. Es folgt eine detaillierte Beschreibung der benötigten Teilschritte:

Markov Chain Usage Model
1. Einfügen von Zustandsinvarianten
Im ersten Schritt werden auf der Systeminstanz der Anforderungsszenarien weitere Zustandsinvarianten
eingefügt, die als sog. Zwischenzustände den jeweiligen Systemzustand
repräsentieren. Dies erfolgt nach der Regel, dass in Kombination mit den bereits enthaltenen
benutzerdefinierten Invarianten maximal zwei Ereignisse zwischen zwei Zuständen
verbleiben - ein Sende- und das korrespondierende Empfangsereignis. In allen anderen
Fällen stehen Ereignisse einzeln, voneinander durch Zustandsinvarianten getrennt. Diese
stellen sicher, dass erkannte Fehler während der Testausführung im Szenario rückverfolgbar
sind.
2. Abbildung der Szenarien auf Zustandsmaschinen
Abbildung 35 Transformation - Basisregeln
73

74
Q.E.D. – Testentwurfsprozess
Anschließend wird jedes Szenario auf eine Zustandsmaschine abgebildet. Die kleinste
Abbildungseinheit stellen die Ereignisse zwischen zwei Zustandsinvarianten dar. Wegen
des vorhergehenden Transformationsschrittes gibt es drei Basisregeln, die in Abbildung
35 zu sehen sind. Darin ist rechts die erzeugte Transition aus dem korrespondierenden
Szenario links zu sehen.
Die entstehenden Zustandsübergänge benennen die auszutauschenden Nachrichten. Ein
Systemstimulus wird in der Syntax der Protokollzustandsmaschinen auf eine Vorbedingung
abgebildet, folglich steht dieser in eckigen Klammern. Eine Systemantwort entspricht
einer Operation und wird ohne Klammern notiert (vgl. Abbildung 14). Da in den
Szenarien mehrere Benutzerinstanzen enthalten sein können, werden die Nachrichten um
den Namen der Sende- bzw. Empfängerinstanz erweitert. Dies ermöglicht während der
Testfallerstellung die korrekte Zuordnung des Verhaltens auf die Testkomponenten. Zur
Verdeutlichung der verwendeten Transitionssyntax zeigt Abbildung 36 die erzeugte Zustandsmaschine
für das INRES-Beispiel aus Abbildung 9.
Abbildung 36 Zustandsmaschine des INRES-Protokolls
Für die Konkatenation gilt Abbildung 37, darin ist M(i) der erzeugte Automat für Szenario
i. Die Abbildungsvorschrift erzeugt aus einem fortlaufenden Szenario einen fortlaufenden
Automatenpfad.
Abbildung 37 Transformation - Konkatenation

Markov Chain Usage Model
Abbildung 38 und Abbildung 39 zeigen die benötigten Transformationsregeln für verschiedene
kombinierte Fragmente. Die erzeugten Automaten der Operatoren „alt“ und
„opt“ machen deutlich, dass es sich bei letzterem um einen Spezialfall der Alternative
handelt. Beim optionalen Fragment wird entweder das enthaltene Szenario ausgeführt
oder das Verhalten wird an dessen Ende fortgesetzt.
Abbildung 38 Transformation - Kombinierte Fragmente (Teil 1)
75

76
Q.E.D. – Testentwurfsprozess
Im Falle des „par“-Operators wird ein zusammengesetzter Zustand mit orthogonalen Regionen
erzeugt. Die im kombinierten Fragment enthaltenen Szenarien werden als Sub-
Zustandsmaschinen in die erzeugten Regionen eingefügt. Der Automat aus der unbeschränkten
Schleife kann die Zustände des Szenarios gar nicht oder beliebig oft durchlaufen,
bei der beschränkten Schleife mindestens „min“, höchstens „max“ Mal.
Die Operanden der Operatoren „alt“, „opt“ und „loop“ können außerdem mit einem booleschen
Ausdruck versehen sein, welcher für einen ausgewählten Operanden mit „wahr“
ausgewertet sein muss. Diese Ausdrücke haben keinen Einfluss auf die Transformation,
sondern auf das operationelle Profil. So muss sich die Wahrscheinlichkeit einer wahren
Bedingung in der Wahrscheinlichkeit dieser Verzweigung im MCUM widerspiegeln.
Abbildung 39 Transformation - Kombinierte Fragmente (Teil 2)
Für Szenarien mit SPT-Annotationen gelten grundsätzlich die gleichen Abbildungsregeln,
hinzu kommt die Notwendigkeit, die Annotationen zu erhalten und Start- und Endpunkte
für die zeitlichen Einschränkungen zu kennzeichnen.
Da die Start- und Endzeitpunkte der nicht-funktionalen Anforderungen immer an Sende-
bzw. Empfangsereignisse von Nachrichten gekoppelt sind, lassen sich die Annotationen

Markov Chain Usage Model
gut auf die Zustandsautomaten übertragen. Hier gilt die Regel, dass die ursprüngliche
Annotation - um einen nummerierten Start-Tag erweitert - an die Nachricht des Startzeitpunktes
gebunden wird. Die Nachricht des Endzeitpunktes erhält eine Annotation mit
einem End-Tag und einer - zum Start-Tag korrespondierenden - laufenden Nummer. Die
Tags ermöglichen auch bei verschachtelten Anforderungen die eindeutige Zuordnung von
Start- und Endpunkten. Die Abbildung 40 enthält dazu ein Beispiel.
Abbildung 40 Transformation – SPT-Annotation
3. Vereinigung der Zustandsmaschinen und Erstellung des MCUMs
Vor diesem dritten Transformationsschritt existiert pro Szenario ein Zustandsautomat,
diese werden nun zu einem MCUM vereint. Alle gleich benannten Zustände werden zusammengefasst,
die neu entstehende Menge an ein- bzw. ausgehenden Transitionen ist die
Vereinigung der alten ein- und ausgehenden Übergänge. Ebenso werden alle Endzustände
zu einem verschmolzen. Da die UML2-Spezifikation für den Initialzustand nur eine ausgehende
Transition erlaubt, wird dieser mit einem Zustand namens „Start“ verbunden,
welcher die Initialzustände aller Szenarien ersetzt.
Für diesen dritten Transformationsschritt gibt es mehrere Ausnahmen. Verschiedene Automatenzustände
müssen atomar behandelt werden, d.h. sie dürfen mit anderen gleich
benannten Zuständen nicht verschmolzen werden.
Zum einen trifft diese Ausnahme auf Zustandsinvarianten aus den kombinierten Fragmenten
Sicherstellung („assert“) und dem kritischen Bereich („critical“) zu. Beide Operatoren
verbieten gültige Verzweigungen innerhalb ihres Fragments, durch eine Vereinigung
mit Zuständen anderer Szenarien würde ihre Semantik verletzt werden.
Die gleiche Ausnahme gilt für Automaten mit SPT-Annotationen. Zeitliche Einschränkungen
erstrecken sich häufig über mehrere Systemzustände hinweg, nur die enthaltene
77

78
Q.E.D. – Testentwurfsprozess
Sequenz besitzt eine gültige nicht-funktionale Anforderung. Ein Verschmelzen mit Zuständen
anderer Szenarien kann zu fälschlicherweise annotierten Pfaden führen, für die
keine Zeitanforderung gegeben ist. Folglich müssen die enthaltenen Automatenzustände
ebenfalls atomar behandelt werden.
Zur Fertigstellung des MCUMs wird jede Transition um ihre Auftretenswahrscheinlichkeit
aus einem operationellen Profil erweitert (siehe Kapitel 4.2.2). Besteht die Anforderungsspezifikation
zusätzlich aus einem Use-Case-Diagramm, in welchem mehrere Anwendungsfälle
modelliert sind, ist das vorläufige Ergebnis ein MCUM pro Use-Case.
Liegen Informationen über die Auftretenswahrscheinlichkeiten der Benutzer und Use-
Cases vor, können die Modelle zu einem einzigen MCUM verbunden werden.
Abbildung 41 zeigt ein Beispiel mit zwei Akteuren, es sei:
qi: Auftretenswahrscheinlichkeit von Benutzer i
pij: Wahrscheinlichkeit von Benutzer i, den Anwendungsfall j auszuführen
Abbildung 41 Erweitertes Use-Case-Diagramm
Das aus diesem Beispiel resultierende zusammengesetzte MCUM zeigt Abbildung 42.
Abbildung 42 Zusammengesetztes MCUM

Markov Chain Usage Model
Die Übergangswahrscheinlichkeit vom Startzustand zum MCUM für Anwendungsfall j
berechnet sich aus:
P ( j)
∑
= qi
pij
i∈Akteure
Semantikvergleich UML Sequenzdiagramm – MCUM
Zum Abschluss dieses Unterkapitels folgt ein Vergleich der Semantiken der UML2-
Sequenzdiagramme und des erzeugten MCUM. Die UML erlaubt die Beschreibung von
Systemverhalten durch die Angabe seiner internen bzw. externen Interaktionen. Dabei gilt
eine Spurensemantik, d.h. die Semantik der Interaktionen wird durch das Mengenpaar
[P, I] beschrieben, mit:
P: die Menge der gültigen Spuren
I: die Menge der ungültigen Spuren
Ein Szenario mit einer Negation („neg“) beschreibt eine Spur der Menge I, alle anderen
Szenarien beschreiben Spuren der Menge P. Szenarien beschreiben jedoch nicht das gesamte
mögliche Systemverhalten, sie stellen lediglich eine Auswahl dar. Über nicht spezifizierte
Spuren kann keine Aussage getroffen werden, sie gehören entweder zur Menge P
oder zur Menge I.
Das MCUM und ein aus ihm erzeugter Testfall hat notwendigerweise eine andere Semantik.
Verhält sich das SUT beim Testen wie im MCUM spezifiziert, so gilt das Testurteil
„pass“. Zeigt sich ein anderes Verhalten, so gilt dieser Testfall als fehlgeschlagen. Die
Spurensemantik würde stattdessen ein „inconclusive“ vorschreiben, also das Testurteil
ohne Korrektheitsaussage. Die Anwendung der Spurensemantik beim Testen ist jedoch
nicht möglich, da jedes illegale SUT-Verhalten explizit angegeben werden müsste.
Eine weitere Konsequenz der UML2-Spurensemantik ist, dass lediglich die gesamte Spur
gültig ist, nicht jedoch einzelne Teilspuren daraus. Das MCUM besitzt stattdessen die
Markow-Eigenschaft, d.h. für den weiteren Verlauf einer Spur ist dessen Historie irrelevant.
Es ist also gleich, auf welchem Weg der aktuelle Zustand erreicht wurde, jede ausgehende
Transition im MCUM gilt als gültige Fortsetzung. Dies stellt eine Grundannahme
bei der MCUM-Erstellung dar, was durch das Vorhandensein von Systemzuständen in
den Sequenzdiagrammen begründet ist. Durch die Spezifikation mehrerer gleich benannter
Zustände werden implizit alternative gültige Spuren beschrieben, diese Eigenschaft
macht sich der Transformationsalgorithmus zu Nutze.
79

80
4.2.4 Software-Zuverlässigkeit
Q.E.D. – Testentwurfsprozess
Der Begriff der Zuverlässigkeit wird in der Literatur und in Standards unterschiedlich
definiert. Die DIN ISO Norm 9000 Teil 4 [DIN94] beschreibt den Begriff als „Beschaffenheit
einer Einheit bezüglich ihrer Eignung, während oder nach vorgegebenen Zeitspannen
bei vorgegebenen Anwendungsbedingungen die Zuverlässigkeitsanforderungen
zu erfüllen“. Diese Definition wird jedoch meist mit dem Begriff der Verlässlichkeit
(„dependability“) gleichgesetzt. Im Allgemeinen setzt sich die Verlässlichkeit aus den
Komponenten Zuverlässigkeit („reliability“), Sicherheit („safety“) und Verfügbarkeit
(„availability“) zusammen.
[Bir97] beschreibt eine verbreitete Definition der Softwarezuverlässigkeit mit der Überlebenswahrscheinlichkeit,
also der Wahrscheinlichkeit, in einer gegebenen Umgebung und
Zeitraum ohne Reparaturen funktionsfähig zu sein.
Die Anforderungen an die Zuverlässigkeit eines Systems können sich stark unterscheiden.
Der Standard [IEC98] definiert „SIL“-Level mit verschiedenen Zuverlässigkeitsanforderungen
für unterschiedliche Systemtypen.
Beim statistischen Testen wird durch eine geeignete Auswahl der Testfälle die Softwarezuverlässigkeit
abgeschätzt, wie sie die tatsächlichen Benutzer empfinden. Man spricht
hier von der Benutzungszuverlässigkeit („usage reliability“).
Whittaker und Thomason geben in [WT94] einen Algorithmus zur Berechnung der Benutzungszuverlässigkeit
an. Darin erstellen sie neben dem MCUM ein weiteres Modell,
das sog. Testkettenmodell („testing chain“), welches zunächst aus den gleichen Zuständen
wie das MCUM besteht. Die Transitionswahrscheinlichkeiten des Testkettenmodells sind
zunächst alle gleich null, erst während der Testausführung werden sie berechnet. Die Übergangswahrscheinlichkeit
p(si, sj) von Zustand si zu Zustand sj berechnet sich aus:
s(
si
, s j )
p ( si
, s j ) =
v(
s )
Formel 1 Testkettenmodell - Transitionswahrscheinlichkeiten
s(si, sj): Anzahl der erfolgreichen Transitionsübergänge von Zustand si zu Zustand sj
v(si): Anzahl der Besuche von Zustand si
Tritt beim Testen ein Fehler auf, wird an der entsprechenden Position im Testkettenmodell
ein neuer Fehlerzustand eingefügt. Trat der k-te Fehler bei einer Transition aus Zu-
i

Markov Chain Usage Model
stand si auf, entspricht die Übergangswahrscheinlichkeit von si zum neuen Fehlerzustand
fk der Differenz der Summe aller übrigen Übergangswahrscheinlichkeiten von si zu eins:
S: Menge aller Modellzustände
∑
si∈S
p ( s , f ) = 1−
p(
s , s )
i
k
Die ausgehende Transition von fk wird entweder mit dem Endzustand oder mit dem ursprünglichen
Nachfolgezustand im Testkettenmodell verbunden, dies hängt von der
Schwere des Fehlers ab. Da der Fehlerzustand in jedem Fall eine einzige ausgehende
Transition besitzt, ist deren Wahrscheinlichkeit eins: p ( f , ) = 1
i
j
k s j
Für die Berechnung der Softwarezuverlässigkeit werden alle Fehlerzustände als absorbierend
betrachtet. Dann ist die Zuverlässigkeit gleich der Wahrscheinlichkeit eines fehlerfreien
Pfades vom Start- zum Endzustand innerhalb des Testkettenmodells:
∑
s j∈S
R ( s , s ) = p(
s , s ) + p(
s , s ) R(
s , s )
start
end
start
end
start
Formel 2 Benutzungszuverlässigkeit nach [WT94]
S: Menge aller Zustände des Testkettenmodells
Das Testkettenmodell kann auch zur Definition eines möglichen Stoppkriteriums verwendet
werden. Das MCUM repräsentiert das gewünschte, theoretische Verhalten bei Abwesenheit
jeden Fehlers, während das Testkettenmodell das reale Verhalten darstellt. Vergleicht
man die Wahrscheinlichkeitsmatrix des MCUMs (d.h. das operationelle Profil)
mit der des Testkettenmodells, nähern sie sich mit der Anzahl der Testläufe einander an.
Jeder gefundene Fehler verlangsamt diese Annäherung, sie vollzieht sich schneller, je
weniger Fehler entdeckt werden. Betrachtet man die Differenz der zwei Matrizen als Maß
für den Testfortschritts, kann das Unterschreiten einer vorgegebenen Differenz als Stoppkriterium
für das Testen dienen.
Die beschriebene Berechnung der Zuverlässigkeit besitzt den Nachteil, dass vor der Testdurchführung
implizit ein Startwert von 1, also hundertprozentige Zuverlässigkeit angenommen
wird. Dies kann schnell nachvollzogen werden: Vorinitialisiert besitzt das Testkettenmodell
ausschließlich Transitionswahrscheinlichkeiten von null. Entlang eines feh-
j
j
end
81

82
Q.E.D. – Testentwurfsprozess
lerfrei getesteten Pfades berechnen sich diese nach Formel 1 zu eins. Nach Formel 2 wird
anschließend die hundertprozentige Zuverlässigkeit berechnet.
Erst auftretende Fehler bei der Testausführung reduzieren diesen Wert. Enthält das SUT
nur wenige Fehler oder werden nur wenige Testfälle ausgeführt, sind fehlerfreie Testläufe
wahrscheinlich und die Berechnung liefert diesen unrealistischen Wert.
Nach Miller [MMN+92] und Sayre [Say99] lässt sich die Fehlerrate von Software durch
eine Standard Beta-Verteilung beschreiben. Im Folgenden beschreibt die Zufallsvariable
Fij die Fehlerrate des Zustandsübergangs von si zu sj, ij
ij
R = 1 − F ist die Wahrscheinlich-
keit für den fehlerfreien Zustandswechsel von si nach sj. Der Erwartungswert der Zufallsvariablen
Fij lässt sich demnach durch den Mittelwert der Beta-Verteilung angeben:
f ( si
, s j ) + a(
si
, s j )
E(
Fij
) =
f ( s , s ) + s(
s , s ) + a(
s , s ) + b(
s , s )
i
j
i
Formel 3 Einführung der Miller-Parameter
s(si,sj): Anzahl der erfolgreichen Transitionsübergänge von Zustand si zu Zustand sj
f(si,sj): Anzahl der fehlerhaften Transitionsübergänge von Zustand si zu Zustand sj
a(si,sj) und b(si,sj): a-priori Information über die Transition von Zustand si zu Zustand sj
Die Parameter a(si,sj) und b(si,sj) werden als „Miller-Parameter“ bezeichnet und können
dazu genutzt werden, vorhandenes Wissen oder aus Erfahrung abgeleitete Vermutungen
in die Berechnung einfließen zu lassen. Ist z.B. bekannt, dass die Transition zwischen den
Zuständen si und sj eine niedrige Fehlerrate aufweist, kann der Wert von a(si,sj) niedrig
auf 1 und der Wert für b(si,sj) auf einen höheren Wert von 10 gesetzt werden. Dieses Zahlenbeispiel
würde für zehn fiktiv durchgeführte und erfolgreich durchlaufene Testfälle
stehen. Ist für eine Transition keine Information vorab bekannt, so werden beide Parameter
mit dem Standardwert 1 belegt.
Die Einführung der „Miller-Parameter“ bringt mehrere Vorteile mit sich. So liegt der
Startwert der Softwarezuverlässigkeit vor Durchführung eines Testfalls standardmäßig
bei 50 Prozent. Dies erlaubt eine bessere Zuverlässigkeitsaussage auch ohne Auffinden
von Fehlern. Zum zweiten erlauben die Parameter das Einbringen von vorhandenem Wissen.
Beide Effekte führen nach [Say99] zu einem schnelleren Konvergieren des berechneten
an den realen Wert.
j
i
j
i
j

Markov Chain Usage Model
Importance Sampling
In [WPT95] beschreiben Walton, Poore und Trammell einen generellen Nachteil des statistischen
Testens mit einem MCUM. Die Testfälle werden ausschließlich nach dem Kriterium
der Auftretenswahrscheinlichkeiten im realen Betrieb ausgewählt. Dies ermöglicht
zwar eine erwartungstreue Abschätzung der erreichten Zuverlässigkeit, vernachlässigt
jedoch andere wichtige Kriterien bei der Testfallauswahl wie die Fehleranfälligkeit und
das Fehlerrisiko, also die unterschiedlichen Kosten, die durch Fehler verursacht werden.
Seltene Ereignisse mit hohen Folgekosten im Fehlerfall werden so wenig getestet.
Sie beschreiben dafür drei mögliche Lösungen. Die eine ist das Erstellen eines weiteren
Benutzermodells für seltene, aber kritische Operationen. Zweitens schlagen sie das unabhängige
manuelle Testen dieser Operationen vor. Drittens ist die Verwendung eines verschobenen
operationellen Profils möglich, welches die Traversierung kritischer Pfade im
MCUM begünstigt. Dies geht jedoch mit dem Verlust der Abschätzbarkeit der Systemzuverlässigkeit
einher.
Gutjahr beschreibt in [Gut97] eine mögliche Lösung dieses Problems durch die Anwendung
des – aus der Simulation bekannten – „Importance Samplings“. Dazu wird der Kostenfaktor
q eingeführt, der die Höhe der von einem Fehler verursachten Folgekosten darstellt
und individuell für jede Transition angegeben werden kann. Damit verschieben sich
die Wahrscheinlichkeiten des operationellen Profils gemäß des Vorschlags in [WPT95],
es entsteht das sog. Testprofil. Nach [Gut95] werden die darin enthaltenen Transitions-
TP
wahrscheinlichkeiten p ( si
, s j ) wie folgt berechnet:
p
TP
( s , s ) =
i
j
p
OP
i
OP
∑ p
su
, sv
∈S
( s , s ) q(
s , s )
u
j
( s , s ) q(
s , s )
Formel 4 Berechnung des Testprofils
TP
p ( si
, s j ) : Transitionswahrscheinlichkeit von Zustand si zu Zustand sj im Testprofil
OP
p ( si
, s j ) : Transitionswahrscheinlichkeit von Zustand si zu Zustand sj im op. Profil
q : Kostenfaktor für Übergang von Zustand si zu Zustand sj
( si
, s j )
S : Menge aller Modellzustände
Testfälle, die aus einem MCUM auf Basis eines Testprofils generiert werden, eignen sich
aufgrund der Verschiebung offensichtlich nicht mehr zur Abschätzung der erreichten
v
i
u
j
v
83

84
Q.E.D. – Testentwurfsprozess
Zuverlässigkeit. Vor deren Abschätzung muss das Testergebnis daher durch eine Gewichtung
zurück verschoben werden. Nach [Gut97] kann diese Gewichtung mit dem sog. likelihood-Quotienten
erfolgen:
E )
OP
E ( F ) = E(
F
ij
ij
)
TP
p
p
OP
TP
( s , s
i
( s , s
Formel 5 Rückberechnung der mittleren Fehlerrate
OP
( Fij
: Mittl. Fehlerrate der Transition von Zustand si zu Zustand sj mit dem op. Profil
E )
TP
( Fij
: Mittl. Fehlerrate der Transition von Zustand si zu Zustand sj mit dem Testprofil
Der errechnete Erwartungswert der Fehlerrate auf Basis des Testprofils wird mit dem
Quotienten aus der Original- und der getesteten Wahrscheinlichkeit multipliziert. Gutjahr
zeigt, dass das resultierende Ergebnis der erwartungstreuen Zuverlässigkeitsabschätzung
entspricht.
Damit ist es im Rahmen des Q.E.D.-Ansatzes möglich, die Benutzungszuverlässigkeit
abzuschätzen, a-priori Wissen über die Softwarefehleranfälligkeit einzubringen und Systeme
mit Operationen unterschiedlicher Risikoklassen zu testen.
4.3 Testfallgenerierung
Das „Marcov Chain Usage Model“ (MCUM) bildet als Testmodell den Kern des Testentwurfprozesses,
es stellt die Quelle für die Testfallgenerierung dar. Dieses Unterkapitel
widmet sich der Erzeugung der Testfälle, diese entsprechen einer Nachrichtensequenz auf
einem möglichen Pfad vom Start- zum Endzustand des Automatenmodells.
Beim statistischen Test erzeugt man Testfälle für zwei unterschiedliche Phasen der Testausführung.
Zunächst werden Testfälle aus nicht zufälligen Modelltraversierungen erzeugt
und ausgeführt. Beispiele hierfür sind Testfälle zur Abdeckung aller Zustände bzw.
Übergänge oder zur Überprüfung einer bestimmten Funktionalität. Dies hilft bei der Validierung
des MCUMs und dient zur Erfüllung von Vertragsbedingungen. In die Gewinnung
der Zuverlässigkeitsaussage, die in Kapitel 4.2.4 vorgestellt wurden, gehen die Testergebnisse
dieser Testphase nicht ein.
i
j
j
)
)

Testfallgenerierung
Im Anschluss daran wird der eigentliche statistische Test durchgeführt. Die Testfälle
werden bezüglich der im MCUM enthaltenen Auftretenswahrscheinlichkeiten zufällig
erzeugt und ausgeführt. Der Test spiegelt somit das tatsächliche bzw. vermutete spätere
Nutzungsverhalten wider und erlaubt die Abschätzung der erreichten Zuverlässigkeit des
Systems (siehe Kapitel 4.2.4).
Nichtdeterministisches & paralleles Verhalten
Die Erzeugung eines Testfalls weicht in zwei Fällen von der Grundregel des einfachen
Modellpfads ab. Bei Zuständen mit mehreren ausgehenden Transitionen mit identischen
Stimuli verhält sich das System nichtdeterministisch. Das bedeutet, dass für eine Systemeingabe
mehrere unterschiedliche korrekte Reaktionen auftreten dürfen. Abbildung 43
zeigt beispielhaft das Triggern des SUT mit einer Nachricht und zwei spezifizierten korrekten
Antworten OK und NOT_OK.
Abbildung 43 Nichtdeterminismus
Die Beachtung nur eines Pfades im Testfall kann das Testergebnis verfälschen. Es ist
daher notwendig, alle entsprechenden Folgepfade als alternative mögliche Fortsetzungen
zu übernehmen. Im ungünstigen Fall kann das den Umfang des erzeugten Testfalls stark
erhöhen, was z.B. durch eine „on-the-fly“-Generierung umgangen werden könnte. In diesem
Fall würde der jeweils nächste Testschritt erst zur Testlaufzeit generiert werden, entsprechend
der beobachteten Systemreaktion. Zur Realisierung müsste das gesamte
MCUM zur Ausführung gebracht werden, was z.B. durch eine Übersetzung in die
TTCN-3 möglich wäre.
Die zweite Ausnahme zur Grundregel ist der Fall parallelen Verhaltens. Dies wird im
MCUM durch einen orthogonalen zusammengesetzten Zustand beschrieben.
85

86
Abbildung 44 Paralleles Verhalten
Q.E.D. – Testentwurfsprozess
Abbildung 44 zeigt zwei, in der UML2 durch eine gestrichelte Linie angedeutete, Regionen
mit jeweils einer Sub-Zustandsmaschine. Für die Testfallgenerierung müssen alle
enthaltenen Zustandsmaschinen durchlaufen werden.
Synchronisierung
Bei Testkonfigurationen mit mehreren Testkomponenten muss für deren Synchronisierung
gesorgt werden, um eine korrekte Sendereihenfolge zu gewährleisten. Dies gilt nicht
nur für verteilte Tests, sondern auch für lokale Tests mit mehreren Prozessen bzw.
Threads. Die Notwendigkeit zur Synchronisierung verdeutlicht folgendes Beispiel.
Abbildung 45 Synchronisierung
Abbildung 45 links zeigt ein zu testendes Verhalten. Darin wird für die Systeminstanz
gefordert, dass zunächst die Nachrichten m1 und m2 mit der Benutzerinstanz User_1,
danach die Nachrichten n1 und n2 mit der Instanz User_2 ausgetauscht werden. Weiter-

Erzeugung der Testsuite
hin legt die partielle Ordnungsrelation der Sequenzdiagramme die zeitliche Reihenfolgen
m2 nach m1 und n2 nach n1 fest.
Die Freiheitsgrade liegen bei den Sendeereignissen der Nachrichten m1 und n1 und den
Empfangsereignissen der Nachrichten m2 und n2, deren Reihenfolgen nicht festgelegt
sind. Im vorliegenden Beispiel sind demnach folgende sechs Sendesequenzen erlaubt:
(m1, m2, n1, n2), (m1, n1, n2, m2), (m1, n1, m2, n2), (m1, n2, m1, m2), (n1, m1, m2, n2),
(n1, m1, n2, m2). Um die definierte Ereignisreihenfolge auf der Systeminstanz zu garantieren,
ist daher der Austausch von Synchronisierungsnachrichten notwendig.
Die Abbildung 45 rechts zeigt den resultierenden Testfall. Die spezielle Komponente
MTC signalisiert mit dem Versenden der Nachricht sync_ack, welche Testkomponente
eine Aktion durchführen darf. Der Empfang einer Nachricht wird durch eine sync-
Meldung an die MTC-Komponente quittiert.
Auch für diese Regel existiert ein Ausnahmefall. Für gefordertes paralleles Verhalten
wird keine zusätzliche Synchronisierung benötigt, da keine explizite Nachrichtenabfolge
definiert ist. Dies erzeugt die geforderte nichtdeterministische Verschränkung der beteiligten
Nachrichten.
4.4 Erzeugung der Testsuite
Die generierten Testfälle beschreiben das Verhalten des Testsystems, zur Vervollständigung
einer Testsuite muss auch dessen Struktur, also die Testkonfiguration, festgelegt
werden. Für jede modellierte Benutzerinstanz wird eine Testkomponente erzeugt. Zusätzlich
wird eine weitere Komponente zur Erfüllung folgender drei Aufgaben benötigt:
(1) Berechnung des finalen Testurteils. (2) Synchronisierung aller erstellten Testkomponenten.
(3) Protokollieren der Testausführung. Letzteres ist wichtig, um einen fehlerhaften
Testschritt identifizieren zu können. Dazu benötigt sie von den Testkomponenten ihre
zur Laufzeit erzeugten Testurteile. Um das Verschicken zusätzlicher Nachrichten zu vermeiden,
lässt sich diese Information z.B. als Parameter in den Synchronisierungsnachrichten
weitergeben.
Jede Benutzerkomponente besitzt daher neben einer Kommunikationsverbindung zum
„System Under Test“ einen zusätzlichen Port zu dieser Testkomponente. Das folgende
UML2-Kompositionsstrukturdiagramm stellt eine Beispielkonfiguration mit drei Benutzer-Testkomponenten
dar:
87

88
Abbildung 46 Beispiel-Testkonfiguration
Q.E.D. – Testentwurfsprozess
Die folgende Abbildung 47 fasst alle Bestandteile zur Beschreibung eines Tests als Paket
zusammen, die darin enthaltenen Stereotypen entsprechen dem „UML2 Testing Profile“
(U2TP) [OMG05a] (siehe Kapitel 3.7.3). Das Paket enthält die zur Abbildung 46 gehörenden
Testkomponenten und den Testkontext, bestehend aus der Testkonfiguration, zehn
Testfällen und dem Attribut verdict für das Testurteil.
Abbildung auf die TTCN-3
Abbildung 47 Beispiel-TestPackage
Zur Ausführung muss der Test in eine ausführbare Sprache übersetzt werden, für U2TPkonforme
Testsuiten existiert keine weitere Werkzeugunterstützung. Bei der Entwicklung

Erzeugung der Testsuite
der U2TP wurde jedoch auf verbreitete Testsprachen und -konzepte Rücksicht genommen.
Die Abbildung auf die TTCN-3 gelingt problemlos, der Standard [OMG05a] enthält
neben Beschreibungen für das Mapping auch ausführliche Konzeptvergleiche. In [SG02]
wird die größere Ausdrucksstärke der TTCN-3 im Vergleich zur U2TP beschrieben mit
dem Ergebnis, dass ein vollständiges Mapping in Richtung der TTCN-3 möglich ist, jedoch
nicht umgekehrt.
Eine ausführliche Beschreibung der TTCN-3 findet sich in Kapitel 2.3. Jede Benutzerinstanz
wird auf eine parallele Testkomponente (PTC) der TTCN-3 abgebildet. Die Sonderaufgaben
der Synchronisierung, des Protokollierens und der Bildung des finalen Testurteils
übernimmt die Haupt-Testkomponente (MTC).
Die TTCN-3-Testkonfiguration entspricht der Konfiguration in der U2TP. Die MTC besitzt
einen Port zu allen PTCs, letztere realisieren das eigentliche Verhalten der Testfälle
über Ports zum getesteten System.
Abschließend fehlen datenbezogene Informationen, d.h. die eigentlichen Testdaten müssen
definiert, Datentypen und Templates müssen beschrieben werden (Beispiel siehe Kapitel
2.3.5).
Wie in Kapitel 2.3.8 beschrieben, können die nicht-funktionalen Anforderungen der Testfälle
nur schlecht auf die TTCN-3 abgebildet werden, dazu sind ihre Mittel für die Zeitbehandlung
zu ungenau. Dagegen ist eine Abbildung in die TimedTTCN-3 [Neu04] (siehe
Kapitel 2.3.8) möglich, insbesondere durch das in ihr enthaltene Uhrenkonzept zur
Abfrage der absoluten Zeit.
Neben einer Konzeptbeschreibung enthält [Neu04] auch Entwurfsmuster zum Testen von
Antwortzeiten, Latenzzeiten und Durchsatzanforderungen in der TimedTTCN-3. Der Test
weicher Zeitgrenzen und der Test statistischer Verteilungen sind nicht beschrieben, jedoch
auch möglich. In der TimedTTCN-3 lassen sich Algorithmen implementieren, die
komplexere Berechnungen auf einer Menge von Zeitstempeln durchführen. Deren Ergebnisse
können direkt in die Bildung eines Testurteils einfließen.
Abbildung 48 stellt TimedTTCN-3 Code zum Test der Verteilungsfunktions-Anforderung
in Abbildung 31 dar. Zwei Nachrichten werden zwanzigmal mit der SUT ausgetauscht,
deren Antwortzeiten in einem Array gespeichert werden. Zusammen mit der Angabe der
geforderten Verteilungsfunktion und Parametern wird die Auswertefunktion aufgerufen.
89

90
function user_function1() runs on user_type {
var float respTime[], parameters[];
var float timestamp1, timestamp2;
var integer s, t;
Q.E.D. – Testentwurfsprozess
for(s := 0, t := 0; s < 20; s := s+1, t := t+1) {
user_type2sut.send(ICONreq);
timestamp1 := self.now;
user_type2sut.receive(ICONconf);
timestamp2 := self.now;
respTime[t] := timestamp2 – timestamp1;
}
parameters[0] := 0.5;
setverdict(eval_Kol_Smi(exponential, parameters, respTime));
}
function eval_Kol_Smi(distribution dist, float param_array, float
time_array) {
… // Kolmogorov-Smirnov test
}
Abbildung 48 Test einer Verteilungsfunktions-Anforderung
In ihr kann ein Algorithmus eines klassischen „goodness-of-fit“ Tests implementiert sein.
Neben des hier angedeuteten Kolmogorov-Smirnov-Tests gehören der Anderson-Darling-
und der Chi-Quadrat-Test zu bekannten Verfahren, die zum Testen einer Verteilungsfunktions-Anforderung
anwendbar sind [LK00]. Dazu empfiehlt sich die Bereitstellung verschiedener
Auswertefunktionen in einer Funktionsbibliothek.
Die beschriebenen Transformations- und Generierungsschritte sind automatisierbar, per
Hand muss die Schnittstelle zwischen Testsystem und dem getesteten System implementiert
werden. Ihre Realisierung ist stark von der jeweiligen Systemimplementierung abhängig,
Hauptaufgabe dieser Schnittstelle ist die Umwandlung der Daten in die jeweils
andere Repräsentation. Für die TTCN-3 existiert eine standardisierte API, das „TTCN-3
Runtime Interface“ [ETS07b].
Die abstrakte TTCN-3 Testsuite (ATS) ist damit vollständig beschrieben, Standardwerkzeuge
für die TTCN-3 können diese in eine ausführbare Version (ETS) kompilieren und
unter einer graphischen Oberfläche benutzerfreundlich ausführen.

Zusammenfassung
4.5 Zusammenfassung
Der Q.E.D.-Entwurfsprozess beschreibt die Möglichkeit, ausgehend von Szenarienbeschreibungen
Testfälle zu erstellen, die es ermöglichen, aus den Testergebnissen Rückschlüsse
auf die erreichte Softwarezuverlässigkeit zu ziehen.
Möglich wird dies durch die Erstellung eines speziellen Testmodells, des „Markov Chain
Usage Models“. Für dessen Erstellung wird in diesem Kapitel eine detaillierte Abbildungsvorschrift
gegeben, die alle erlaubten Elemente der UML2-Sequenzdiagramme berücksichtigt.
Nach der Betrachtung sinnvoller Zeit- und Leistungsanforderungen für den
Black-Box-Test wird auch für diese die Abbildung auf das MCUM beschrieben. Schließlich
wurde über die Semantikunterschiede diskutiert, die zwischen der Spurensemantik
der Szenarien und der Testmodellsemantik des MCUMs auftreten. Dabei wurde festgestellt,
dass zwar Differenzen existieren, diese jedoch zu akzeptieren sind (siehe Kapitel
4.2.3).
Bei der Testfallgenerierung aus dem MCUM wurde auf die benötigte Synchronisierung
zwischen verschiedenen Testkomponenten aufmerksam gemacht. Für deren Regelung
tauschen diese mit einer Kontrollinstanz Synchronisierungsnachrichten aus. Ebenso werden
zwei Sonderfälle betrachtet (nichtdeterministisches und paralleles Verhalten), die bei
der Testfallerzeugung gesondert behandelt werden müssen.
Zur Testausführung wird im Q.E.D.-Prozess eine Testsuite in der Testsprache TTCN-3
erzeugt. Für den Test von Zeit- und Leistungsanforderungen existiert eine Erweiterung
der Sprache, die TimedTTCN-3, mit der auch das Testen von weichen Zeitgrenzen möglich
ist. Für komplexere Auswertefunktionen von statistischen Vorgaben wird die Bereitstellung
von Funktionsbibliotheken vorgeschlagen.
Für die Auswertung der Testergebnisse wurden existierende Algorithmen beschrieben.
Neben der Abschätzung der erreichten Benutzungszuverlässigkeit kann auch vorab vorhandenes
Wissen über die Fehleranfälligkeit in die Berechnung mit einfließen. Schließlich
lässt sich mit Hilfe der „Importance Sampling“-Technik auch Software mit verschiedenen
Fehlerklassen auswerten.
91

92
Q.E.D. – Testentwurfsprozess

5 Anwendungsstudie DECT
Alle Transformations- und Generierungsschritte des Q.E.D.-Ansatzes wurden im Rahmen
dieser Arbeit implementiert. Die daraus entstandene Werkzeugkette konnte an einer realen
Fallstudie erprobt werden [Bie06].
Die Projektgruppe CCIOS (Competence Center for InterOperative Systems) des Fraunhofer
Instituts für Integrierte Schaltungen stellte für diese Studie sechs DECT-Funkmodule
M5 aus eigener Entwicklung zur Verfügung. DECT [ETS99] steht für „Digital Enhanced
Cordless Telephony“ und ist ein Standard der ETSI (European Telecommunications
Standards Institute) für die drahtlose Sprach- und Datenübertragung.
DECT Funkmodul M5
Das DECT Modul M5 stellt eine Basisplattform für die Entwicklung kundenspezifischer
Produkte dar. Es kann sowohl im DECT-Frequenzbereich um 1,9 GHz funken als auch im
ISM-Bereich um 2,4 GHz. Bis zu fünf Verbindungen können gleichzeitig aufgebaut werden,
werden diese gebündelt, wird eine Datenrate von 160 kbit/s erreicht. Sprachkonferenzen
sind mit bis zu fünf Teilnehmern möglich. Das Datenübertragungsprotokoll ist auf
niedrige Verzögerungszeiten optimiert, Antennendiversität ist bei der Feststation („fixed
part“, FP) oder beim Mobilteil („portable part“, PP) möglich, um auch unter ungünstigen
Empfangsbedingungen sicheren Betrieb zu gewährleisten.
Der Zugriff auf das Funkmodul ist über eine AT-Modem-Schnittstelle und über ein neu
entwickeltes „DECT Host Controller Interface“ (DHCI) möglich. In der vorliegenden
Fallstudie wurden die DECT-Module über das DHCI getestet.
Das DHCI ist eine Schnittstelle zwischen dem Funkmodul und dem Host bzw. dem Benutzer.
Darüber lassen sich sowohl Benutzerdaten als auch Signalisierungsinformationen
zur Steuerung des DECT-Systems übertragen. Die genaue Schnittstellenspezifikation
kann in [Stu05] nachgelesen werden.
Die Module sind konfigurierbar, um sowohl als FP als auch als PP zu fungieren. Es wurden
zwei verschiedene Testkonfigurationen verwendet. Die eine bestand aus zwei Basisstationen
und zwei Mobilteilen, für erweiterte Testfälle kamen zwei weitere Mobilteile
hinzu. Die maximale Testkonfiguration bestand demnach aus sechs DECT-Modulen bzw.
sechs Testkomponenten (siehe Abbildung 49).
93

94
Werkzeugkette
Abbildung 49 Testkonfiguration DECT-Fallstudie
Anwendungsstudie DECT
Für jeden benötigten Transformations- und Generierungsschritt wurde ein Werkzeug für
die Automatisierung implementiert. Die Basisrepräsentation jedes Modells war das Standardaustauschformat
der UML, die XMI in der Version 2.0 [OMG05c] (siehe Kapitel
3.5). Da es sich dabei um eine XML-Notation handelt, kamen für die Implementierung
der Werkzeugkette Sprachen mit guter XML-Unterstützung in Betracht.
Die „Extensible Stylesheet Language Transformation“ (XSLT) [W3C99] ist als Sprache
zur Manipulation von XML-Dokumenten von der W3C („World Wide Web Consortium“)
standardisiert. Die XSLT beschreibt die Transformation eines XML-Dokuments in
ein anderes XML-Dokument oder in ein beliebig anderes Format.
Ihre Verwendung bringt zwei Vorteile. Zum einen werden die nötigen Transformationsschritte
ebenso in Form eines wohldefinierten XML-Dokuments beschrieben. Zum zweiten
muss keine vollständige Anwendung implementiert werden, es genügt, Regeln anzugeben,
in welcher Form das Quell- in ein Zielformat umzuwandeln ist. Dies vereinfacht
ihre kaskadierte Anwendung in einer Toolkette.

Anwendungsstudie DECT
JDOM 1 stellt eine API für die objekt-orientierte Programmiersprache Java dar. Es ermöglicht
den einfachen Zugriff, die Manipulation und die Ausgabe von XML-Dokumenten
aus Java Code heraus. Bei vorhandener Kenntnis der Sprache Java bleibt der Implementierer
somit in seiner gewohnten Programmierumgebung. Des Weiteren steht die gesamte
Bibliotheksvielfalt von Java zur Verfügung, um erweiterte Funktionen während der
Transformation durchzuführen.
Als Modellierungswerkzeug für die UML wurde IBM Rational Software Architect (RSA) 2
Version 6.0 gewählt, welches das Austauschformat XMI in der Version 2.0 unterstützt.
Ein Problem der XMI war und ist das Fehlen einer Referenzimplementierung. Ein Ergebnis
davon war das Entstehen von werkzeug- und herstellerspezifischen XMI-
Implementierungen, die untereinander nur wenig kompatibel sind.
Die stetig wachsende Eclipse-Gemeinschaft 3 , ein Open-Source-Vorhaben zur Bereitstellung
einer einheitlichen Software-Entwicklungsplattform, trieb die Verbreitung der XMI
2.0 voran. Eine wesentliche Komponente ihrer Plattform, das Eclipse Modeling Framework
(EMF) 4 , welches Aufgaben zur Modellbearbeitung und Codegenerierung vereint,
nutzt diese XMI-Version als kanonisches Speicherformat aller Modelle.
Die Eclipse gründete ein UML2-Projekt 5 mit der Zielvorgabe, eine anwendbare Referenzimplementierung
des UML2-Metamodells bereitzustellen, um die Entwicklung von Modellierungstools
zu unterstützen. Die Verwendung eines gemeinsamen XMI-Schemas
ermöglicht den Austausch von semantischen Modellen. Im Jahre 2004 veröffentlichte das
Projekt ihre erste Implementierung des Metamodells der UML 2.0.
Da das UML2-Projekt auf der EMF basiert, können UML-2.0-konforme Modelle erstellt
und im – vom EMF unterstützten – XMI-2.0-Format serialisiert werden. Kommerzielle
Tools von IBM und von Omondo 6 setzen auf die Implementierung des UML2-Projekts als
Basisplattform.
1 http://www.jdom.org
2 http://www.ibm.de
3 http://www.eclipse.org
4 http://www.eclipse.org/emf/
5 http://www.eclipse.org/uml2/
6 http://www.omondo.de
95

96
Anwendungsstudie DECT
Standardkonform ist dieses Speicherformat für die UML 2.x jedoch nicht, da die XMI 2.0
auf MOF 1.4 basiert (siehe Kapitel 3.5). Seit Anfang 2006 unterstützt eine neue EMF
Version 2.2 die für MOF 2.0 entwickelte Version XMI 2.1. Auch das UML2-Projekt veröffentlicht
aktualisierte Versionen, so existieren bereits Vorversionen einer Metamodellimplementierung
der UML 2.1 [OMG06a]. Die gesamte – in dieser Arbeit implementierte
– Werkzeugkette verarbeitet Modelle im XMI-2.0-Format.
Durchführung des Fallbeispiels
Für die DECT-Module wurden ca. 230 Anforderungsszenarien definiert und im Tool RSA
in Form von Sequenzdiagrammen beschrieben. Benutzerdefinierte Zustände in Form von
Zustandsinvarianten können in der aktuellen Werkzeug-Version nicht modelliert werden,
sie mussten daher nachträglich mit dem Baumeditor von Eclipse eingefügt werden. Zeit-
und Leistungsanforderungen wurden in dieser Anwendungsstudie nicht beschrieben, da
diese durch die Zielsprache TTCN-3, wie in Kapitel 2.3.8 beschrieben, nicht unterstützt
werden. Für deren Erweiterung, die TimedTTCN-3, existiert noch keine Werkzeugunterstützung.
Die folgenden Abbildungen wurden mit dem Werkzeug RSA erstellt.
Abbildung 50 On-Air Subscription

Anwendungsstudie DECT
Abbildung 50 zeigt exemplarisch die Durchführung einer „On-Air Subscription“, also
eines Einlernvorgangs zwischen Mobilteil und Feststation über die Luftschnittstelle. Die
Empfangsreihenfolge der Indication-Nachrichten vom System ist beliebig, die Nachrichten
sind daher in einem parallelen Fragment modelliert.
Für die Generierung des MCUM wurde der Algorithmus aus Kapitel 4.2.3 in Form von
XSLT-Stylesheets implementiert [Sus05]. Ein XSLT-Prozessor wird mit der Quelldatei
und den Transformationsregeln in den implementierten Stylesheets aufgerufen. Dies erzeugte
beim Fallbeispiel eine UML-Protokollzustandsmaschine mit ca. 900 Zuständen,
die Erstellungszeit lag bei 15 bis 20 Minuten. Die folgende Abbildung 51 stellt eine Skizze
des resultierenden MCUM dar. Es enthält Zustände für verschiedene Sprach-, Daten-
und kombinierte Verbindungen, für „Streaming“-Dienste und verschiedene Telefonkonferenz-Modi.
Abbildung 51 DECT - MCUM
Für das operationelle Profil kann durch ein XSLT-Stylesheet eine Adjazenzliste ausgegeben
werden. Diese enthält die Zustände des MCUM und standardmäßig gleichverteilte
Übergangswahrscheinlichkeiten. Die Liste kann bezüglich eines operationellen Profils
angepasst werden und anschließend automatisch in das MCUM eingelesen werden. Zu
97

98
Anwendungsstudie DECT
diesem Zweck wurde die XMI-Syntax für die Statechart-Transition um ein Attribut zur
Aufnahme des Wahrscheinlichkeitswerts erweitert. Für die Anpassung der Gleichverteilung
im Rahmen der Fallstudie gingen nach Gesprächen mit Entwicklern der DECT-
Module deren Erfahrungen mit Vorgängerversionen ein.
Für die Testfallgenerierung wurde zunächst ein weiteres Stylesheet implementiert. Es
stellte sich jedoch heraus, dass auf Grund des rekursiven Charakters von XSLT die Modelltraversierung
unerwartet zeitaufwändig war. Trotz 2 GB an Arbeitsspeicher im Testrechner
kam es zu Abbrüchen aus Speichergründen, so kam es trotz manueller Erhöhung
der Speicherzuweisung an die JavaVM zu häufigen Stapelüberläufen. Durch Evaluierung
von Kombinationen verschiedener Betriebssysteme, XSLT-Prozessoren und Virtuellen
Maschinen von Java wurde eine Erstellungszeit pro Testfall von ca. 5 Minuten erreicht.
[Bie05] listet Details zu den durchgeführten Experimenten auf. Eine Reimplementierung
des Prozesses für die Testfallgenerierung in Java mit JDOM brachte mit 1 Minute pro
Testfall eine Geschwindigkeitsoptimierung [Kol06].
Abbildung 52 Beginn eines Testfalls

Anwendungsstudie DECT
Testfälle lassen sich durch zufällige Traversierung oder mit dem Ziel einer Zustands-
bzw. Transitionsüberdeckung erzeugen. In Abbildung 52 ist der Beginn eines Testfalls
mit automatisch eingefügten Synchronisierungsnachrichten (siehe Kapitel 4.3) zu sehen.
Ein weiteres XSLT-Stylesheet steht zur Verfügung, um nach den Regeln gemäß Kapitel
4.4 eine TTCN-3-Testsuite zu erzeugen [Li05]. Ca. 200 Testfälle wurden erzeugt und
übersetzt, die Testsuite um benötigte Dateninformationen und die Schnittstelle zur DHCI
ergänzt. Das Werkzeug Telelogic Tau G2 1 kompilierte die komplette Testsuite in eine
ausführbare Form in ca. drei Stunden. Pro Testfall erzeugte der Compiler 3-20 MB C-
Code. Neben der Testfalllänge war insbesondere das Auflösen vorhandener interleave-
Anweisungen (siehe Kapitel 2.3.6) für die Codegröße verantwortlich.
Die Testausführung förderte zehn Fehler unterschiedlichen Typs zu Tage. Unter anderem
wurden falsche Werte in den Nachrichtenfeldern erkannt. Ein Beispiel ist die Statusabfrage
der aufgebauten Verbindungen mittels der CON_STATE+REQ-PDU, die mit einem
falschen „MBC“-Wert beantwortet wurde. Dieser gibt die Anzahl der Slots für Daten-
und Streamingverbindungen wieder.
Ein weiterer Fehlertyp war der Empfang einer – im aktuellen Zustand – nicht spezifizierten
Nachricht. Im unsynchronisierten Zustand bekam das Mobilteil beispielsweise auf
eine Anfrage zum Setzen eines Parameters zusätzlich zur spezifizierten Antwortnachricht
eine Synchronisationsanzeige mit der Information „Out Of Sync“.
Weiterhin ließ sich nach einer „On-Air Subscription“ keine Vierer-Konferenz aufbauen.
Schließlich wurden mehrmals „On Air Subscriptions“ oder Verbindungsaufbauwünsche
oder -abbauwünsche mit einem Timeout quittiert.
Die Anwendbarkeit des Q.E.D.-Ansatzes wurde somit demonstriert. Weiterhin wurde ein
Algorithmus zur Abschätzung der erreichten Benutzungszuverlässigkeit nach Whittaker
und Thomason (siehe Kapitel 4.2.4) in Java implementiert [Shi05]. Leider verhinderte die
zu diesem Zeitpunkt langwierige Erzeugung die Generierung einer aussagekräftigen Anzahl
von Testfällen. So konnte nur eine Zustandsüberdeckung von unter zehn Prozent
erreicht werden. Die Berechnung einer sinnvollen Zuverlässigkeitsabschätzung war unter
diesen Umständen nicht möglich.
1 http://www.telelogic.de
99

100
Fazit
Anwendungsstudie DECT
Die durchgeführte Anwendungsstudie zeigt die Einsatzfähigkeit des Q.E.D.-Ansatzes im
realen Umfeld. Durch den Einsatz der implementierten Werkzeugkette waren nur wenige
manuelle Eingriffe nötig, um aus Szenarienbeschreibungen in der UML2 statistische Testfälle
in der TTCN-3 zu erzeugen und auszuführen.
Ein Problem stellte die schlechte Performanz der Testfallerzeugung mit Hilfe des XSLT-
Stylesheets dar, so dass die Berechnung einer sinnvollen Zuverlässigkeitsaussage mit der
erreichten niedrigen Zustandsüberdeckung nicht möglich war. Eine schnellere Version in
Java wurde erst mit Abgabe dieser Arbeit fertig gestellt. Eine Möglichkeit zur Umgehung
des Performanzproblems stellt zudem die „on-the-fly“-Generierung dar, bei der im Vorfeld
keine Testfälle erzeugt werden müssen. Stattdessen würde während der Testausführung
jeweils nur der nächste Testschritt erzeugt werden. Dies würde jedoch zu Lasten
möglicher Regressionstests gehen, also die Wiederholung bereits durchgeführter Testfälle
erschweren.

6 Zusammenfassung
In dieser Arbeit wurde der Q.E.D.-Testentwurfsprozess vorgestellt, eine systematische
Vorgehensweise zur Erzeugung von statistischen Testfällen. Der Prozess zeichnet sich
durch mehrere Merkmale aus:
Zum einen ist der Prozess szenarienbasiert, d.h. den Ausgangspunkt bilden Szenarien, die
in Form von Objektinteraktionen Anforderungen an ein System beschreiben. Ein weiteres
Kennzeichen ist die Verwendung von aktuellen Sprachstandards, die in ihren Domänen
eine hohe Bedeutung besitzen. So findet der Großteil des Entwurfprozesses innerhalb der
UML2 statt, dem de-facto-Standard für die modellgestützte Softwareentwicklung. Als
dedizierte Testsprache dient die TTCN-3, die einzige standardisierte Notation für diese
wichtige Phase des Softwareentwurfs. Die statistische Auswahl der Testfälle ermöglicht
es auf Basis der Testergebnisse Aussagen über die erreichte Systemzuverlässigkeit aus
Benutzersicht zu treffen. Diese Metrik unterstützt den Entscheidungsprozess bezüglich
einer Systemfreigabe.
Die Idee des szenarienbasierten statistischen Tests hat ihren Ursprung im europäischen
IST Projekt „Markov Test Logic“ (MaTeLo) [BD03, BD04, DZ03]. Darin wurden einfache
Szenarien als „Message Sequence Charts“ betrachtet, die in ein Modell mit einer eigenentwickelten
Beschreibungssprache übersetzt wurden, um statistische Testfälle zu
erzeugen.
Im Q.E.D.-Entwurfsprozess wird konsequent auf die UML2 gesetzt, ihre große Verbreitung
fördert sowohl das Verständnis als auch die Anwendbarkeit des Ansatzes. Zur Beschreibung
der Anforderungsszenarien dienen die Sequenzdiagramme, deren voller
Sprachumfang unterstützt wird. So sind auch komplexere Beschreibungen möglich, die
durch unterschiedliche Kombination einfacher Szenarien entstehen können. Außerdem
wurden relevante Zeit- und Leistungsaspekte diskutiert, die während des Black-Box-Tests
evaluiert werden können. Dazu gehören Antwort- und Latenzzeiten, der Durchsatz und
die Überprüfung von Nachrichtenankunftszeiten auf eine geforderte Verteilung hin. Auf
die Notwendigkeit der Synchronisierung verschiedener Testkomponenten wird eingegangen.
Es wird eine Vorschrift für den Austausch von Synchronisierungsnachrichten gegeben,
mit der die Einhaltung der korrekten Sende- und Empfangsreihenfolge gewährleistet
wird. Außerdem wurden die Sonderfälle von nichtdeterministischem und parallelem Ver-
101

102
Zusammenfassung
halten identifiziert, bei denen der generierte Testfall vom einfachen Pfad im Testmodell
abweicht.
Zur Demonstration der Anwendbarkeit wurden alle benötigten Transformations- und
Auswertungsschritte prototypisch in einer Werkzeugkette implementiert und in einer realen
Fallstudie eingesetzt.
6.1 Ausblick
Aus Sicht des Entwurfsprozesses wäre eine weitere Fokussierung auf die UML denkbar
und wünschenswert, indem die TTCN-3 als eingesetzte Testsprache obsolet werden würde.
Die implementierte Werkzeugkette generiert bereits eine Testsuite in der UML2 (vgl.
Kapitel 4.4), welche jedoch aus mehreren Gründen in die TTCN-3 übersetzt wird. Zum
einen ist das Testprofil der UML2 ausdrucksschwächer, es gibt keine standardisierten
Schnittstellen, und es fehlt im Gegensatz zur TTCN-3 die Werkzeugunterstützung für die
Testausführung.
Ein weiterer Punkt betrifft den Zeitpunkt der Testfallgenerierung. Wie in Kapitel 4.3 diskutiert,
werden die Testfälle vollständig vor der Testausführung erzeugt. Dieser Generierungsvorgang
ist zwar zeitunkritisch, er kann jedoch zum Speicherproblem führen, da
durch die nötige Beachtung aller nichtdeterministischer Systemreaktionen sehr große
Testfälle entstehen. Eine mögliche Lösung wäre ein ausführbares Testmodell, also z.B.
die Übersetzung des gesamten MCUM in die TTCN-3. Der jeweils nächste Testschritt
könnte „on-the-fly“ erst während der Testausführung generiert werden und so der speicherintensive
Vorgang der Generierung vollständiger Testfälle umgangen werden.
Außerdem ist für die Evaluierung der geforderten Zeit- und Leistungsvorgaben eine
Werkzeugunterstützung für die TimedTTCN-3 wünschenswert. Zur Überprüfung von
statistischen Anforderungen wäre, wie in Kapitel 4.4 beschrieben, der Aufbau einer Bibliothek
sinnvoll, in der verschiedene Auswertefunktionen zur Verfügung gestellt werden.
Damit würde auch das Testen erweiterter Leistungsanforderungen größere Verbreitung
erfahren.

Abbildungsverzeichnis
Abbildung 1 V-Modell, nach [Bal98] ................................................................................. 6
Abbildung 2 Modellbasiertes Testen – Szenarien, nach [PP05] ....................................... 10
Abbildung 3 „Model Driven Testing“ [ZDS+05] ............................................................. 16
Abbildung 4 Benutzersicht auf die TTCN-3 [ETS07a]..................................................... 19
Abbildung 5 Allgemeine Struktur eines TTCN-3 Testsystems, nach [ETS07c]............... 19
Abbildung 6 Allgemeines verteiltes TTCN-3 Testsystem, nach [ETS07c] ...................... 21
Abbildung 7 Typische TTCN-3 Testkonfiguration [ETS07a] .......................................... 21
Abbildung 8 Anweisung für alternatives Verhalten.......................................................... 24
Abbildung 9 INRES - Protokoll ........................................................................................ 25
Abbildung 10 INRES - Testfall......................................................................................... 26
Abbildung 11 Vier-Ebenen Hierarchie der UML, nach [OMG07b] ................................. 37
Abbildung 12 Die Rolle des „Core“-Pakets im MOF-Umfeld [OMG07b]....................... 38
Abbildung 13 UML2-Diagrammtypen, nach [JRH+04] ................................................... 39
Abbildung 14 Protokolltransition...................................................................................... 42
Abbildung 15 XMI in der Vier-Ebenen-Hierarchie, nach [Jec04] .................................... 43
Abbildung 16 Ordnungsbeziehung.................................................................................... 47
Abbildung 17 Interaktionsreferenz.................................................................................... 48
Abbildung 18 Dekomposition ........................................................................................... 48
Abbildung 19 Zustandsinvarianten.................................................................................... 49
Abbildung 20 Ausführungsfocus....................................................................................... 49
Abbildung 21 SPT-Profil Struktur [OMG05b].................................................................. 51
Abbildung 22 SPT - Time Modeling [OMG05b].............................................................. 52
Abbildung 23 SPT - Performance Modeling [OMG05b].................................................. 53
Abbildung 24 Syntax der Zeitwerte .................................................................................. 55
Abbildung 25 MARTE – Subprofile [OMG05e] .............................................................. 56
Abbildung 26 Q.E.D.-Testentwurfsprozess....................................................................... 59
Abbildung 27 Use-Case-Diagramm .................................................................................. 62
Abbildung 28 Antwortzeit - Anforderung........................................................................ 63
Abbildung 29 Latenz - Anforderung ................................................................................. 64
Abbildung 30 Durchsatz - Anforderung............................................................................ 64
Abbildung 31 Verteilungsfunktions - Anforderung .......................................................... 65
Abbildung 32 Einfaches MCUM....................................................................................... 67
Abbildung 33 Ordnungsrelation........................................................................................ 70
Abbildung 34 Auflösung des „ignore“-Fragments............................................................ 72
103

104
Abbildungsverzeichnis
Abbildung 35 Transformation - Basisregeln ..................................................................... 73
Abbildung 36 Zustandsmaschine des INRES-Protokolls.................................................. 74
Abbildung 37 Transformation - Konkatenation ................................................................ 74
Abbildung 38 Transformation - Kombinierte Fragmente (Teil 1) .................................... 75
Abbildung 39 Transformation - Kombinierte Fragmente (Teil 2) .................................... 76
Abbildung 40 Transformation – SPT-Annotation............................................................. 77
Abbildung 41 Erweitertes Use-Case-Diagramm............................................................... 78
Abbildung 42 Zusammengesetztes MCUM ...................................................................... 78
Abbildung 43 Nichtdeterminismus.................................................................................... 85
Abbildung 44 Paralleles Verhalten.................................................................................... 86
Abbildung 45 Synchronisierung........................................................................................ 86
Abbildung 46 Beispiel-Testkonfiguration......................................................................... 88
Abbildung 47 Beispiel-TestPackage ................................................................................. 88
Abbildung 48 Test einer Verteilungsfunktions-Anforderung ........................................... 90
Abbildung 49 Testkonfiguration DECT-Fallstudie........................................................... 94
Abbildung 50 On-Air Subscription ................................................................................... 96
Abbildung 51 DECT - MCUM.......................................................................................... 97
Abbildung 52 Beginn eines Testfalls ................................................................................ 98

Literatur
[AKW+02] A. Avritzer, J. Kondek, E. J. Weyuker et.al.. Software Performance
Testing Based on Workload Characterization, In: Proceedings of WOSP
02, Rom, Juli 2002
[AW95] A. Avritzer, E. J. Weyuker. The Automatic Generation of Load Test
Suites and the Assessment of the Resulting Software. IEEE Transac-
tions on Software Engineering, Vol. 21, No. 9, September 1995
[Bal98] H. Balzert. Lehrbuch der Software-Technik, vol. 2, Spektrum Akademi-
scher Verlag, Heidelberg, Berlin, Oxford, 1998
[BD03] M. Beyer, W. Dulz. Scenario-Based Statistical Testing of Quality-of-
Service Requirements, Scenarios: Models, Transformations and Tools.
International Workshop, Dagstuhl, September 2003
[BD04] M. Beyer. QED - A Framework for QoS-Enhanced Development based
on the UML and TTCN-3. Interner Bericht. Erlangen: Friedrich-
Alexander-Universität Erlangen-Nürnberg. Februar 2004
[BDD+01] M. Birbeck, J. Diamon, J. Duckett et.al.. Professional XML 2nd Edition,
Wrox Press Verlag, 2001
[BDH06] M. Beyer, W. Dulz, K.-S. Hielscher. Performance Issues in Statistical
Testing, In: Proceedings of the Conference on Measurement, Modeling
and Evaluation of Computer and Communication Systems (MMB),
Nürnberg, März 2006
[BFG+99] M. Bozga, J-C. Fernandez, L. Ghirvu et.al.. IF: An intermediate repre-
sentation and validation environment for timed asynchronous systems.
In: Proceedings of the World Congress on Formal Methods in the De-
velopment of Computing Systems, Volume I (FM 1999), Springer Ver-
lag, 1999
[Bie05] M. Biegel. Statistisches Testen von DECT-Modulen, Diplomarbeit,
Institut für Informatik 7, Universität Erlangen-Nürnberg, November
2005
[Bie06] M. Biegel. Statistical Testing of DECT modules, In: Proceedings of the
MMB Workshop, Model-Based Testing, Nürnberg, März 2006
105

106
Literatur
[Bir97] A. Birolini. Zuverlässigkeit von Geräten und Systemen, Springer Ver-
lag, Berlin, Heidelberg, New York, 1997
[BJK+05] M. Broy, B. Jonsson, J.-P. Katoen, et. al.. „Model-Based Testing of
Reactive Systems”, Springer LNCS 3472. 2005
[Coc00] A. Cockburn. Writing Effective Use Cases, Addison-Wesley, Oktober
2000
[DH01] W. Damm, D. Harel. LSCs: Breathing Life into Message Sequence
Charts, Formal Methods in System Design, Kluwer Academic Publish-
ers, 19, 45-80, 2001
[DIN94] DIN ISO 9000-4. Normen zu Qualitätsmanagement und zur Darlegung
von Qualitätsmanagementsystemen; Leitfaden zum Management von
Zuverlässigkeitsprogrammen, Beuth Verlag, Berlin, Juni 1994
[DN84] J. W. Duran, S. C. Ntafos. “An evaluation of random testing”, IEEE
Transactions on Software Engineering, Vol. 10, No. 4, Juli 1984
[Dou04] B. P. Douglass. Real Time UML Third Edition, Addison-Wesley, 2004
[DZ03] W. Dulz, F. Zhen. „MaTeLo - Statistical Usage Testing by Annotated
Sequence Diagrams, Markov Chains and TTCN-3”, Third International
Conference on Quality Software (QSIC 2003), Dallas, Texas , Novem-
ber 6-7 2003
[ECM+99] A. S. Evans, S. Cook, S. Mellor et.al. Advanced Methods and Tools for
a Precise UML, In: 2nd International Conference on the Unified Model-
ing Language. Editors: B.Rumpe and R.B.France, Colorado, LNCS
1723, 1999.
[ETS07a] ETSI. Methods for Testing and Specification (MTS); The Testing and
Test Control Notation version 3; Part 1: TTCN-3 Core Language, ES
201 873-1 V3.2.1, Februar 2007
[ETS07b] ETSI. Methods for Testing and Specification (MTS); The Testing and
Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface
(TRI), ES 201 873-5 V3.2.1, Februar 2007
[ETS07c] ETSI. Methods for Testing and Specification (MTS); The Testing and
Test Control Notation version 3; Part 6: TTCN-3 Control Interface
(TCI), ES 201 873-6 V3.2.1, Februar 2007
[ETS99] ETSI. Digital Enhanced Cordless Telecommunications (DECT); Com-
mon Interface (CI); Part 1: Overview, EN 300 175-1, Juni 1999

Literatur
[FHP02] E. Farchi, A. Hartman, S. S. Pinter. Using a Model-based Test Genera-
tor to Test for Standard Conformance, IBM System Journal - special is-
sue on Software Testing. Volume 41(1) (2002), S. 89 - 110.
[GJV96] Erich Gamma, Ralph Johnson, John Vlissides. "Entwurfsmuster - Ele-
mente wiederverwendbarer objektorientierter Software", Addison-
Wesley 1996, ISBN 3-8273-1862-9
[GKO+00] Y. Gurevich, P. Kutter, M. Odersky et.al.. Abstract State Machines:
Theory and Applications, Lecture Notes in Computer Science, vol.
1912, Springer Verlag, 2000
[GM02] H. L. Guen, R. Marie. “Visiting Probabilities in Non-Irreducible
Markov Chains with Strongly Connected Components”, European
Simulation Multiconference: Modelling and Simulation 2002, Darm-
stadt, Juni 2002
[GNS+94] J. Grabowski, R. Nahm, A. Spichiger, et. al.. Die SAMSTAG Methode
und ihre Rolle im Konformitätstesten, Praxis der Informationsverarbei-
tung und Kommunikation (PIK) Heft 4/94, Dezember 1994, S. 214-224
[Gut95] W. J. Gutjahr. Optimal Test Distributions for Software Failure Cost
Estimation, Department of Statistics, Operations Research and Com-
puter Science, Universität Wien, 1995
[Gut97] W. J. Gutjahr. Importance Sampling of Test Cases in Markovian Soft-
ware Usage Models, Department of Statistics, Operations Research and
Computer Science, Universität Wien, 1997
[Gut00] W. J. Gutjahr. Software Dependability Evaluation Based on Markov
Usage Model, Department of Statistics, Operations Research and Com-
puter Science, Universität Wien, 2000
[Har04] A. Hartman. AGEDIS – Final Project Report. http://www.agedis.de,
Februar 2004
[Har87] D. Harel. Statecharts: A Visual Formalism for Complex Systems, Sci-
ence of Computer Programming 8, 231-274. Elsevier. 1987
[HD03] A. Hartman, K. Dussa-Ziegler. TorX: Automated Model-Based Testing,
J. Tretmans, E. Brinksma Editors, First European Conference on Model-
Driven Software Engineering, Nürnberg, 2003
107

108
[HHR+05] Ø. Haugen, K. E. Husa, R. K. Runde et. al.. STAIRS towards formal
design with sequence diagrams, Software & System Modeling (So-
SyM), 2005
Literatur
[Hog91] D. Hogrefe. OSI Formal Specification Case Study: The INRES Protocol
and Service. Technical Report IAM-91-012, Universität Bern, Mai 1991
[Hol91] G. J. Holzmann. Design and Validation of Protocols. Prentice-Hall
Software Series, 990157918X, 1991
[IEC98] IEC 61508-4, Funktionale Sicherheit sicherheitsbezogener elektri-
scher/elektronischer/programmierbarer elektronischer Systeme - Teil 4:
Begriffe und Abkürzungen, 1998
[IEE90] IEEE. 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology, 1990
[ISO88] ISO. LOTOS – A formal description technique based on the temporal
ordering of observational behaviour, International Standard 8807, Sep-
tember 1988
[ISO89] ISO. Estelle – Formal Description Technique Based on an Extended
State Transition Model, International Standard 9074, 1989
[ISO92] ISO. ISO/IEC JTC 1/SC 21, Information Technology - Open Systems
Interconnection - Conformance Testing Methodology and Framework.
International Multipart Standard 9646, 1992
[ITU03] ITU-T, Draft Recommendation Z.152, Use Case Map Notation, Version
3.0, September 2003
[ITU96] ITU-T. Recommendation Z.120, Message Sequence Chart, 1996
[ITU99] ITU-T. Recommendation Z.100, Specification and Description Lan-
guage, November 1999
[Jec04] M. Jeckle. OMG’s XML Metadata Interchange Format XMI, In: Pro-
ceedings of the 1st Workshop of German Informatics Society e.V. (GI)
in conjunction with the 7th GI Conference “Modellierung 2004“, Mar-
burg, März 2004
[JJ02] C. Jard, T. Jéron. TGV: Theory, principles and algorithms, In: Proceed-
ings of the 6th World Conference on Integrated Design and Process
Technology (IDPT 2002), Juni 2002
[JRH+04] M. Jeckle, C. Rupp, J. Hahn et.al.. UML2 glasklar, Hanser Verlag,
München, 2004

Literatur
[Kel76] R. M. Keller. Formal verification of parallel programs, Communications
of the ACM, Vol. 19, Issue 7, Juli 1976
[Kol06] A. K. Kolla. Generation of a U2TP-compatible Test Suite from a UML
2.0 Markov Chain Usage Model, Master Thesis, Institut für Informatik
7, Universität Erlangen-Nürnberg, Mai 2006
[KT01] C. Kallepalli, J. Tian. “Measuring and Modeling Usage and Reliability
for Statistical Web Testing”, IEEE Transactions on Software Engineer-
ing, Vol. 27, No. 11, November 2001
[Li05] J. Li. Test Suite-Erzeugung aus UML2.0-Modellen, Diplomarbeit, Insti-
tut für Informatik 7, Universität Erlangen-Nürnberg, August 2005
[LK00] A. M. Law, W. D. Kelton. Simulation Modeling and Analysis, Third
Edition, McGraw-Hill Companies, 2000
[MK99] J. Magee, J. Kramer. Concurrency: State Models & Java Programs. John
Wiley & Sons, 1999
[MMN+92] K. W. Miller, L. J. Morell, R. E. Noonan et.al.. Estimating the Probabil-
ity of Failure When Testing Reveals No Failures, IEEE Transactions on
Software Engineering, Vol. 18, No. 1, Januar 1992
[MMN+92] K. W. Miller, L. J. Morrell, R. E. Noonan et.al.. Estimating the prob-
ability of failure when testing reveals no failures, IEEE Transactions on
Software Engineering, Vol. 18, No. 1, Januar 1992
[Mus93] J. D. Musa. Operational Profiles in Software-Reliability Engineering,
IEEE Software, März 1993
[Mus98] J. D. Musa. Software Reliability Engineering Testing, McGraw-Hill
Education, 1998
[Mye79] G. Myers. The Art of Software Testing, Wiley Verlag, 1979
[Neu04] H. W. Neukirchen. Languages, Tools and Patterns for the Specification
of Distributed Real-Time Tests. Dissertation, Universität Göttingen,
2004
[OMG03] Object Management Group. MDA Guide Version 1.0.1, omg/03-06-01,
Juni 2003
[OMG05a] Object Management Group. UML Testing Profile, version 1.0, for-
mal/05-07-07, Juli 2005
[OMG05b] Object Management Group. UML Profile for Schedulability, Perform-
ance and Time Specification, version 1.1, formal/05-01-02, Januar 2005
109

110
Literatur
[OMG05c] Object Management Group. XML Metadata Interchange (XMI) Specifi-
cation, version 2.0, formal/05-05-01, Mai 2005
[OMG05d] Object Management Group. MOF 2.0/XMI Mapping Specification,
version 2.1, formal/05-09-01, September 2005
[OMG05e] Object Management Group. UML Profile for Modeling and Analysis of
Real-Time and Embedded systems (MARTE), RfP, realtime/05-02-06,
Februar 2005
[OMG06a] Object Management Group. Unified Modeling Language: Superstruc-
ture, version 2.1, ptc/2006-04-02, April 2006
[OMG06b] Object Management Group. Meta Object Facility (MOF) Core Specifi-
cation, version 2.0, formal/06-01-01, Januar 2006
[OMG06c] Object Management Group. Unified Modeling Language: Infrastructure,
version 2.0, formal/05-07-05, März 2006
[OMG06d] Object Management Group. Diagram Interchange, version 1.0, for-
mal/06-04-04, April 2006
[OMG06e] Object Management Group. Object Constraint Language, version 2.0,
formal/06-05-01, Mai 2006
[OMG06f] Object Management Group. Unified Modeling Language: Infrastructure,
version 2.1, ptc/06-04-03, April 2006
[OMG07a] Object Management Group. Unified Modeling Language: Superstruc-
ture, version 2.1.1, formal/2007-02-05, Februar 2007
[OMG07b] Object Management Group. Unified Modeling Language: Infrastructure,
version 2.1.1, formal/07-02-06, Februar 2007
[OMG07c] Object Management Group. A UML Profile for MARTE, Beta 1,
ptc/07-08-04, August 2007
[PP05] A. Pretschner, J. Philipps. Methodological Issues in Model-Based Test-
ing, M. Broy et al. (Eds.): Model-Based Testing of Reactive Systems,
LNCS 3472, pp. 281-291. Springer-Verlag Berlin Heidelberg 2005
[Pro00] S. J. Prowell. TML: a description language for Markov chain usage
models, Information and Software Technology, 42 (2000)
[PTL+99] S. J. Prowell, C. J. Trammell, R. C. Linger et.al.. Cleanroom Software
Engineering – Technology and Process, Addison-Wesley, Februar 1999
[RJB04] J. Rumbaugh, I. Jacobson, G. Booch. The Unified Modeling Language
Reference Manual, Second Edition, Addison-Wesley, 2004

Literatur
[Say99] K. Sayre. “Improved Techniques for Software Testing Based on
Markov Chain Usage Models”, Dissertation, University of Tennessee,
Knoxville, Dezember 1999
[SD04] R. Schieber, F. Derichsweiler. Testautomatisierung in der Automobilin-
dustrie, SIGS-DATACOM, Objekt Spektrum April 2004,
[SEG00] M. Schmitt, M. Ebner, J. Grabowski. Test Generation with Autolink and
TestComposer. In: Proceedings of the 2nd Workshop of the SDL Forum
Society on SDL and MSC, Grenoble (France), 2000
[SG02] I. Schieferdecker, J. Grabowski. The Graphical Format of TTCN-3 in
the context of MSC and UML, Telecommunications and beyond: The
Broader Applicability of SDL and MSC (Editor: E. Sherratt). Proceed-
ings of the Third International Workshop on SDL and MSC (SAM
2002), Aberystwyth, UK, Juni 2002
[Shi05] J. Shi. Statistische Auswertung von Testergebnissen, Studienarbeit,
Institut für Informatik 7, Universität Erlangen-Nürnberg, Oktober 2005
[SL03] A. Spillner, T. Linz. Basiswissen Softwaretest, dpunkt Verlag Heidel-
berg, 2003
[SP00] K. Sayre, J. H. Poore. “Partition Testing With Usage Models”, Informa-
tion and Software Technology, Vol. 42, No. 12, 2000
[SSR97] I. Schieferdecker, B. Stepien, A. Rennoch. PerfTTCN, a TTCN lan-
guage extension for performance testing, 10th Intern. Workshop on
Testing of Communicating Systems, IWTCS`97, Cheju Island, Korea,
September 1997.
[Stu05] Roland Sturm, DHCI Spezifikation, Version 01.05, 2005, Fraunhofer
Institut für Integrierte Schaltungen, Abteilung Kommunikationssysteme
[Sus05] O. Sushanskyy. Statistische Testfallgenerierung aus UML2.0 Interakti-
onsdiagrammen, Diplomarbeit, Institut für Informatik 7, Universität Er-
langen-Nürnberg, Januar 2005
[TB02] J. Tretmans, E. Brinksma. Côte de Resyste – Automated Model Based
Testing, Progress 2002 – 3rd Workshop on Embedded Systems, Okto-
ber 2002
[Tre96] J. Tretmans. Test Generation with Inputs, Outputs and Repetitive Qui-
escence, Software – Concepts and Tools, 17(3):103-120, 1996
111

112
Literatur
[Vee06] E. v. Veenendaal. Standard glossary of terms used in Software Testing,
Version 1.2, Glossary Working Party, International Software Testing
Qualification Board, 4. Juni 2006
[VW98] F. I. Vokolos, E. J. Weyuker. Performance Testing of Software Sys-
tems. Workshop on Software and Performance (WOSP98), Santa Fe,
New Mexico, 1998
[W3C04a] World Wide Web Consortium. Extensible Markup Language (XML) 1.0
(Third Edition), W3C Recommendation 04 February 2004
[W3C04b] World Wide Web Consortium. XML Schema Part 0: Primer Second
Edition, W3C Recommendation 28 October 2004
[W3C99] World Wide Web Consortium. XSL Transformations (XSLT) Version
1.0, W3C Recommendation 16 November 1999
[Wey03] E. J. Weyuker. “Using Operational Distributions to Judge Testing Pro-
gress. In: Proceedings of the 2003 ACM symposium on Applied com-
puting, 2003
[WG99] T. Walter, J. Grabowski. A Framework for the Specification of Test
Cases for Real Time Distributed Systems. Information and Software
Technology, Vol. 41 (781-798), Juli 1999
[WP00] G. H. Walton, J.H. Poore. “Generating transition probabilities to support
model-based software testing”, Software-Practice and Experience, Vol.
30, 2000
[WP93] J. A. Whittaker, J. H. Poore. “Markov Analysis of Software Specifica-
tions”, ACM Transactions on Software Engineering and Methodology,
Vol. 2, No. 1, Januar 1993
[WPT95] G. H. Walton, J. H. Poore, C. J. Trammell. “Statistical Testing of Soft-
ware Based on a Usage Model”, Software-Practice and Experience, Vol.
25, No. 1, Januar 1995
[WT94] J. A. Whittaker, M. G. Thomason. “A Markov Chain Model for Statisti-
cal Software Testing”, IEEE Transactions on Software Engineering,
Vol. 20, No. 10, Oktober 1994
[WV00] E. J. Weyuker, F. I. Vokolos. Experience with Performance Testing of
Software Systems: Issues, an Approach and Case Study. IEEE Transac-
tions on Software Engineering, Vol. 26, No. 12, Dezember 2000

Literatur
[ZDS+05] J. Zander, Z. R. Dai, I. Schieferdecker, et.al.. From U2TP Models to
Executable Tests with TTCN-3 – An Approach to Model Driven Test-
ing, IFIP 17th Intern. Conf. on Testing Communicating Systems - Test-
Com 2005, Montreal, Canada, ISBN: 3-540-26054-4, Mai 2005
113