Dokument 1.pdf - Opus - Friedrich-Alexander-Universität Erlangen ...
Dokument 1.pdf - Opus - Friedrich-Alexander-Universität Erlangen ...
Dokument 1.pdf - Opus - Friedrich-Alexander-Universität Erlangen ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Q.E.D.<br />
-<br />
Ein Entwurfsprozess für statistische Tests<br />
mit Betrachtung von Zeit- und Leistungsanforderungen<br />
Der Technischen Fakultät der<br />
<strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg<br />
zur Erlangung des Grades<br />
DOKTOR-INGENIEUR<br />
vorgelegt von<br />
Dipl.-Inf. Matthias Beyer<br />
<strong>Erlangen</strong> – 2008
II<br />
Als Dissertation genehmigt von<br />
der Technischen Fakultät der<br />
<strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg<br />
Tag der Einreichung: 09. Mai 2008<br />
Tag der Promotion: 26. Juni 2008<br />
Dekan: Prof. Dr.-Ing. habil. J. Huber<br />
Berichterstatter: Prof. Dr.-Ing. R. German<br />
Prof. Dr.-Ing. D. Kips
Inhaltsverzeichnis<br />
1 Einleitung .................................................................................................................... 1<br />
1.1 Ziele der Arbeit.................................................................................................... 2<br />
1.2 Beiträge der Arbeit .............................................................................................. 2<br />
1.3 Aufbau der Arbeit................................................................................................ 3<br />
2 Softwaretest ................................................................................................................. 5<br />
2.1 Einführung........................................................................................................... 5<br />
2.2 Modellbasierter Test............................................................................................ 9<br />
2.2.1 Sichten ......................................................................................................... 9<br />
2.2.2 Szenarien ................................................................................................... 10<br />
2.2.3 Modellarten................................................................................................ 11<br />
2.2.4 Model Driven Architecture (MDA)........................................................... 14<br />
2.3 Testing and Test Control Notation 3 ................................................................. 16<br />
2.3.1 Historie ...................................................................................................... 16<br />
2.3.2 Der TTCN-3 Standard ............................................................................... 18<br />
2.3.3 Verteilter Test............................................................................................ 20<br />
2.3.4 Testkonfiguration ...................................................................................... 21<br />
2.3.5 TTCN-3 Module........................................................................................ 22<br />
2.3.6 TTCN-3 Verhalten..................................................................................... 23<br />
2.3.7 INRES-Beispiel ......................................................................................... 25<br />
2.3.8 TTCN Echtzeit- und Leistungserweiterungen........................................... 32<br />
3 Die Unified Modeling Language 2............................................................................ 35<br />
3.1 Historie .............................................................................................................. 35<br />
3.2 Metamodell........................................................................................................ 36<br />
3.3 Infrastructure ..................................................................................................... 38<br />
3.4 Superstructure.................................................................................................... 39<br />
3.4.1 Diagrammtypen ......................................................................................... 40<br />
3.5 XML Metadata Interchange (XMI) ................................................................... 42<br />
3.6 Sequenzdiagramme............................................................................................ 44<br />
3.7 UML Profile ...................................................................................................... 50<br />
3.7.1 UML Profile for Schedulability, Performance and Time.......................... 50<br />
3.7.2 UML Profile MARTE ............................................................................... 55<br />
3.7.3 UML Testing Profile ................................................................................. 57<br />
III
IV<br />
4 Q.E.D. – Testentwurfsprozess................................................................................... 59<br />
4.1 Szenarienbasierte Anforderungsspezifikation................................................... 61<br />
4.1.1 Use-Case-Diagramm ................................................................................. 61<br />
4.1.2 Leistungsanforderungen ............................................................................ 63<br />
4.2 Markov Chain Usage Model ............................................................................. 65<br />
4.2.1 Einführung................................................................................................. 65<br />
4.2.2 Eigenschaften ............................................................................................ 66<br />
4.2.3 Erstellung eines MCUMs .......................................................................... 69<br />
4.2.4 Software-Zuverlässigkeit........................................................................... 80<br />
4.3 Testfallgenerierung............................................................................................ 84<br />
4.4 Erzeugung der Testsuite .................................................................................... 87<br />
4.5 Zusammenfassung ............................................................................................. 91<br />
5 Anwendungsstudie DECT......................................................................................... 93<br />
6 Zusammenfassung ................................................................................................... 101<br />
6.1 Ausblick........................................................................................................... 102<br />
Abbildungsverzeichnis .................................................................................................... 103<br />
Literatur ........................................................................................................................... 105
Kurzfassung<br />
Software nimmt an Größe, Komplexität und Qualitätsanforderungen stetig zu. Diesen<br />
Herausforderungen stellt sich die moderne Softwareentwicklung u.a. mit verbesserten<br />
Programmierkonzepten, abstrakteren Programmiersprachen und systematischeren Entwicklungsprozessen.<br />
In diesem Zusammenhang ist die steigende Popularität der modellbasierten<br />
Softwareentwicklung zu verstehen, deren Stärken in einer meist visuellen abstrakten<br />
Notation und in erweiterten Validierungsmöglichkeiten liegen. In den letzten Jahren<br />
hat sich dieser Trend auf die Testphase ausgeweitet, um gleichermaßen systematisch<br />
und automatisch Testfälle aus Modellen generieren zu können. Die UML stellt als Sprachenfamilie<br />
den populärsten Vertreter aller Modellierungsnotationen dar.<br />
Ziel dieser Arbeit ist die Konzeption eines systematischen Testentwurfprozesses auf Basis<br />
einer Softwareentwicklung mit der UML2. Dieser soll verbreitete Sprachstandards verwenden<br />
und relevante Zeit- und Leistungsaspekte berücksichtigen. Aussagekräftige Testergebnisse<br />
sollen eine Entscheidung zur Systemfreigabe ermöglichen. Außerdem soll der<br />
gesamte Prozess praxisgerecht sein, also insbesondere niedrige Einsatzvoraussetzungen<br />
besitzen und leicht anzuwenden sein.<br />
In der vorliegenden Arbeit wird der Q.E.D. („QoS Enhanced test Development“) genannte<br />
Testentwurfsprozess vorgestellt. Dessen Ausgangslage stellen Anforderungsszenarien<br />
dar, die in der UML2 definiert sind. Außerdem können diese standardkonform Zeit- und<br />
Leistungsanforderungen beschreiben. Mittels einer - in dieser Arbeit diskutierten - Menge<br />
von Transformationsregeln wird ein Testmodell erzeugt. Dem Modell werden Benutzungsprofile<br />
hinzugefügt, um Testfälle statistisch nach angenommenem Nutzungsverhalten<br />
zu generieren. Eine Folge ist die Abschätzbarkeit der erreichten Softwarezuverlässigkeit<br />
aus Benutzersicht, einer geeigneten Größe zur Entscheidung der Systemfreigabe. Als<br />
Zielsprache für die Testausführung wurde die TTCN-3 gewählt, da sie eine verbreitete<br />
und die einzige standardisierte Testnotationssprache darstellt. Aufgrund der weitestgehenden<br />
Automatisierbarkeit ist der Testentwurfsprozess außerdem leicht anzuwenden.<br />
Im Rahmen dieser Arbeit wurden alle benötigten Teilschritte des Testentwurfsprozesses<br />
prototypisch implementiert. Die entstandene Werkzeugkette konnte an einer realen Fallstudie<br />
erprobt werden. Dazu stellte die Projektgruppe CCIOS des Fraunhofer Instituts für<br />
Integrierte Schaltungen sechs DECT-Funkmodule M5 aus eigener Entwicklung zur Verfügung.<br />
Damit konnte die praktische Einsatzfähigkeit des Q.E.D.-Ansatzes gezeigt werden.<br />
V
Abstract<br />
Software is continuously increasing in size, complexity and quality demands. Modern<br />
software engineering faces up to these challenges amongst others with improved programming<br />
concepts, programming languages with higher degrees of abstraction and more<br />
systematic development processes. In this context, the growing popularity of model based<br />
software engineering is reasonable, which has its strengths in mostly graphical and abstract<br />
notations and in extended validation possibilities. In the last years this tendency<br />
dilated to the testing phase, to generate test cases both systematically and automatically<br />
from models. The UML, as a family of languages, is the most popular representative of<br />
all modelling notations.<br />
The aim of this thesis is the conceptual design of a systematic test development process<br />
based on a software design with the UML2. It should apply common language standards<br />
and account for relevant time and performance aspects. Significant test results should<br />
facilitate the decision to release software. Furthermore the whole process ought to be<br />
practice-oriented, in particular with low prerequisites and easy appliance.<br />
This thesis introduces a test development process called Q.E.D. (“QoS Enhanced test<br />
Development”). It starts with requirements defined as scenarios in the UML2. Moreover<br />
they may include standard conforming time and performance requirements. By applying a<br />
set of transformation rules - as discussed in this thesis - a test model can be created. User<br />
profiles are added to the model to generate test cases statistically to the expected software<br />
usage. A consequence is the ability to estimate the achieved software reliability from the<br />
user perspective, an appropriate measurement for the decision towards a software release.<br />
TTCN-3 is chosen as the target language for test execution, both because of its popularity<br />
and because it’s the only standardized test notation language. Due to the possible high<br />
degree of automation the whole test development process is easily applicable.<br />
For this thesis all necessary partial steps of the test development process were prototypically<br />
implemented. The emerged tool chain could be validated by appliance within a real<br />
case study. Therein six wireless DECT modules M5, developed and provided by the project<br />
group CCIOS from the Fraunhofer Institute for Integrated Circuits, could be used as<br />
the system under test. The realized case study demonstrates the practical applicability of<br />
the Q.E.D. approach.<br />
VII
VIII<br />
Einleitung
1 Einleitung<br />
Die wachsende Technisierung weiter Lebensbereiche und der allgemeine technische Fortschritt<br />
erzeugen eine stetig wachsende Anzahl an immer größeren technischen Systemen.<br />
Die mit ihr einhergehende steigende Komplexität dieser Systeme erhöht den Bedarf an<br />
systematischen Vorgehensweisen für jede Phase des Entwurfsprozesses.<br />
Vor diesem Hintergrund halten seit Jahren Modellierungssprachen und modellgestützte<br />
Techniken in der Softwareentwicklung Einzug. Visuelle Modelle behalten auch bei höherer<br />
Komplexität ihre Verständlichkeit, formale Modelle bieten zudem automatische Analyse-<br />
und Validierungsmöglichkeiten. Fortgeschrittene Techniken ermöglichen werkzeuggestützt<br />
die automatisierte Generierung von Implementierungscode. Die Modellierungssprachen<br />
SDL [ITU99] und MSC [ITU96] wurden aus diesen Gründen in den vergangenen<br />
drei Jahrzehnten sehr erfolgreich im Bereich der Telekommunikation eingesetzt.<br />
Mitte der 90er Jahre trat die UML [OMG07a] ihren Siegeszug als allgemeine Modellierungsnotation<br />
in der Softwareentwicklung an. Ihre in der Sprachenarchitektur verankerte<br />
Erweiterbarkeit ließ die Anwendungsbereiche und die Zahl der Anwender stetig wachsen.<br />
Seit Verabschiedung der neuesten UML-Version, in der alle wichtigen Konzepte der SDL<br />
und MSC übernommen wurden, nimmt auch die Telekommunikationsbranche die Sprache<br />
besser an. Zudem lässt sich die UML auf Grund ihrer Diagrammvielfalt in allen Phasen<br />
der Softwareentwicklung einsetzen.<br />
Eine der zeitaufwändigsten Phasen dabei ist das Testen, die damit verbundenen Aktivitäten<br />
nehmen in der Praxis bis zu 40 Prozent der gesamten Softwareentwicklung in Anspruch.<br />
Die Anwendung moderner Methodiken und formaler Verifikationstechniken können<br />
diesen Aufwand reduzieren, überflüssig wird das Testen jedoch nicht. Die bei der<br />
Verifikation notwendigerweise getroffenen Annahmen über das reale System bzw. die<br />
Umgebung müssen auf ihre Korrektheit hin überprüft, d.h. getestet werden.<br />
Ein oft vernachlässigter Aspekt sowohl beim Entwurf wie auch beim Testen sind Zeit-<br />
und Leistungsanforderungen, die häufig im gleichen Maße für die Kundenakzeptanz verantwortlich<br />
sind. Dies betrifft sowohl das Einhalten einfacher zeitlicher Schranken als<br />
auch von Größen pro Zeiteinheit.<br />
1
2<br />
1.1 Ziele der Arbeit<br />
Einleitung<br />
Zwischen den Vorgehensweisen bei der Systementwicklung in der akademischen und der<br />
industriellen Welt existiert eine Diskrepanz, welche nur schwer aufzulösen ist. Auf der<br />
einen Seite werden formale Sprachen und Techniken entwickelt, die mitunter beweisbare<br />
Korrektheit ermöglichen. Auf der anderen Seite dominieren informelle Sprachen und<br />
Implementierungscode, dessen einzige Überprüfung durch Debugging und (mehr oder<br />
weniger) unsystematisches Testen erfolgt. Die erreichte Akzeptanz der (semi-formellen)<br />
UML im industriellen Umfeld stellt eine Chance dar, beide Welten einander näher zu<br />
bringen.<br />
Das Ziel dieser Arbeit ist es, auf Basis eines Entwurfsprozesses in der UML2 einen verbesserten,<br />
d.h. systematischen Testprozess zu entwickeln. Dabei sind nachfolgende Bedingungen<br />
zu erfüllen: (1) Der Prozess soll existierende und verbreitete Sprachstandards<br />
verwenden. (2) Die Testergebnisse sollen die Entscheidung zur Systemfreigabe erleichtern.<br />
(3) Die Tests sollen relevante Zeit- und Leistungsaspekte berücksichtigen. (4) Der<br />
gesamte Prozess soll praxisgerecht sein, d.h. insbesondere niedrige Einsatzvoraussetzungen<br />
besitzen und leicht anzuwenden sein.<br />
1.2 Beiträge der Arbeit<br />
Diese Arbeit setzt auf Vorarbeiten des europäischen IST Projekts „Markov Test Logic“<br />
(MaTeLo) auf, welches sich mit dem Einsatz von markowkettenbasierten Testmodellen<br />
beschäftigt hat. So wird in [BD03, BD04, DZ03] ein ähnlicher Ansatz wie in dieser Arbeit<br />
beschrieben.<br />
Im Unterschied zum Q.E.D.-Entwurfsprozess war die betrachtete Notationssprache jedoch<br />
eine andere, „Message Sequence Charts“ (MSC) anstelle der UML. Musste für die<br />
Repräsentation des Testmodells eine neue, proprietäre Beschreibungssprache entwickelt<br />
werden, wird in dieser Arbeit konsequent – von der Anforderungsspezifikation bis hin zur<br />
Testsuite – die UML genutzt. Lediglich für die Testausführung muss diese Sprache insbesondere<br />
aufgrund fehlender Werkzeugunterstützung verlassen werden. Der Prämisse zur<br />
Verwendung existierender Standards folgend, erfolgt hier die Abbildung auf die „Testing<br />
and Control Notation version 3“ (TTCN-3).<br />
In Erweiterung zu „MaTeLo“ wird zudem der gesamte Sprachumfang der Sequenzdiagramme<br />
betrachtet. Alle – laut Spezifikation erlaubten – Elemente werden für eine mögliche<br />
Abbildung auf das Testmodell diskutiert, insbesondere auch komplexere Szenarien,<br />
die durch Kombination einfacher Sequenzen entstehen können. Außerdem wird für ver-
Aufbau der Arbeit<br />
schiedene Zeit- und Leistungsanforderungen aufgezeigt, wie sich diese von der Anforderungsdefinition<br />
über das Testmodell auf eine Erweiterung der TTCN-3 abbilden lassen.<br />
Bei der Testfallgenerierung wird sowohl auf die Sonderfälle von nichtdeterministischem<br />
und parallelem Verhalten, als auch auf die Notwendigkeit der Synchronisierung verschiedener<br />
Testkomponenten eingegangen.<br />
1.3 Aufbau der Arbeit<br />
Diese Arbeit gliedert sich in sechs Kapitel. Nach der Einleitung führt Kapitel 2 in das<br />
Thema des Softwaretests ein, wobei die zwei Schwerpunkte bei den modellbasierten Verfahren<br />
und der Testsprache „Testing and Test Control Notation version 3“ (TTCN-3)<br />
liegen. Letztere stellt die Zielsprache im Q.E.D.-Testentwurfsprozess dar. Neben einer<br />
Beschreibung der in ihr enthaltenen Konzepte und deren Erläuterung anhand eines kleinen<br />
Beispiels schließt das Kapitel mit existierenden Spracherweiterungen ab.<br />
Das Kapitel 3 widmet sich dem Thema der „Unified Modeling Language version 2“<br />
(UML2), einer Modellierungssprache, die die Grundlage des Q.E.D.-Prozesses bildet.<br />
Neben unterschiedlichen Aspekten dieser Sprache werden zum Abschluss des Kapitels<br />
ebenfalls verschiedene Spracherweiterungen (sog. Profile) beleuchtet, die für diese Arbeit<br />
von Bedeutung sind.<br />
Im anschließenden Kapitel 4 wird der entwickelte Q.E.D.-Entwurfsprozess beschrieben.<br />
Den Ausgangspunkt des Prozesses stellen szenarienbasierte Anforderungsdefinitionen<br />
dar, folglich startet das Kapitel mit deren Erläuterung. Aus ihnen wird ein Testmodell<br />
erstellt, das sog. „Markov Chain Usage Model“ (MCUM). Es stellt die zentrale Struktur<br />
im Entwurfsprozess dar, neben einer Beschreibung der Eigenschaften und Vorteile gibt<br />
das Kapitel eine Abbildungsvorschrift für dessen Erstellung aus der Anforderungsspezifikation<br />
wieder. Abschließend werden verschiedene Aspekte beleuchtet, die bei der Testfallgenerierung<br />
aus dem MCUM und der Erzeugung einer Testsuite in der TTCN-3 zu<br />
beachten sind.<br />
Kapitel 5 enthält eine Anwendungsstudie mit Modulen für drahtlose Sprach- und Datenübertragung<br />
(DECT). Der gesamte Entwurfsprozess wurde in Form einer Werkzeugkette<br />
realisiert, welche in der Studie exemplarisch angewendet werden konnte. Damit konnte<br />
die Anwendbarkeit von Q.E.D. auf reale Systeme demonstriert werden. Kapitel 6 fasst die<br />
Ergebnisse der Arbeit noch einmal zusammen, den Abschluss bilden die Verzeichnisse<br />
der in der Arbeit enthaltenen Abbildungen und der referenzierten Literatur.<br />
3
4<br />
Einleitung
2 Softwaretest<br />
Das folgende Kapitel beschreibt den Softwaretest und die Konzepte der Testsprache<br />
TTCN-3. Die Einführung ordnet das Testen in den Softwareentwurf ein, beschreibt dessen<br />
Klassifizierung und erklärt die häufigsten Testarten. Im Anschluss werden modellbasierte<br />
Testansätze vorgestellt, als Grundlage für den – im Kapitel 4 vorgestellten – Testentwurfsprozess.<br />
Den Abschluss des Kapitels bildet eine Beschreibung der Testnotation<br />
TTCN-3, der Zielsprache des entwickelten Q.E.D.-Ansatzes.<br />
2.1 Einführung<br />
Der Entwurf von Software gliedert sich in verschiedene Phasen. Er beginnt in der Regel<br />
mit der Definition der Anforderungen und endet vor der Softwarefreigabe mit einer Testphase.<br />
Dazwischen lassen sich je nach Detaillierungsgrad mehrere Entwurfs-, Spezifikations-,<br />
Programmier- und Testphasen identifizieren. Ein Entwicklungsprozess regelt ihre<br />
genaue Abfolge, Phasen können in Iterationen mehrmals durchlaufen, andere vernachlässigt<br />
oder übersprungen werden.<br />
Die Abbildung 1 stellt exemplarisch das V-Modell dar, ein Vorgehensmodell für die<br />
Softwareentwicklung aus der Mitte der 80er Jahre. Trotz seines Alters und der Veröffentlichung<br />
neuerer und moderner Methoden verdeutlicht es sehr gut das Vorhandensein unterschiedlicher<br />
Testphasen und deren Testfallgrundlagen. Wie die Bezeichnungen schon<br />
andeuten, werden beim Modultest einzelne Softwaremodule und beim Systemtest das<br />
gesamte System geprüft. Von Ersterem bilden die detaillierten Entwurfsdokumente und<br />
Modulspezifikationen die Grundlage der Testfälle, von Letzterem sind es die Anforderungsdefinitionen<br />
und Grobentwürfe. Der Integrationstest zielt auf die Schnittstellen bei<br />
der Interaktion verschiedener Komponenten, der Abnahmetest ist ein Systemtest aus Sicht<br />
des Kunden und findet in dessen Systemumgebung statt.<br />
Der Begriff des Softwaretests wird in der Literatur unterschiedlich weit gefasst. G. J.<br />
Myers definierte Ende der 70er Jahre [Mye79] Testen als „Prozess, ein Programm mit der<br />
Absicht auszuführen, Fehler zu finden“. Eine aktuelle Definition geben Spillner et.al. in<br />
[SL03] mit einem Testobjekt, welches zur Überprüfung stichprobenartig ausgeführt wird.<br />
Das Testobjekt ist hierbei unbestimmt und kann von einer einfachen Funktion bis zu einem<br />
vollständigen verteilten System jegliche Komplexität besitzen.<br />
5
6<br />
Anforderungsdefinition<br />
Grobentwurf<br />
Feinentwurf<br />
Modulspezifikation<br />
Testfälle<br />
Testfälle<br />
Testfälle<br />
Testfälle<br />
Testfälle<br />
Testfälle<br />
Testfälle<br />
Programmierung<br />
Modultest<br />
Integrationstest<br />
Abbildung 1 V-Modell, nach [Bal98]<br />
Systemtest<br />
Abnahmetest<br />
Softwaretest<br />
Andere Definitionen beschreiben den Testbegriff umfassender und schließen Analyse-<br />
und Reviewtechniken mit ein, die als statische Testverfahren klassifiziert werden, da das<br />
Testobjekt nicht zur Ausführung gebracht wird. Balzert beschreibt in [Bal98] Testen als<br />
„[…] jegliches Mittel mit dem Ziel, Fehler in einem Programm zu finden“.<br />
Auch die letztgenannte Definition umfasst nicht die Klasse der statistischen Testverfahren.<br />
Nach [Vee06] stellen diese ein Testentwurfsverfahren dar, „in dem das Modell der<br />
statistischen Verteilung der Eingaben verwendet wird, um repräsentative Tests zu konstruieren.“<br />
Musa benennt in [Mus98] den „anwendungsprofilorientierten Test“ und beschreibt<br />
ihn als „statistischen Test unter Verwendung eines Modells von Systemoperationen<br />
und ihrer typischen Nutzung“.<br />
Bei statistischen Testverfahren werden die Testfälle demnach nicht mit dem Augenmerk<br />
erstellt, möglichst viele Fehler aufzudecken und damit die Systemqualität zu erhöhen.<br />
Vielmehr werden durch die Verwendung der statistischen Eingabeverteilung Testfälle<br />
erzeugt, um die erreichte Systemqualität abzuschätzen.<br />
Die Begriffsdefinition des Softwaretests, der sich diese Arbeit anschließt, findet sich in<br />
[Vee06] wieder:<br />
Definition: „Testen ist der Prozess, bestehend aus allen Aktivitäten des Lebenszyklus, der<br />
sich, sowohl statisch als auch dynamisch, mit der Planung, Vorbereitung und Bewertung
Einführung<br />
eines Softwareprodukts und damit verbundener Arbeitsergebnisse befasst, um sicherzustellen,<br />
dass sie die festgelegten Anforderungen erfüllen, um zu zeigen, dass sie ihren<br />
Zweck erfüllen, und um Fehler zu finden.“ [Vee06]<br />
Qualitätssichernde Prüfmaßnahmen werden meist als Verfahren der Verifikation oder der<br />
Validierung klassifiziert. Eine strenge Zuordnung des Testens ist allerdings nicht möglich.<br />
Nach [IEE90] versteht man unter der Validierung den Prozess der Beurteilung eines<br />
Systems oder einer Komponente während oder am Ende des Entwicklungsprozesses, mit<br />
dem Ziel, festzustellen, ob die spezifizierten Anforderungen erfüllt sind. Betrachtet werden<br />
Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische<br />
beabsichtigte Anwendung. Es wird also geprüft, ob das richtige System realisiert wurde.<br />
Unter einer Verifikation versteht man zwei Dinge [IEE90]. Zum einen ist sie der Prozess<br />
der Beurteilung eines Systems oder einer Komponente mit dem Ziel, festzustellen, ob die<br />
Resultate einer gegebenen Entwicklungsphase den Vorgaben für diese Phase entsprechen.<br />
Demnach wird geprüft, ob das System richtig realisiert wurde. Zum anderen ist sie der<br />
formale Beweis der Korrektheit des Systems. Letzteres wird auch formale Verifikation<br />
genannt.<br />
Der Großteil der Testaktivitäten findet zur Konformitätsüberprüfung statt, d.h. es wird<br />
bestimmt, ob ein System die vorher festgelegten Forderungen erfüllt. Testen wird daher<br />
im Allgemeinen der Verifikation zugeordnet. Werden die Testfälle jedoch hinsichtlich<br />
Benutzeranforderungen mit dem Blick auf gewünschte Anwendungsfälle erstellt, findet<br />
eine Validierung statt.<br />
Folgende zwei charakteristische Eigenschaften besitzen alle Testverfahren: (1) Ein Test<br />
entspricht immer einem Stichprobenexperiment, d.h. die Eingabedomäne ist in der Regel<br />
auch bei kleinen Systemen zu groß, um sie vollständig zu testen. (2) Es existiert immer<br />
ein Testorakel, welches beobachtete Ereignisse der Testdurchläufe auf ihre Korrektheit<br />
überprüft. Ohne diese Aussagemöglichkeit wäre der Test sinnlos. Dabei ist es unerheblich,<br />
woher das Orakel die Korrektheitsinformation erhält und wann die Überprüfung<br />
stattfindet.<br />
Testarten<br />
Zur Kategorisierung der Testverfahren existieren verschiedene Dimensionen bzw. Unterscheidungsmerkmale,<br />
die jeweils mehrere disjunkte Testklassen bilden. Die am häufigsten<br />
verwendeten Kriterien werden im Folgenden vorgestellt:<br />
7
8<br />
Softwaretest<br />
Eine Dimension stellt der Ursprung der Korrektheitsinformation für die Testfälle dar. Sie<br />
klassifiziert Verfahren in „black-box“ bzw. funktionale und „white-box“ bzw. strukturelle<br />
Tests. Bei der erstgenannten Gruppe werden Testfälle auf Grundlage der vorliegenden<br />
Systemspezifikation, bei der zweiten auf Grundlage der Implementierung gewonnen.<br />
Mischformen gehören der „grey-box“-Klasse an.<br />
Beschränken sich die getesteten Anforderungen nicht nur auf das rein funktionale Verhalten,<br />
so wird von nicht-funktionalen Tests gesprochen. Die Fragestellung des Testers lautet<br />
nicht „Funktioniert es?“ sondern „Funktioniert es gut genug?“. Je nach betrachtetem Aspekt<br />
lassen sich eine Vielzahl von Unterklassen benennen. Hier sind insbesondere Zeit-<br />
und Leistungsfragen von Belang, die mit Leistungs-, Last- und Stresstests eine hohe Bedeutung<br />
haben. Sicherheits- und Robustheitstests prüfen auf Sicherheitslücken bzw. auf<br />
Negativfälle.<br />
Entsprechend der zu testenden Einheit existieren unterschiedliche Testlevel. Beim Komponententest<br />
werden einzelne Module bzw. Komponenten getestet. Der Integrationstest<br />
prüft die Modulschnittstellen und das Zusammenspiel integrierter Module. Das gesamte<br />
System ist im Fokus des Systemtests.<br />
Eine weitere Dimension ist die Lokalität des Testsystems, die zwei weitere Klassen bildet.<br />
Läuft es auf einem einzelnen Knoten, so findet ein lokaler, ansonsten ein verteilter<br />
Test statt. Wird das zu testende System während des Tests ausgeführt, spricht man von<br />
einem dynamischen Test, sonst von einem statischen Test. Die primäre Zielsetzung des<br />
Tests kann das Auffinden von Fehlern sein (Fehlertest) oder die Abschätzung der Qualität<br />
(statistischer oder Qualitätstest).<br />
Neben vielen weiteren Unterscheidungsmerkmalen existiert eine Testklasse, die in den<br />
letzten Jahren an Bedeutung gewonnen hat. Mit dem Begriff des modellbasierten Tests<br />
wird zum Ausdruck gebracht, dass ein Modell die Grundlage der Testfallgenerierung<br />
bildet. Das anschließende Kapitel gibt einen Überblick über existierende und laufende<br />
Arbeiten in diesem Umfeld.<br />
Zur Beschreibung eines Testverfahrens werden relevante Dimensionen ausgewählt und<br />
die zutreffenden Testklassen genannt. Der in dieser Arbeit vorgestellte Testentwurfsprozess<br />
ließe sich mit den hier vorgestellten Dimensionen als ein statistisches, dynamisches,<br />
modellbasiertes, nicht-funktionales, black-box Systemtestverfahren bezeichnen.
Modellbasierter Test<br />
2.2 Modellbasierter Test<br />
Beim Systementwurf erfahren modellgestützte Ansätze seit vielen Jahren wachsende Bedeutung,<br />
insbesondere ihre visuelle Notation und erweiterte Analyse- und Validierungsmöglichkeiten<br />
sind dafür verantwortlich.<br />
Eine Testsuite ist ein Stück Software, bei ihrer Erstellung treten demnach die gleichen<br />
Herausforderungen und Fehlerquellen auf, wie sie bei jedem Softwareentwurf zu Tage<br />
treten. Um gleichermaßen von den Vorteilen modellgestützter Herangehensweisen zu<br />
profitieren, halten diese auch in der Testphase Einzug.<br />
In modellbasierten Testverfahren werden Testfälle auf Basis eines Testmodells erstellt.<br />
Der Begriff „Testmodell“ impliziert jedoch kein dediziertes Modell für das Testen, er<br />
beschreibt nur den (möglicherweise zusätzlichen) Verwendungszweck.<br />
Die grundsätzliche Vorgehensweise beim modellbasierten Testen ist die folgende: Ein<br />
Modell des zu testenden Systems, des sog. „SUT“ (System Under Test), wird erstellt, um<br />
anschließend daraus Testfälle zu generieren. Das SUT wird mit Eingabesignalen bzw.<br />
-nachrichten stimuliert, um anschließend die Ausgaben des SUT mit denen des Modells<br />
zu vergleichen. Dies impliziert die Forderung eines gültigen und korrekten Modells, d.h.<br />
es muss die tatsächlichen Anforderungen an das System widerspiegeln.<br />
Da ein Modell immer eine Abstraktion eines realen Systems ist, bei dem – für den Anwendungszweck<br />
– unwichtige Aspekte weggelassen wurden, bleibt der Vergleich zwischen<br />
Modell und SUT stets unvollständig. Für die Erstellung der Testfälle aus dem Modell<br />
werden meist strukturelle Kriterien definiert, d.h. von den Testfällen wird ein bestimmter<br />
Grad an Modellüberdeckung gefordert. Alternativ können ausgewählte „interessante“<br />
Testfälle erzeugt werden.<br />
Im Folgenden werden verschiedene Aspekte im Zusammenhang mit Testmodellen betrachtet.<br />
2.2.1 Sichten<br />
Testmodelle unterscheiden sich in ihrer Systemsicht und in ihren Abstraktionsniveaus.<br />
Ein Testmodell kann die Sicht eines Systemmodells oder eines Benutzungsmodells besitzen.<br />
Ersteres beschreibt die Systemdynamik, bestehend aus dem internen Verhalten und<br />
der Schnittstellenkommunikation. Das Systemmodell beschreibt also, wie ein System sein<br />
Verhalten realisiert. Das Benutzungsmodell besitzt eine externe Sicht auf das System, es<br />
beschreibt ausschließlich das Kommunikationsverhalten mit der Umwelt, interne System-<br />
9
10<br />
Softwaretest<br />
abläufe sind nicht enthalten. Das Modell enthält also lediglich Informationen darüber, was<br />
in Reaktion auf Benutzungseingaben vor sich geht, nicht wie es realisiert wird.<br />
2.2.2 Szenarien<br />
Innerhalb des Entwurfsprozesses eines Systems können Testmodelle auf unterschiedliche<br />
Weise eingesetzt werden, in [PP05] sind hierzu vier Szenarien beschrieben.<br />
autom.<br />
Erzeugen<br />
Testfälle<br />
Anforderungsdefinition<br />
autom.<br />
Erzeugen<br />
Testfälle<br />
Anforderungsdefinition Anforderungsdefinition<br />
Spezifikation<br />
Modell<br />
manuelles<br />
Überprüfen<br />
Testmodell<br />
autom.<br />
Überprüfen<br />
autom.<br />
Erzeugen<br />
Code<br />
Spezifikation<br />
Code<br />
manuelle<br />
Codierung<br />
autom.<br />
Erzeugen<br />
Testfälle<br />
Anforderungsdefinition<br />
autom.<br />
Erzeugen<br />
Testfälle<br />
Testmodell<br />
manuelles<br />
Überprüfen<br />
Testmodell<br />
autom.<br />
Überprüfen<br />
Abbildung 2 Modellbasiertes Testen – Szenarien, nach [PP05]<br />
autom.<br />
Erzeugen<br />
Code<br />
Implement.modell<br />
Code<br />
manuelle<br />
manuelle<br />
Codierung<br />
oder autom.<br />
Codierung<br />
Eine Möglichkeit ist die Erstellung eines gemeinsamen Modells aus der Anforderungsspezifikation<br />
für die Code- und Testfallgenerierung (Abbildung 2, l.o.). Der Vorteil ist die<br />
Erstellung und Pflege eines einzigen Modells. Nachteil ist jedoch die fehlende Redundanz,<br />
die für das Testen nötig ist, d.h. die unabhängige Erstellung des aktuellen Verhaltens<br />
(in dem SUT) und des gewünschten Verhaltens (in den Testfällen). Damit sind in<br />
diesem Szenario lediglich zwei Dinge testbar: der Code-Generator und getroffene Annahmen<br />
über die Umgebung.<br />
Im zweiten Szenario wird das SUT manuell implementiert und das Testmodell aus dem<br />
Systemcode extrahiert (Abbildung 2, r.o.). Automatisch generierte Testfälle aus diesem<br />
Modell besitzen jedoch den gleichen Nachteil wie im vorherigen Szenario: ihnen fehlt die<br />
Redundanz.
Modellbasierter Test<br />
Eine weitere Möglichkeit ist neben der manuellen Implementierung des SUT die manuelle<br />
Erstellung des Testmodells aus der Anforderungsspezifikation (Abbildung 2, l.u.).<br />
Durch die dabei entstehende Redundanz ist eine Testausführung mit automatischer Vergabe<br />
von Testurteilen möglich.<br />
Das letzte Szenario ist die Erstellung zweier verschiedener Modelle, eines Implementierungs-<br />
und eines Testmodells (Abbildung 2, r.u.). Aus ersterem lässt sich Systemcode, aus<br />
letzterem lassen sich Testfälle generieren. Durch das Vorhandensein zweier Modelle ist<br />
die nötige Redundanz für das Testen gegeben.<br />
2.2.3 Modellarten<br />
Testmodelle werden insbesondere durch Transitionssysteme dargestellt. Die zwei wichtigsten<br />
Vertreter sind die beschrifteten Transitionssysteme („labelled transition system“<br />
(LTS)) und die endlichen Automaten („finite state machine“ (FSM)).<br />
Beschriftete Transitionssysteme (LTS)<br />
Beschriftete Transitionssysteme [Kel76] sind eine verbreitete Notation zur Beschreibung<br />
von datenintensiven Systemen und von Hardwareschaltungen. Sie beschreiben in einem<br />
zustandsbasierten System alle möglichen Zustände und Zustandsübergänge (Transitionen).<br />
Formal ist ein LTS definiert durch ein Quadrupel (S, A, T, S0), mit der Zustandsmenge S,<br />
dem Alphabet („labels“) A mit S∩A = ∅, der Transitionsrelation T ⊆ S×A×S und der<br />
nichtleeren Menge an Startzuständen S0 ⊆ S. Im Gegensatz zu den endlichen Automaten<br />
müssen in einem LTS die Zustandsmenge S, das Alphabet A und somit auch T nicht endlich<br />
sein.<br />
Die folgenden Arbeiten setzen das Vorhandensein eines präzisen und eindeutigen LTS-<br />
Modells eines realen Systems voraus. Das bedeutet, dass Zustände und Transitionen im<br />
LTS eindeutig entsprechenden Zuständen und Übergängen im SUT zuzuordnen sind.<br />
Daraus folgt, dass die aus dem Modell erzeugten Testfälle das SUT genau auf die gewünschte<br />
Eigenschaft hin, und nur auf diese Eigenschaft überprüfen. Diese Testfälle<br />
nennt man beweisbar gültig („valid“).<br />
Die wichtigste Theorie im Bereich der LTS-basierten Testmodelle ist die ioco-Theorie<br />
[Tre96], welche nach der ioco-Implementierungsrelation („input output conformance<br />
relation“) benannt ist. Die Relation ist ein abstraktes Konzept und beschreibt formal die<br />
11
12<br />
Softwaretest<br />
Umstände einer korrekten Implementierung. Hierfür wird angenommen, dass für jedes zu<br />
testende System ein eindeutiges korrektes Modell existiert, d.h. dass die zu testenden Systeme<br />
formal behandelt werden können.<br />
Die Konformität zwischen Spezifikation und Implementierung wird formal als Konformitätsrelation<br />
zwischen zwei Modellen definiert, dem Modell der Spezifikation und dem der<br />
Implementierung. Formal ist die ioco-Implementierungsrelation folgendermaßen definiert:<br />
i ioco s =def ∀σ ∈ Straces(s) : out(i after σ) ⊆ out(s after σ)<br />
Straces(p) : Mögliche Spurenmenge im LTS p<br />
p after σ : Erreichbare Zustandsmenge nach Ausführung der Spur σ im LTS p<br />
out(P) : Ausgabenmenge der möglichen Transitionen für die Zustandsmenge P<br />
Informal bedeutet dies, dass eine Implementierung i ioco-korrekt zu einer Spezifikation s<br />
ist, wenn nach allen möglichen Verhalten der Spezifikation jede Ausgabe der Implementierung<br />
eine mögliche Ausgabe der Spezifikation ist. Dies soll auch für die spezielle Ausgabe<br />
„quiescence“ gelten, die für die leere (keine) Ausgabe steht.<br />
Testgenerierungsalgorithmen zur Überprüfung der ioco-Korrektheit erzeugen eine Test-<br />
Suite mit folgenden zwei Eigenschaften: Ist das SUT korrekt implementiert, so wird kein<br />
Testfall erzeugt, der zu dem Testurteil „fail“ führt (ein fehlerfreies Modell wird vorausgesetzt).<br />
Eine Testsuite mit dieser Eigenschaft nennt sich sound. Ist das SUT fehlerhaft implementiert,<br />
so kann ein Testfall generiert werden, der einen Fehler aufzeigt. Dies ist die<br />
completeness oder Vollständigkeitseigenschaft der Testsuite.<br />
Den Testgeneratoren vieler Werkzeuge liegt die „ioco“-Theorie zugrunde. Zu den wichtigsten<br />
gehören das „Côte de Resyste“-Projekt mit dem Tool TorX [HD03], das TGV-<br />
Tool von IRISA / Verimag 1 [JJ02] und das AGEDIS-Projekt mit dem gleichnamigen<br />
Werkzeug [Har04].<br />
Das „Côte de Resyste“-Projekt [TB02] begann 1998 mit dem Ziel, die formale ioco-<br />
Testtheorie in einem Werkzeug umzusetzen und ihre Anwendbarkeit anhand mehrerer<br />
akademischer und industrieller Studien zu demonstrieren. Das „TorX“ getaufte Tool unterstützt<br />
die automatische Testgenerierung, -ausführung und -analyse in einem „on-the-<br />
1 http://www-verimag.imag.fr/
Modellbasierter Test<br />
fly“-Modus. Dies bedeutet, dass jeder erzeugte Testschritt sofort ausgeführt wird und<br />
entsprechend der erhaltenen Antwort der nächste Testschritt gewählt wird. Unterstützte<br />
Eingabesprachen zur Beschreibung des beschrifteten Transitionssystems sind LOTOS<br />
[ISO88], PROMELA [Hol91], SDL [ITU99] und LTSA [MK99].<br />
„TGV“, entwickelt von IRISA und Verimag [JJ02], ist ein Tool für Konformitätstests und<br />
basiert ebenso auf der ioco-Implementierungsrelation. Bis auf eine zusätzliche Betrachtung<br />
von Livelocks entspricht die Testtheorie der von TorX. TGV unterstützt mehrere<br />
Eingabesprachen, darunter LOTOS [ISO88], SDL [ITU99], UML und IF [BFG+99], einem<br />
von Verimag entwickelten Beschreibungsformat.<br />
Das AGEDIS-Projekt [Har04] bestand zwischen den Jahren 2000 und 2003 aus sieben<br />
akademischen und industriellen Partnern. Ziel war die Entwicklung von Methoden und<br />
Tools zum automatischen Softwaretest. Einzige Eingabesprache ist die AML (AGEDIS<br />
Modeling Language), ein Profil der UML 1.4. Das UML-Modell wird in die Zwischennotation<br />
IF [BFG+99] übersetzt, aus der Testfälle generiert werden. Der Algorithmus dazu<br />
setzt sich aus TGV und GOTCHA [FHP02] zusammen, einem Tool von IBM. Letzteres<br />
erweitert den Algorithmus um die Möglichkeit, die Testfallauswahl anhand von<br />
Einschränkungs- und Überdeckungskriterien zu steuern.<br />
Endliche Automaten (FSM)<br />
Endliche Automaten gehören zu den am stärksten verbreiteten Verhaltensmodellen. Neben<br />
der Beschreibung von digitalen Schaltungen finden sie in allen Bereichen der Softwaretechnik<br />
ihren Einsatz.<br />
Ein FSM ist formal definiert durch ein 6-Tupel (I, O, S, s0, δ, λ). I und O entsprechen den<br />
endlichen, nicht leeren Mengen des Ein- bzw. Ausgabealphabets, S und s0 der nicht leeren<br />
Zustandsmenge bzw. dem Anfangszustand, δ ist mit δ: SxI → S die Zustandsübergangs-<br />
funktion und λ mit λ: SxI → O die Ausgabefunktion.<br />
Viele formale Notationen basieren auf den endlichen Automaten oder ähneln ihnen sehr,<br />
so auch die Statecharts [Har87], die SDL [ITU99], ASM [GKO+00], Stateflow 1 , etc.<br />
Der Verwendung von endlichen Automaten für die Testfallgenerierung kommen viele<br />
Ergebnisse aus der klassischen Automatentheorie zu Gute. Der wichtigste Algorithmus ist<br />
wohl der für das Auffinden des kürzesten Pfades zur Überdeckung aller Zustände bzw.<br />
aller Transitionen (das sog. „Briefträgerproblem“).<br />
1 http://www.mathworks.com/products/stateflow<br />
13
14<br />
Softwaretest<br />
Weitere Ergebnisse aus der Automatentheorie, die eine sinnvolle Anwendung beim modellbasierten<br />
Testen finden, sind z.B. Verfahren zur Identifizierung bzw. Überprüfung des<br />
aktuellen Automatenzustands. Oder das Auffinden einer Eingabesequenz, die den Automaten<br />
sicher in den Endzustand führt, unabhängig vom aktuellen Zustand, in dem sich der<br />
Automat befindet (eine sog. „synchronizing sequence“). Weiterhin sind Eingabesequenzen<br />
bestimmbar (sog. „homing sequences“), mit denen ein erreichter Zustand identifiziert<br />
werden kann, indem die Ausgabesequenz betrachtet wird.<br />
Zu den bekanntesten Testfallgeneratoren auf FSM-Basis gehören „Autolink“ und der<br />
„TestComposer“ [SEG00]. Die Firmen Telelogic 1 und Verilog waren vor ihrer Fusion<br />
Ende 1999 Hersteller der zwei führenden Tools für die SDL [ITU99]. Auch nach der Fusion<br />
blieben deren Produkte „Tau“ und „ObjectGeode“ eigenständig, welche die zwei<br />
genannten Testfallgeneratoren als Testkomponenten enthielten. Während der „TestComposer“<br />
die „TGV“-Algorithmen [JJ02] zur Testfallerzeugung übernahm, wurden in „Autolink“<br />
die Arbeiten des „SaMsTaG-Projektes“ [GNS+94] integriert. Dabei werden die<br />
Testfälle durch die Exploration des Zustandsraums eines vorhandenen SDL-Modells erzeugt.<br />
„PHACT“ und „TVEDA“ sind zwei weitere Testwerkzeuge auf Basis von endlichen Automaten.<br />
Mit beiden wurden akademische Anwendungsstudien betrieben. Ersteres wurde<br />
von Philips 2 im Jahre 1995 entwickelt und erzeugt aus einem endlichen Automaten Testfälle<br />
in der TTCN-2 (siehe Kapitel 2.3). Letzteres ist ebenso aus dem Jahr 1995 von der<br />
France Telecom 3 , es traversiert SDL-Modelle und erzeugt Testfälle in der TTCN-2.<br />
Daneben existiert noch eine Reihe von kommerziellen Werkzeugen mit endlichen Automaten<br />
als Eingabeformat, über deren interne Testfallgeneratoren jedoch nur wenig bekannt<br />
ist (z.B. der Conformiq 4 „Test Generator“).<br />
2.2.4 Model Driven Architecture (MDA)<br />
Andere modellbasierte Testansätze adaptieren den Grundgedanken der „Model Driven<br />
Architecture“ (MDA) [OMG03]. Die MDA repräsentiert die Vision der ausführbaren<br />
1 http://www.telelogic.de<br />
2 http://www.philips.de<br />
3 http://www.rd.francetelecom.com<br />
4 http://www.conformiq.com
Modellbasierter Test<br />
Modelle und beschreibt im Wesentlichen drei Artefakte für unterschiedliche Sichtweisen<br />
in der modellgestützten Systementwicklung.<br />
Das „Computation Independent Model“ (CIM) stellt ein Benutzungsmodell dar. Es beschreibt<br />
ein System innerhalb seiner Umgebung und fokussiert auf die Systemanforderungen.<br />
Das Modell fungiert als Schnittstelle zwischen den Verantwortlichen für die Anforderungsspezifikation<br />
und den Systemdesignern. Das „Platform Independent Model“<br />
(PIM) spezifiziert die Funktionalität eines Systems, ohne Informationen über eine spezifische<br />
Plattform zu enthalten. Es besteht aus den Spezifikationsteilen, die sich zwischen<br />
verschiedenen Plattformen nicht ändern. Im „Platform Specific Model“ (PSM) findet sich<br />
das PIM wieder, welches um Details einer bestimmten Plattform erweitert wurde.<br />
[OMG03] beschreibt generische Möglichkeiten, Transformationen zwischen diesen drei<br />
Artefakten automatisiert in beide Richtungen durchzuführen. Das PIM kann so je nach<br />
Anwendungszweck durch unterschiedliche Regelsätze in verschiedene PSMs transformiert<br />
werden. Die umgekehrte Richtung ermöglicht „reverse engineering“ und ist für die<br />
Konsistenzhaltung und Verfolgbarkeit von Funktionalitäten zwischen Modellen von Bedeutung.<br />
Es existieren zwei grundlegende Interpretationen, wie die Vision der MDA zu realisieren<br />
ist, die „Ausarbeitungs-“ („elaborationist“) und die „Übersetzungsvariante“ (“translationist“).<br />
Für beide Denkweisen existieren Literatur und Werkzeuge.<br />
Im ersten Ansatz wird manuell ein PIM erstellt, aus der automatisiert das Grundgerüst der<br />
PSM generiert werden kann. Diese muss manuell ausgearbeitet bzw. vervollständigt werden.<br />
Daraus kann dann wiederum automatisiert der Hauptteil des Codes generiert werden,<br />
welcher per Hand vervollständigt werden muss. Idealerweise soll auch die umgekehrte<br />
Richtung automatisiert sein, d.h. die Modifikationen der ausgearbeiteten Modelle können<br />
in die abstrakteren Modelle eingearbeitet werden.<br />
In der zweiten Variante wird das PIM direkt in Code übersetzt. Das PSM existiert nur als<br />
interner Zwischenschritt im Code-Generator, das weder sichtbar noch veränderbar ist.<br />
Wesentlich hierbei ist, dass keine manuelle Änderung des PSM oder des Codes notwendig<br />
ist. Es findet ein einziger Übersetzungsvorgang mit Hilfe des PIM und der Generierungsregeln<br />
statt.<br />
[ZDS+05] greift den Ansatz der MDA auf und überträgt ihn auf die Testentwicklung zum<br />
„Model Driven Testing“ (siehe Abbildung 3). Es führt zum PIM und PSM korrespondierende<br />
Testmodelle ein, das „Platform Independent Test design model“ (PIT) und das<br />
„Platform Specific Test design model“ (PST). Zum einen sollen die Testmodelle aus den<br />
entsprechenden Systemmodellen gewonnen werden, zum anderen soll nach dem MDA-<br />
15
16<br />
Softwaretest<br />
Ansatz das PST aus dem PIT hervorgehen. Zur letztgenannten Aufgabenstellung beschreibt<br />
[ZDS+05] eine konkrete Implementierung von Transformationsregeln. Als<br />
Quellsprache kommt das „UML 2 Testing Profile“ (siehe Kapitel 3.7.3) zum Einsatz, als<br />
Zielsprache dient die TTCN-3 (siehe Kapitel 2.3).<br />
Abbildung 3 „Model Driven Testing“ [ZDS+05]<br />
[SD04] beschreibt ebenso die Anwendbarkeit der MDA-Philosophie in der Testentwicklung.<br />
Die plattformunabhängige Testbeschreibung erfolgt in proprietär erweiterten<br />
UML1-Modellen. Aus diesen lässt sich automatisiert ausführbarer Python-Code generieren,<br />
welcher die plattformabhängige Testspezifikation darstellt.<br />
2.3 Testing and Test Control Notation 3<br />
Dieses Kapitel gibt einen Einblick in die Konzepte der „Testing and Test Control Notation<br />
version 3“. Es werden die Bestandteile einer TTCN-3 Testsuite, die Testarchitektur<br />
und die Verhaltensbeschreibung erläutert. Im Anschluss soll eine Beispiel-Testsuite zum<br />
besseren Verständnis beitragen. Den Abschluss bilden existierende Erweiterungen der<br />
TTCN zur Spezifikation von Zeit- und Leistungsanforderungen.<br />
2.3.1 Historie<br />
Der Ursprung der TTCN-3 liegt beim Protokolltest. Kommunikationsprotokolle regeln<br />
die Interaktionen zwischen verschiedenen Instanzen. Dabei ist es unerheblich, wo sich die<br />
Instanzen befinden, ob innerhalb eines lokalen Systems oder verteilt auf Komponenten,
Testing and Test Control Notation 3<br />
oder welches Übertragungsmedium zwischen ihnen genutzt wird. Protokolle legen die<br />
Reihenfolge der auszutauschenden Nachrichten, deren Inhalt, Bedeutung und Format fest.<br />
Beim Protokolltest liegt das Hauptaugenmerk auf dem Testen der Konformität zwischen<br />
der Spezifikation und der Implementierung. Die Konformität gewährleistet, dass unterschiedliche<br />
Implementierungen miteinander interagieren können. Für diverse Kommunikationsprotokolle<br />
existieren schon von den Standardisierungsgremien veröffentlichte<br />
Testsuiten zur Überprüfung auf Konformität.<br />
Konformitätstests sind Black-Box-Tests, da die Testfälle aus der Spezifikation gewonnen<br />
werden. Daraus folgt, dass der Formalismus der Spezifikation bedeutenden Einfluss auf<br />
das Testen der Protokolle hat. Um die Mängel informaler Techniken zu umgehen, dominieren<br />
insbesondere formale Beschreibungstechniken. Schon in den achtziger Jahren<br />
wurden für den Protokollentwurf formale Sprachen wie Estelle [ISO89], LOTOS [ISO88]<br />
und SDL [ITU99] verabschiedet.<br />
1992 verabschiedete die ISO (International Standardization Organization) den „International<br />
Standard 9646“ [ISO92], ein Rahmenwerk für den Konformitätstest von OSI-<br />
Protokollen („Conformance Testing and Methodology Framework“ (CTMF)). Dieser<br />
mehrteilige Standard beschreibt allgemeine Vorgehensweisen, Testarchitekturen und Methoden<br />
zur Konformitätsprüfung von Kommunikationsprotokollen. Zusätzlich wurde eine<br />
neue Beschreibungssprache für Testfälle eingeführt, die TTCN („Tree and Tabular Combined<br />
Notation“). Die Bezeichnung deutet an, dass in der TTCN das Testfallverhalten in<br />
Tabellen baumartig notiert wird (die Zeit verläuft von der Wurzel zu den Blättern, Verzweigungen<br />
entsprechen Alternativen).<br />
Stellte die zweite TTCN-Version noch eine Erweiterung der ursprünglichen Sprache dar<br />
(hinzu kamen insbesondere die Unterstützung von verteilten Tests und Modularisierungsmöglichkeiten),<br />
wurde mit der aktuellen dritten Version, der TTCN-3 [ETS07a],<br />
eine komplett überarbeitete Fassung veröffentlicht. Mit zahlreichen neuen Sprachkonstrukten,<br />
neuen Notationsmöglichkeiten und der Definition standardisierter Schnittstellen<br />
wurden der TTCN-3 die Beschränkungen des Protokolltests genommen. Es entstand eine<br />
universelle Testnotations- und Testimplementierungssprache. Auf Grund der neuen Notationsmöglichkeiten<br />
und zur Verdeutlichung der vielfältigen Änderungen steht hinter dem<br />
Kürzel TTCN nun die „Testing and Test Control Notation“. Im Jahre 2001 stellte die<br />
ETSI (European Telecommunications Standards Institute) die erste Fassung der TTCN-3<br />
vor. In den folgenden Jahren folgten mehrere Revisionen mit Ergänzungen und Detailverbesserungen.<br />
Zum aktuellen Zeitpunkt gilt Version 3.2.1 vom Februar 2007.<br />
17
18<br />
2.3.2 Der TTCN-3 Standard<br />
Softwaretest<br />
Die TTCN-3 ist aktuell die einzige standardisierte Testsprache, ihre Verwendung bringt<br />
demnach die Vorteile eines jeden Standards mit. Die Syntax und Semantik der Tests wird<br />
von einem größeren Anwenderkreis verstanden und hängt nicht von einer bestimmten<br />
Programmiersprache ab. Die Kosten werden gesenkt, da unterstützende kommerzielle<br />
Werkzeuge zur Verfügung stehen und sich Ausbildungskosten reduzieren. Die Sprache<br />
selbst wird gepflegt und an neue Anforderungen angepasst. Die erstellten Testsuites können<br />
besser gewartet werden. Außerdem ist die TTCN-3 als dedizierte Testsprache speziell<br />
für das Testen entwickelt worden. Als solche ist sie abstrakt gehalten, der Tester kann<br />
sich auf das Entwickeln der Tests konzentrieren, ohne auf Details des getesteten Systems<br />
Rücksicht nehmen zu müssen.<br />
Im Speziellen zeichnet sich die TTCN-3 durch folgende Eigenschaften aus. Ihre Syntax,<br />
ihre statische und ihre operationelle Semantik sind wohldefiniert. Die Sprache erlaubt das<br />
Erstellen von dynamischen, d.h. zur Laufzeit veränderlichen Testkonfigurationen aus<br />
nebenläufig agierenden Testkomponenten. Zur Kommunikation mit dem zu testenden<br />
System stehen der Prozeduraufruf und der asynchrone Nachrichtenaustausch zur Verfügung.<br />
Für die Datenbehandlung existieren sowohl CoDec-Mechanismen für die Kodierung<br />
bzw. Dekodierung der Daten als auch Verfahren für das „Matching“, d.h. für das<br />
Erkennen und Überprüfen des Datentyps ankommender Nachrichten. Des Weiteren fallen<br />
die optionalen Notationsmöglichkeiten auf, die das einfachere Verständnis fördern und<br />
dem Trend zu graphischen Designs Rechnung tragen.<br />
Die aktuelle Spezifikation der TTCN-3 besteht aus acht Teilen. Die Kernspezifikation<br />
(Teil 1) wird durch zwei weitere Notationsmöglichkeiten – einer tabellarischen (Teil 2)<br />
und einer graphischen (Teil 3) – ergänzt. Die operationelle Semantik (Teil 4) definiert die<br />
Bedeutung der Verhaltensanweisungen der Sprache. Die nächsten zwei Teile widmen sich<br />
den Schnittstellen des ausführbaren bzw. interpretierbaren TTCN-3 Codes, das „TTCN-3<br />
Runtime Interface“ (Teil 5) stellt das API zum „System Under Test“ (SUT) dar, das<br />
„TTCN-3 Control Interface“ (Teil 6) das API zu weiteren Komponenten des Testsystems.<br />
Die beiden letzten Teile beschreiben die Benutzung der abstrakten Datenbeschreibungssprache<br />
ASN.1 (Abstract Syntax Notation One) (Teil 7) und der Schnittstellenbeschreibungssprache<br />
IDL (Teil 8) innerhalb der TTCN-3.
Testing and Test Control Notation 3<br />
Abbildung 4 Benutzersicht auf die TTCN-3 [ETS07a]<br />
Abbildung 4 zeigt die Benutzersicht auf die TTCN-3. Die linke Hälfte deutet an, dass<br />
neben den TTCN-3-eigenen Datentypen auch andere Sprachen zu ihrer Definition erlaubt<br />
sind. Neben der ASN.1 dürfte insbesondere die XML als weitere Möglichkeit folgen.<br />
Die rechte Seite stellt zum einen die standardisierten Präsentationsformate dar, d.h. die<br />
textuelle, tabellarische und die graphische (MSC-ähnliche) Notation. Zum anderen lässt<br />
der Standard weitere Formate zu, die für bestimmte Anwendungsbereiche geeigneter erscheinen.<br />
Abbildung 5 Allgemeine Struktur eines TTCN-3 Testsystems, nach [ETS07c]<br />
In Abbildung 5 ist die Gesamtstruktur eines Testsystems zu erkennen. Das Kernstück<br />
stellt der ausführbare TTCN-3-Code dar (TTCN-3 Executable), welcher in kompilierter<br />
oder interpretierbarer Form vorliegen kann. Aufgrund des abstrakten Charakters fehlen<br />
diesem implementierungsspezifische Informationen über das zu testende System (SUT).<br />
Die Kommunikation erfolgt daher über den „System Adaptor“ (SA), der die benötigten<br />
19
20<br />
Softwaretest<br />
Kommunikationsmechanismen und Protokollstapel enthält. Im „Platform Adaptor“ stehen<br />
weitere systemspezifische Funktionen bereit, beispielsweise werden hier spezielle Timer<br />
und externe Funktionsaufrufe realisiert. Die Schnittstellen zu den zwei letztgenannten<br />
Komponenten sind im sog. „TTCN-3 Runtime Interface“ (TRI) [ETS07b] festgelegt, dies<br />
gibt Toolherstellern größere Freiheiten bei der Entwicklung von Werkzeugen zur Testausführung.<br />
Die zweite Schnittstelle ist das „TTCN-3 Control Interface“ (TCI), sie regelt die Aufrufsyntax<br />
zu vier logischen Komponenten. Im Test Management (TM) werden alle organisatorischen<br />
Aufgaben der Testausführung geregelt inkl. diverser Modulparameter und externen<br />
Konstanten. Eine optionale graphische Benutzeroberfläche zur einfacheren Testausführung<br />
wäre hier angesiedelt.<br />
Die Test Logging (TL) Komponente realisiert alle Operationen zum Abrufen von Informationen<br />
über die Testausführung. Die Ergebnisliste kann gefiltert werden, um den benötigten<br />
Detaillierungsgrad zu beeinflussen.<br />
Über das „Coding/Decoding Interface“ (CoDec) wird auf benötigte Kodierer und Dekodierer<br />
zugegriffen, um zu sendende und empfangene Daten entsprechend bearbeiten zu<br />
können.<br />
Das „Component Handling“ (CH) realisiert Operationen zum Management der Testkomponenten,<br />
d.h. zu deren Erstellung, Auflösung und zum Aufbau der gewünschten Komponentenverbindungen.<br />
Ebenso wird die gesamte Kommunikation unter den Testkomponenten<br />
über das CH realisiert, gleich ob in einer lokalen oder verteilten Testkonfiguration.<br />
2.3.3 Verteilter Test<br />
Abbildung 6 zeigt die Struktur im Fall einer Testkonfiguration, bei der die TE auf mehrere<br />
Knoten verteilt ist. Jeder Knoten besitzt neben der TE eine Entität von SA, PA, CD und<br />
TL. Das TM und CH existieren nur einmal zur Überwachung des gesamten Tests bzw.<br />
zur Steuerung der Testkomponenten auf den unterschiedlichen Knoten. Eine spezielle<br />
TTCN-3 Executable startet einen Testfall und vergibt das finale Testurteil, ansonsten<br />
werden alle TEs gleich behandelt.<br />
Die Kommunikation zwischen den Testkomponenten wird von der CH-Komponente verwaltet.<br />
Ganz gleich, ob die Empfängertestkomponente sich auf dem gleichen Testknoten<br />
befindet oder nicht, oder ob die Kommunikation prozedural oder nachrichtenbasiert abläuft.<br />
Die CH-Komponente empfängt den Kommunikationswunsch und adaptiert vor der<br />
Weiterleitung das Signal bzw. die Nachricht auf die entsprechende Zielplattform. Den<br />
Testkomponenten bleibt ihre örtliche Verteilung verborgen.
Testing and Test Control Notation 3<br />
Abbildung 6 Allgemeines verteiltes TTCN-3 Testsystem, nach [ETS07c]<br />
2.3.4 Testkonfiguration<br />
In der TTCN-3 besteht eine Testkonfiguration aus einer Menge nebenläufig agierender<br />
Testkomponenten, welche dynamisch spezifizierbar – also während des Testablaufs veränderbar<br />
– ist. Ein Testsystem besteht immer aus einer „Main Test Component“ (MTC),<br />
welche implizit beim Start eines Testfalls erzeugt wird und das in ihr spezifizierte Verhalten<br />
ausführt. Alle anderen Testkomponenten sind parallele Testkomponenten (PTC), die<br />
explizit durch die MTC oder anderen PTCs erstellt und zerstört werden.<br />
Abbildung 7 Typische TTCN-3 Testkonfiguration [ETS07a]<br />
Komponenten besitzen Ports, über die sie kommunizieren können. Jeder Port ist als potentiell<br />
unendliche FIFO-Warteschlange für Nachrichten bzw. Prozeduraufrufe spezifiziert.<br />
Das Überlaufen eines Ports in einem realen Testsystem soll zu einem Testfallurteil<br />
21
22<br />
Softwaretest<br />
„error“ führen (siehe Kapitel 2.3.5). In Abbildung 7 ist neben den Komponenten das Test<br />
System Interface (TSI) zu sehen. Es stellt die Kommunikationsschnittstelle zur SUT dar<br />
und untergliedert sich wiederum in zwei Teile, dem abstrakten und dem realen TSI.<br />
Das Abstrakte Test System Interface stellt die TTCN-3-interne Schnittstelle zur SUT dar<br />
und ist nichts anderes als eine weitere Testkomponente mit dem reservierten Schlüsselnamen<br />
„system“. Sie kommuniziert mit dem „realen“ TSI durch Aufruf der Funktionen,<br />
die im TTCN-3 Runtime Interface (TRI) implementiert sind.<br />
2.3.5 TTCN-3 Module<br />
Eine Testspezifikation in der TTCN-3 besteht zunächst aus Modulen, welche die oberste<br />
Struktureinheit darstellen. Sie sind parametrisierbar und können untereinander Definitionen<br />
importieren. In ihnen werden alle benötigten Informationen spezifiziert, von den<br />
Testkonfigurationen über das Testverhalten bis hin zu Anweisungen zur Testablaufsteuerung.<br />
Letztere befinden sich im optionalen Kontrollteil des Moduls, welche lokale Variablen,<br />
Konstanten und Timer enthalten. Ihre Hauptaufgabe liegt jedoch in der Festlegung der<br />
Ausführungsreihenfolge der Testfälle durch die Verwendung von Bedingungen und<br />
Schleifen. Fehlt der Kontrollteil, dient das Modul mit den enthaltenen Deklarationen und<br />
Testfällen als Bibliotheksmodul.<br />
Alle weiteren Anweisungen befinden sich im Definitionsteil. Zum einen sind dies datenrelevante<br />
Informationen wie die Datentypen und die Vorlagen für die Testdaten. Neben<br />
den üblichen Datentypen wie den primitiven, den benutzerdefinierten oder Typen für<br />
Strings existiert ein spezieller Datentyp namens verdicttype. Jede Testkomponente besitzt<br />
ein Objekt „verdict“ von diesem Typ zur Aufnahme des lokalen Testurteils. Dieses kann<br />
eines von fünf Werten annehmen: none, pass, fail, inconclusive oder error. Zu Beginn<br />
eines Testfalls ist der Wert none, während seiner Durchführung kann explizit ein pass,<br />
fail oder im nicht spezifizierten Fall ein inconclusive Fall gesetzt werden. Treten Fehler in<br />
der Testumgebung auf, wird implizit ein error gesetzt.<br />
Datenvorlagen bzw. „Templates“ dienen zum einen zur Beschreibung der zu sendenden<br />
Testdaten, zum anderen dienen sie beim Datenempfang als Grundlage eines Matching-<br />
Verfahrens zu deren Korrektheitsüberprüfung. Das folgende Beispiel verdeutlicht das<br />
Konzept, der folgende Codeabschnitt definiert einen Nachrichtentyp „MessageType1“:
Testing and Test Control Notation 3<br />
type record MessageType1 {<br />
integer field1,<br />
boolean field2<br />
}<br />
Für den Empfang einer Nachricht dieses Typs wird ein Template definiert. Im Beispiel<br />
fordert das „Template1“ für den zweiten Parameter den positiven Boolwert.<br />
template MessageType1 Template1 := {<br />
field1 := ?,<br />
field2 := true<br />
}<br />
Aufgerufen wird die Empfangsoperation durch:<br />
P1.receive(Template1);<br />
Für die Versenden von Nachrichten werden ebenfalls Templates erstellt, z.B.:<br />
template MessageType1 Template2 := {<br />
field1 := 3,<br />
field2 := false<br />
}<br />
Die Sendeoperation erfolgt dann durch:<br />
P1.send(Template2);<br />
2.3.6 TTCN-3 Verhalten<br />
Wichtigste Aufgabe und Hauptbestandteil des Definitionsteils ist die Beschreibung des<br />
gewünschten Testverhaltens. Dies geschieht in Testfällen und Funktionen, wobei erstere<br />
in der TTCN-3 ebenso Funktionen sind, mit der Besonderheit der Rückgabe eines Testurteils.<br />
Funktionen beschreiben entweder Testverhalten oder dienen der Strukturierung innerhalb<br />
des Moduls, z.B. für wiederholende Aufrufe bestimmter Anweisungen.<br />
Wird im Kontrollteil eines Moduls ein Testfall aufgerufen, so wird implizit die Haupt-<br />
Testkomponente (MTC) dieses Testfalls erzeugt, bevor auf ihr die erste Anweisung ausgeführt<br />
wird. Die MTC kann dann explizit weitere zu ihr parallel laufende Komponenten<br />
(PTCs) starten und auf ihnen Funktionen aufrufen. Mit dem Ende eines Testfalls wird die<br />
MTC gestoppt und mit ihr implizit alle weiteren existierenden Komponenten.<br />
23
24<br />
Softwaretest<br />
Jede Testkomponente einschließlich der MTC berechnet ihr lokales Testurteil. Ist ein<br />
Testfall beendet, wird aus ihnen nach einem definierten Schema das globale Testergebnis<br />
gebildet, welches vom Testfall an den Kontrollteil des Moduls zurückgegeben wird. Der<br />
Mechanismus zur Erzeugung des globalen Testurteils ist nicht spezifiziert.<br />
Alternatives und verschränktes Verhalten<br />
Eine genaue Erläuterung aller TTCN-3-Anweisungen kann in [ETS07a] nachgeschlagen<br />
werden. Die Semantiken zweier Anweisungen wirken sich in besonderer Weise auf das<br />
Zeitverhalten aus und werden hier näher erläutert.<br />
Die Anweisung „alt“ stellt eine Verzweigung im Kontrollfluss aufgrund des möglichen<br />
Empfangs verschiedener Nachrichten bzw. Signale dar. Die folgende Abbildung 8 stellt<br />
links ein Beispiel in textueller TTCN-3 Notation dar, rechts als Sequenzdiagramm mit<br />
Annotationen aus dem „UML2 Testing Profile“. Das Diagramm zeigt zwei Objekte, eine<br />
Testkomponente und einen Port P1, welche Nachrichten austauschen. Die Zeit schreitet<br />
im Sequenzdiagramm von oben nach unten voran, die umrandeten Alternativen sind jeweils<br />
durch eine gestrichelte Linie voneinander getrennt. Die Angaben der „validationAction“<br />
entsprechen dem Setzen eines Testurteils. Eine genaue Erläuterung des Diagrammtyps<br />
und des Profils finden sich in Kapitel 3.6 bzw. 3.7.3 wieder.<br />
alt {<br />
}<br />
[] P1.receive(Nachricht1) {<br />
setverdict(pass);<br />
}<br />
[] P1.receive(Nachricht2) {<br />
setverdict(fail);<br />
}<br />
[] t1.timeout {<br />
setverdict(fail);<br />
}<br />
Abbildung 8 Anweisung für alternatives Verhalten
Testing and Test Control Notation 3<br />
Die „interleave“-Anweisung beschreibt den möglichen Empfang verschiedener Nachrichten<br />
in beliebiger Reihenfolge. Sie kann als eine Kurzschreibweise für eine größere Anzahl<br />
verschachtelter „alt“-Anweisungen angesehen werden, so nehmen auch aktuelle Tools<br />
diese Umwandlung intern vor. Der folgende Codeabschnitt beschreibt den möglichen<br />
Empfang dreier Nachrichten in beliebiger Reihenfolge.<br />
interleave {<br />
[] P1.receive(Nachricht1);<br />
[] P1.receive(Nachricht2);<br />
[] P1.receive(Nachricht3);<br />
}<br />
2.3.7 INRES-Beispiel<br />
Dieses Kapitel gibt für einen einfachen Testfall TTCN-3-Code in textueller Notation wieder.<br />
Als Beispiel dient der einmalige Austausch von Daten inklusive dem Auf- und Abbau<br />
der Verbindung zwischen zwei Instanzen, wie er im INRES-Protokoll [Hog91] beschrieben<br />
ist.<br />
Abbildung 9 INRES - Protokoll<br />
Die Abbildung 9 stellt das zu testende Szenario dar: Der Sender fordert mit ICONreq eine<br />
Verbindung an, die der Diensterbringer dem Empfänger mit ICONind anzeigt. Der Empfänger<br />
antwortet mit ICONresp, der Sender erhält die Bestätigung mit ICONconf. Der<br />
25
26<br />
Softwaretest<br />
Datenaustausch erfolgt mit der Nachricht IDATreq, welche als IDATind empfangen wird.<br />
Mit der Nachricht IDISreq bzw. IDISind wird die Verbindung vom Empfänger wieder<br />
geschlossen.<br />
Abbildung 10 stellt den Testfall dar und zeigt den Nachrichtenaustausch zwischen Testsystem<br />
und SUT. Ersterer besteht aus der MTC und zwei PTCs, die Sender und Empfänger<br />
darstellen.<br />
Zusätzlich werden Synchronisierungsnachrichten mit der MTC ausgetauscht, wie sie in<br />
Kapitel 4.3 beschrieben sind. Diese dienen unter anderem der Sicherstellung der geforderten<br />
Empfangsreihenfolge auf der Systeminstanz, die sonst aufgrund der partiellen Ordnungsrelation<br />
der Ereignisse nicht gewährleistet ist. Da schon in Abbildung 9 eine totale<br />
Ordnung der Ereignisse gegeben ist, dienen die Synchronisierungsnachrichten in diesem<br />
Beispiel lediglich der Übermittlung des lokalen Testurteils (siehe Kapitel 4.3).<br />
Abbildung 10 INRES - Testfall
Testing and Test Control Notation 3<br />
Die oberste Ordnungseinheit in der TTCN-3 ist das Modul, darin sind alle folgenden Definitionen<br />
enthalten.<br />
module inres_module<br />
{ …<br />
}<br />
Zu Beginn des Definitionsteils werden Porttypen mit den über sie austauschbaren Nachrichten<br />
definiert. Über Ports kommunizieren die Testkomponenten untereinander, im Beispiel<br />
sind das Ports für Nachrichten jeden Typs zwischen der MTC und den PTCs und<br />
zwischen letzterem und der abstrakten SUT-Komponente.<br />
/* Definitionsteil */<br />
type port mtc2ptc_type message {<br />
inout all ;}<br />
type port ptc2mtc_type message {<br />
inout all ;}<br />
type port I_user_type2sut_type message {<br />
inout all ;}<br />
type port R_user_type2sut_type message {<br />
inout all ;}<br />
Unter Verwendung der Ports werden die Komponententypen definiert. Die Testkomponente<br />
„inres_type“ stellt das Abstrakte Test System Interface dar (siehe Kapitel 2.3.4). Es<br />
stellt intern die Schnittstelle zum SUT dar.<br />
type component I_user_type {<br />
port I_user_type2sut_type I_user_type2sut;<br />
port ptc2mtc_type ptc2mtc; }<br />
type component R_user_type {<br />
port R_user_type2sut_type R_user_type2sut;<br />
port ptc2mtc_type ptc2mtc; }<br />
type component mtc_type {<br />
port mtc2ptc_type mtc2ptc ;<br />
var Sync PTCResult; }<br />
type component inres_type {<br />
port I_user_type2sut_type I_user_type2sut;<br />
port R_user_type2sut_type R_user_type2sut; }<br />
27
28<br />
Softwaretest<br />
Nach der Beschreibung der strukturellen Bestandteile des Tests folgt das Testverhalten.<br />
Wie in Kapitel 2.3.6 beschrieben, wird zu Beginn eines Testfalls implizit die MTC erzeugt,<br />
der Testfall „tc1“ startet auf der MTC des Typs „mtc_type“. Die abstrakte Testsystemschnittstelle<br />
trägt stets den reservierten Schlüsselnamen „system“, welcher im Beispiel<br />
vom Typ „inres_type“ ist.<br />
/* MTC */<br />
testcase tc1 runs on mtc_type system inres_type<br />
{<br />
var I_user_type I_user;<br />
var R_user_type R_user;<br />
I_user := I_user_type.create;<br />
I_user.start(I_user_function());<br />
R_user := R_user_type.create;<br />
R_user.start(R_user_function());<br />
Die MTC erstellt die PTCs, in diesem Fall die Sender- und Empfängerkomponente, und<br />
startet auf ihnen Funktionen zur Testausführung, die im Anschluss an den Testfall definiert<br />
sind. Im Anschluss startet der Nachrichtenaustausch, die Konstrukte „interleave“<br />
und „alt“ sind in Kapitel 2.3.6 beschrieben. Nach Auslesen der – in den „sync“-<br />
Nachrichten mitgeschickten – Testurteile setzt die MTC das globale Testurteil und protokolliert<br />
die einzelnen Schritte mittels der „log“-Anweisung.<br />
interleave{<br />
[]mtc2ptc.receive(sync) from I_user {};<br />
[]mtc2ptc.receive(sync) from R_user {};<br />
}<br />
mtc2ptc.send(sync_ack) to I_user;<br />
alt{<br />
[]mtc2ptc.receive(sync) from R_user -> value PTCResult{<br />
if (PTCResult.report == “pass”){<br />
setverdict(pass);<br />
log(“I_user:ICONreq, pass”);<br />
log(“R_user:ICONind, pass”); }<br />
if (PTCResult.report == “fail”){<br />
setverdict(fail);<br />
log(“I_user:ICONreq, fail”);<br />
log(“R_user:ICONind, fail”); }<br />
}<br />
[]mtc2ptc.receive from R_user {<br />
setverdict(inconc);<br />
log(“I_user:ICONreq, inconc”);
Testing and Test Control Notation 3<br />
log(“R_user:ICONind, inconc”);<br />
}<br />
}<br />
mtc2ptc.send(sync_ack) to R_user;<br />
alt{<br />
[]mtc2ptc.receive(sync) from I_user -> value PTCResult{<br />
if (PTCResult.report == “pass”){<br />
setverdict(pass);<br />
log(“[R_user:ICONresp], pass”);<br />
log(“[I_user:ICONconf], pass”); }<br />
if (PTCResult.report == “fail”){<br />
setverdict(fail);<br />
log(“[R_user:ICONresp], fail”);<br />
log(“[I_user:ICONconf], fail”); }<br />
}<br />
[]mtc2ptc.receive from I_user {<br />
setverdict(inconc);<br />
log(“[R_user:ICONresp], inconc”);<br />
log(“[I_user:ICONconf], inconc”);<br />
}<br />
}<br />
mtc2ptc.send(sync_ack) to I_user;<br />
alt{<br />
[]mtc2ptc.receive(sync) from R_user -> value PTCResult{<br />
if (PTCResult.report == “pass”){<br />
setverdict(pass);<br />
log(“I_user:IDATreq, pass”);<br />
log(“R_user:IDATind, pass”); }<br />
if (PTCResult.report == “fail”){<br />
setverdict(fail);<br />
log(“I_user:IDATreq, fail”);<br />
log(“R_user:IDATind, fail”); }<br />
}<br />
[]mtc2ptc.receive from R_user {<br />
setverdict(inconc);<br />
log(“I_user:IDATreq, inconc”);<br />
log(“R_user:IDATind, inconc”);<br />
}<br />
}<br />
mtc2ptc.send(sync_ack) to R_user;<br />
interleave{<br />
[]mtc2ptc.receive(sync) from R_user -> value PTCResult{<br />
if (PTCResult.report == “pass”){<br />
setverdict(pass);<br />
log(“R_user:IDISreq, pass”); }<br />
29
30<br />
}<br />
Softwaretest<br />
if (PTCResult.report == “fail”){<br />
setverdict(fail);<br />
log(“R_user:IDISreq, fail”); }<br />
}<br />
[]mtc2ptc.receive(sync) from I_user -> value PTCResult{<br />
if (PTCResult.report == “pass”){<br />
setverdict(pass);<br />
log(“[I_user:IDISind], pass”); }<br />
if (PTCResult.report == “fail”){<br />
setverdict(fail);<br />
log(“[I_user:IDISind], fail”); }<br />
}<br />
}<br />
stop;<br />
In den folgenden zwei Funktionen ist das Testverhalten der PTCs beschrieben, zunächst<br />
für den Sender, danach für den Empfänger. Mit den Anweisungen „connect“ und „map“<br />
stellen die Testkomponenten gemäß der gewünschten Testkonfiguration die Verbindungen<br />
zu der MTC und zur Testsystemschnittstelle her.<br />
/* PTC I_user */<br />
function I_user_function() runs on I_user_type {<br />
connect(self:ptc2mtc, mtc:mtc2ptc);<br />
map(self:I_user_type2sut, system: I_user_type2sut);<br />
ptc2mtc.send(sync());<br />
ptc2mtc.receive(sync_ack);<br />
I_user_type2sut.send(ICONreq);<br />
alt{<br />
[]I_user_type2sut.receive(ICONconf){<br />
ptc2mtc.send(sync(“pass”));<br />
setverdict(pass) ;}<br />
[]I_user_type2sut.receive {<br />
ptc2mtc.send(sync(“fail”));<br />
setverdict(fail) ;}<br />
}<br />
ptc2mtc.receive(sync_ack);<br />
I_user_type2sut.send(IDATreq);<br />
alt{<br />
[]I_user_type2sut.receive(IDISind){<br />
ptc2mtc.send(sync(“pass”));<br />
setverdict(pass) ;}<br />
[]I_user_type2sut.receive {<br />
ptc2mtc.send(sync(“fail”));
Testing and Test Control Notation 3<br />
}<br />
setverdict(fail) ;}<br />
}<br />
disconnect(self:ptc2mtc, mtc:mtc2ptc);<br />
unmap(self:I_user_type2sut, system: I_user_type2sut);<br />
stop;<br />
/* PTC R_user */<br />
function R_user_function() runs on R_user_type {<br />
connect(self:ptc2mtc, mtc:mtc2ptc);<br />
map(self:R_user_type2sut, system: R_user_type2sut);<br />
ptc2mtc.send(sync());<br />
alt{<br />
[]R_user_type2sut.receive(ICONind){<br />
ptc2mtc.send(sync(“pass”));<br />
setverdict(pass) ;}<br />
[]R_user_type2sut.receive {<br />
ptc2mtc.send(sync(“fail”));<br />
setverdict(fail) ;}<br />
}<br />
ptc2mtc.receive(sync_ack);<br />
R_user_type2sut.send(ICONresp);<br />
alt{<br />
[]R_user_type2sut.receive(IDATind){<br />
ptc2mtc.send(sync(“pass”));<br />
setverdict(pass) ;}<br />
[]R_user_type2sut.receive {<br />
ptc2mtc.send(sync(“fail”));<br />
setverdict(fail) ;}<br />
}<br />
ptc2mtc.receive(sync_ack);<br />
R_user_type2sut.send(IDISreq);<br />
ptc2mtc.send(sync(“pass”));<br />
disconnect(self:ptc2mtc, mtc:mtc2ptc);<br />
unmap(self:R_user_type2sut, system: R_user_type2sut);<br />
stop;<br />
}<br />
Nach Ausführung der Funktion trennen die Testkomponenten ihre Verbindungen zu anderen<br />
Komponenten und stoppen.<br />
Im Kontrollteil des Moduls wird der Testfall „tc1“ mit der Anweisung „execute“ gestartet.<br />
31
32<br />
/* Kontrollteil */<br />
control{<br />
execute(tc1());<br />
}<br />
2.3.8 TTCN Echtzeit- und Leistungserweiterungen<br />
Softwaretest<br />
Die TTCN wurde für den funktionalen Test entwickelt, so fehlen auch der neuesten Version<br />
grundlegende Konzepte zum Test von zeitbezogenen Bedingungen.<br />
In der TTCN-3 existiert lediglich ein Timerkonzept, welches das Einstellen einer maximalen<br />
Wartezeit für das Eintreffen von Nachrichten ermöglicht. Durch den Einsatz eines<br />
testfallweiten Timers lassen sich so effektiv blockierende Testfälle verhindern, die auf<br />
eine (verloren gegangene) Nachricht warten. Für die Spezifikation von Echtzeitanforderungen<br />
ist der Timer jedoch aus mehreren Gründen ungeeignet.<br />
Die Geschwindigkeit der Konsumierung eines Timeouts hängt direkt von der in Kapitel<br />
2.3.6 beschriebenen „snapshot“-Semantik ab. Hier kommt die Trägheit dieses Konzepts<br />
zum Tragen, da das Bilden eines Schnappschusses eine unbestimmte Zeit braucht, diese<br />
nur in nicht vorhersagbaren zeitlichen Abständen getätigt werden und die Reihenfolge der<br />
Verzweigungen in der „alt“-Anweisung von hoher Bedeutung ist. Des Weiteren besitzt<br />
jeder Testfall eine Timeout-Liste, in die sich ein ausgelaufener Timer einträgt und die bei<br />
Bedarf durchsucht wird. Die Suchreihenfolge innerhalb dieser Liste ist nicht spezifiziert,<br />
die benötigte Zeit daher nicht vorhersagbar.<br />
Ein weiterer Nachteil des Timers ist die Begrenztheit auf eine Testkomponente. Eine<br />
Echtzeitanforderung über mehrere Komponenten hinweg ist hiermit prinzipbedingt nicht<br />
testbar.<br />
PerfTTCN<br />
Daher wurden schon für die Vorgängerversion TTCN-2 Vorschläge veröffentlicht, die<br />
Sprache diesbezüglich zu erweitern. PerfTTCN [SSR97] beschreibt nötige Konzepte zur<br />
Durchführung von Leistungstests mit der TTCN-2. Die Testkonfigurationen werden um<br />
eine Beschreibung der vorherrschenden Last erweitert, welche in Hintergrund- und Vordergrundlast<br />
unterteilt ist. Neu ist insbesondere die Erzeugung und Kontrolle der Hintergrundlast,<br />
um das gewonnene Testurteil bezüglich der genauen Lastsituation bewerten zu<br />
können. Zweitens wird ein mächtigeres Verkehrsmodell eingeführt, um diskrete und kontinuierliche<br />
Datenströme zu beschreiben. Daneben kann für definierte Messpunkte die zu<br />
messende Metrik deklariert werden, z.B. die Verzögerungszeit, der Jitter oder der Durch-
Testing and Test Control Notation 3<br />
satz. Statistische Indikatoren (z.B. min, max, mean) ergänzen die Metriken. Abschließend<br />
erweitert PerfTTCN das Testurteil für den Leistungstest. Die Beschreibung der PerfTTCN<br />
blieb jedoch syntaktischer Natur und wurde nicht praktisch umgesetzt.<br />
RT-TTCN<br />
Ein weiterer Vorschlag zur Echtzeiterweiterung der TTCN-2 trägt den Namen RT-TTCN<br />
[WG99]. Damit können die TTCN-2-Anweisungen um die Angabe eines Zeitintervalls<br />
erweitert werden, welches die früheste und die späteste erlaubte Ausführung kennzeichnet.<br />
Zusätzlich wurde die Sprache durch die Abbildung auf ein „Timed Transition System“<br />
formalisiert. Bei praktischen Umsetzungen hat sich jedoch gezeigt, dass Benutzer<br />
mit der Handhabung der Zeitintervalle Probleme hatten, da Zeitpunkte relativ zu vorherigen<br />
Ereignissen angegeben werden. Dies führte zu einer schlechten Akzeptanz und verhinderte<br />
einen größeren Erfolg der RT-TTCN.<br />
TimedTTCN-3<br />
Für die TTCN-3 existiert mit der TimedTTCN-3 [Neu04] ebenfalls eine Erweiterung zur<br />
Beschreibung von Echtzeitanforderungen. Wie in der PerfTTCN wird das Testurteil um<br />
einen neuen Wert erweitert, der im Falle eines funktionalen „pass“ und eines nichtfunktionalen<br />
„fail“ gesetzt wird. Eine wesentliche Erweiterung stellt das Bereitstellen<br />
einer Systemuhr dar, die das Abrufen der absoluten Zeit ermöglicht. Dies löst – zumindest<br />
konzeptionell – das Problem der Überprüfung von Zeitanforderungen über mehrere Testkomponenten<br />
hinweg. Ein Aufruf der Operation „now“ liefert die lokale Uhrzeit zurück,<br />
die Operation „resume“ ermöglicht das Setzen von Wartezeiten. Sogar das Synchronisationsproblem<br />
unterschiedlicher Systemuhren wird durch ein eingeführtes Attribut „timezone“<br />
angegangen. Gemessene Zeiten dürfen nur dann in Relation gesetzt werden, wenn<br />
sie der gleichen „Zeitzone“ entspringen. Dies ermöglicht die Kennzeichnung nichtsynchroner<br />
Uhren.<br />
Zur Evaluierung der Echtzeiteigenschaften bietet die TimedTTCN-3 zwei Möglichkeiten.<br />
Eine Onlineüberprüfung muss in der Testsprache selbst durch Funktionen durchgeführt<br />
werden, die z.B. in einer Funktionsbibliothek bereitgestellt werden können. Zur nachträglichen<br />
(Offline-)Überprüfung können gesicherte Zeitstempel in Protokolldateien ausgewertet<br />
werden. Das nur ungenau beschriebene Logging-Konzept der TTCN-3 wird daher<br />
erweitert. Dies geschieht insbesondere durch eine stärkere Formalisierung der Syntax und<br />
Struktur der Logdateien und durch Zugriffsmöglichkeiten aus den Testkomponenten bzw.<br />
dem Kontrollteil heraus.<br />
33
34<br />
Softwaretest
3 Die Unified Modeling Language 2<br />
Das folgende Kapitel gibt einen Überblick über die UML in der Version 2. Genauere Erläuterung<br />
finden nur die in dieser Arbeit relevanten Teile. Umfassende Informationen<br />
geben unter anderem [OMG06a-f, OMG07a-c, RJB04, JRH+04, Dou04].<br />
Die UML ist eine Sprachenfamilie und dient in der Softwareentwicklung der <strong>Dokument</strong>ation,<br />
Spezifikation, Modellierung und Visualisierung. Sie vereint verschiedene Notationsmöglichkeiten<br />
sowohl für statische als auch dynamische Aspekte eines Systems. Die<br />
Sprache ist bewusst allgemein gehalten, sie ist weder auf ein bestimmtes Anwendungsgebiet<br />
noch auf einen bestimmten Entwurfsprozess hin ausgerichtet. Der Fokus liegt jedoch<br />
auf objektorientierten Vorgehensweisen.<br />
3.1 Historie<br />
Die UML bekam ihren Namen erstmals 1996 mit dem Zusammenschluss dreier Modellierungsansätze<br />
in der Softwareentwicklung. Rumbaugh und Booch vereinten 1995 ihre<br />
OMT und OOD genannten Methoden zunächst zur „Unified Method“, ein Jahr später kam<br />
OOSE von Jacobson dazu. Nach einem Vereinheitlichungsprozess veröffentlichten sie<br />
1997 die UML 1.0 [JRH+04].<br />
Bis zur Version 1.5 im Jahre 2003 hat die Sprache viele Erweiterungen und Veränderungen<br />
erfahren. Die „Object Constraint Language“ (OCL) wurde in die UML 1.1 integriert,<br />
um den Ausdruck formaler konsistenzsichernder Einschränkungen zu ermöglichen. Die<br />
„XML Metadata Interchange“ (XMI) (siehe Kapitel 3.5) wurde Bestandteil der UML 1.3<br />
und ermöglichte eine standardisierte textuelle Notation der graphischen Elemente. 1999<br />
mit der Version 1.3 übergaben die drei Sprachgründer das Copyright an die „Object Management<br />
Group“ (OMG 1 ), einem Industriegremium mit mehreren hundert Mitgliedern.<br />
Nach der Version 1.5 verabschiedete die OMG im Jahre 2005 die finale Fassung der Version<br />
2.0, welche eine große Überarbeitung darstellt. Wichtigste Ziele waren eine größere<br />
Kompaktheit, die Präzisierung der Semantik [ECM+99] und die Abwärtskompatibilität.<br />
Mit ersterem sollte der Vorwurf der zu großen Komplexität begegnet werden. In die Semantikpräzisierung<br />
gingen insbesondere Arbeiten der „precise UML group 2 “ ein, einer<br />
1 http://www.omg.org<br />
2 http://www.puml.org<br />
35
36<br />
Die Unified Modeling Language 2<br />
offenen internationalen Arbeitsgruppe zur Stärkung der UML-Semantik. Dies ist eine<br />
Voraussetzung für die Realisierung der Idee ausführbarer Modelle, die sich bei der OMG<br />
in der „Model Driven Architecture“ (MDA) manifestiert hat.<br />
Im April 2006 veröffentlichte die „Revision Task Force“ der UML – die verantwortliche<br />
Gruppe für die Pflege und Weiterentwicklung der Sprache – eine Vorabversion der UML<br />
2.1 [OMG06a, OMG06f]. Sie enthält kleine Detailverbesserungen und Fehlerkorrekturen.<br />
Im Februar 2007 folgte die endgültige Verabschiedung unter der Versionsnummer 2.1.1<br />
[OMG07a, OMG07b].<br />
Die UML2 besteht aus zwei Teilstandards, dem „Infrastructure“- [OMG07b] und dem<br />
„Superstructure“-<strong>Dokument</strong> [OMG07a]. Die Infrastructure definiert Basisklassen und<br />
grundlegende Sprachkonstrukte, die die Grundlage für die Superstructure bilden. Im letzteren<br />
werden die Diagrammtypen, ihre Semantik und die Notation definiert.<br />
Ergänzt wird die Sprachenspezifikation durch eine überarbeitete Version der OCL<br />
[OMG06e] und eine gänzlich neue Spezifikation – die „Diagram Interchange“<br />
[OMG06d]. Diese stellt ein Erweiterungspaket für das UML-Metamodell dar, welches<br />
jedes Modellelement um die Fähigkeit erweitert, graphische Informationen zu beschreiben.<br />
Dadurch ist es erstmalig möglich, UML-Modelle nicht nur durch ihre Modellinformationen,<br />
sondern auch mit graphischen Informationen standardkonform mit der XMI<br />
auszutauschen.<br />
Um eine konsistente deutsche Namensgebung für die zahlreichen UML-Begriffe zu gewährleisten,<br />
wird im Folgenden auf die englisch-deutsche Übersetzungsliste von Bernd<br />
Oestereich et.al. 1 zurückgegriffen, der sich zahlreiche Autoren und Verlage angeschlossen<br />
haben. Diese haben sich zur Verwendung der enthaltenen Namensgebung in ihren<br />
aktuellen und zukünftigen Veröffentlichungen verpflichtet.<br />
3.2 Metamodell<br />
Die Metamodellierung ist ein grundlegendes Konzept der UML und unabdingbar für ihr<br />
Verständnis. Ein Metamodell ist die Abstraktion eines konkreten Modells durch eine Instanz-Typ-Relation.<br />
Dieser Abstraktionsvorgang ist beliebig häufig wiederholbar, das<br />
Metamodell des einen Modells kann zugleich konkrete Ausprägung eines Meta-<br />
Metamodells sein.<br />
1 http://www.jeckle.de/uml.de
Metamodell<br />
Um die Interoperabilität zwischen Metamodellen oder allgemeinen Metadaten zu gewährleisten,<br />
stellt die „Meta Object Facility“ (MOF) [OMG06b] ein Rahmenwerk zur Verfügung,<br />
das als Grundlage für die Entwicklung von modell- und metadatengestützten Systemen<br />
dient. Zum Grundkonzept der MOF gehören das Objekt, die Klasse und die Navigierbarkeit<br />
einer Instanz zu seiner Klasse. Damit lassen sich beliebig viele Metaebenen<br />
beschreiben, mindestens jedoch zwei (repräsentiert durch die Instanz- und Klassenebene).<br />
Seit 1997 mit der Version 1.1 ist die UML-Spezifikation ein MOF-Modell und in eine<br />
Vier-Ebenen Hierarchie eingebettet, die mit M0 bis M3 nummeriert sind. Die MOF steht<br />
als Meta-Metamodell (M3) an deren Spitze, darunter bilden Sprachenspezifikationen die<br />
Metaebene (M2). Die UML-Spezifikation ist eine davon, das „Common Warehouse Model“<br />
(CWM) eine weitere. Die Benutzerspezifikationen bzw. die Benutzermodelle (M1)<br />
ordnen sich auf der Modellebene ein, während Laufzeit-Instanzen die sog. Objektebene<br />
(M0) darstellen. Abbildung 11 stellt die vier Ebenen in einem Beispiel dar.<br />
M3<br />
(MOF)<br />
M2<br />
(UML)<br />
M1<br />
(Benutzermodell)<br />
M0<br />
(Laufzeit-Instanzen)<br />
Class<br />
<br />
<br />
Attribute Class Instance<br />
<br />
Video<br />
+Titel: string<br />
<br />
<br />
<br />
einVideo<br />
classifier<br />
:Video<br />
Titel=„Casablanca“<br />
Abbildung 11 Vier-Ebenen Hierarchie der UML, nach [OMG07b]<br />
<br />
Wie die deutsche Sprache in der deutschen Sprache beschrieben ist, so wird die UML in<br />
der UML beschrieben. Die Semantik eines UML-Modells wird durch das UML-<br />
Metamodell definiert, dies fördert das Verständnis und die Anschaulichkeit der Beschreibung.<br />
Dieses Konzept ist für den Vorwurf der informalen Semantik zuständig, da es kein<br />
rigoroses mathematisches Beschreibungsmittel darstellt wie ein ASM, Z, etc. Aus dem<br />
37
38<br />
Die Unified Modeling Language 2<br />
UML-Lager wird diesem Vorwurf mit zwei Argumenten begegnet. Zum einen verhindert<br />
das Metamodell nicht die Erstellung einer zusätzlichen vollständigen formalen Spezifikation.<br />
Auf der anderen Seite sei diese Erstellung ein sehr komplexes Unterfangen, ohne<br />
daraus bedeutende Vorteile zu gewinnen.<br />
3.3 Infrastructure<br />
Die Infrastructure [OMG07b] beschreibt die architektonische Grundlage der UML und<br />
besteht aus zwei Teilen, dem „Core“- und dem „Profiles“-Paket. Letzteres beschreibt<br />
Konzepte zur Erweiterung und Anpassung von Metamodellen. Das zentrale Gerüst der<br />
Infrastructure-Spezifikation stellt jedoch das Core-Paket dar. Dieses dient einem wichtigen<br />
Entwurfsziel der UML2, der Harmonisierung der Sprachenarchitekturen der UML<br />
und MOF.<br />
Dem wurde auf zweierlei Weise Rechnung getragen: Zum einen wurden Kernelemente<br />
beider Sprachen zusammengefasst und im „Core“ definiert. Das Paket stellt ein kompaktes<br />
und speziell auf Wiederverwendbarkeit ausgelegtes Metamodell dar. Andere Metamodelle<br />
können Teile des Core-Metamodells importieren, spezialisieren oder instanziieren.<br />
Nun basieren sowohl die MOF als auch die UML-Superstructure auf der Infrastructure-<br />
Spezifikation, deren Verwendung jedoch unterschiedlich ist, da sie auf verschiedenen<br />
Metaebenen (siehe Abbildung 11) angesiedelt sind. Die MOF importiert Infrastructure<br />
Metaklassen, die UML Superstructure enthält Instanzen dieser Klassen und fügt neue<br />
Eigenschaften hinzu. Damit stellt das Core-Paket das Kernstück der gesamten MOF-<br />
Hierarchie dar. Die Abbildung 12 illustriert diesen Umstand und zeigt die Abhängigkeit<br />
sowohl der Metasprachen UML und CWM als auch der Meta-Metasprache MOF und<br />
weiterer Profil-Erweiterungen vom Core-Paket.<br />
Abbildung 12 Die Rolle des „Core“-Pakets im MOF-Umfeld [OMG07b]
Superstructure<br />
Die zweite Harmonisierungsmaßnahme war die Sicherstellung, dass die UML eine MOF-<br />
Instanz ist. Jedes UML-Element ist die Instanz genau einer MOF-Klasse und die Instanz<br />
eines Infrastructure-Elements.<br />
Weiterhin beschreibt die Infrastructure nötige Metaklassen zur Erzeugung von Metamodellen.<br />
Dies geschieht durch Instanziierung der Metaklassen aus der Infrastructure, d.h.<br />
sie definiert Metaklassen zur Instanziierung von Elementen der UML, MOF, CWM und<br />
der Infrastructure-Klassen selbst. Sie besitzt damit die selbstbeschreibende Eigenschaft.<br />
Die MOF führt diese Instanziierungen durch, indem sie die Metaklassen der Infrastructure<br />
verwendet und ist damit auch selbstbeschreibend. Damit kann sie die Vier-Ebenen-<br />
Hierarchie nach oben abschließen, da sie alle Metaklassen enthält, um sich selbst zu definieren.<br />
3.4 Superstructure<br />
Für den Modellierer ist insbesondere das Superstructure-<strong>Dokument</strong> [OMG07a] von Bedeutung,<br />
da es die Klassen der M2-Ebene beschreibt. Diese können in Benutzermodellen<br />
instanziiert werden und mittels vorgegebener Notation graphisch angezeigt werden.<br />
Die Spezifikation beschreibt das Metamodell strukturiert anhand von 13 Diagrammtypen,<br />
die wiederum in sechs Struktur beschreibende Diagramme und sieben Verhaltensdiagramme<br />
geordnet sind (Abbildung 13). Der Modellierer kann somit verschiedene Sichten<br />
auf ein System beschreiben und die Diagrammtypen auswählen, die am besten geeignet<br />
erscheinen.<br />
Abbildung 13 UML2-Diagrammtypen, nach [JRH+04]<br />
39
40<br />
3.4.1 Diagrammtypen<br />
Die Unified Modeling Language 2<br />
Im Folgenden werden die Beschreibungsmöglichkeiten jeden Typs kurz erläutert, beginnend<br />
mit den Strukturdiagrammen.<br />
Das Klassendiagramm ist die meistgenutzte Modellsicht der UML. Der Aufbau eines<br />
Systems wird durch die Gesamtheit aller Klassen und der Beschreibung ihrer Beziehungen<br />
zueinander beschrieben. Neben den Strukturinformationen werden auch die Datentypen<br />
definiert.<br />
Das Objektdiagramm gibt eine konkrete Ausprägung eines Systems zur Laufzeit wieder.<br />
Es stellt eine Momentaufnahme zu einem Ausführungszeitpunkt dar.<br />
Das Paketdiagramm ermöglicht eine Strukturierung des Systems durch Bildung von Einheiten<br />
(von z.B. mehreren Klassen oder Komponenten). Durch eine beliebig tiefe Hierarchiebildung<br />
bleibt die Überschaubarkeit von komplexen Systemen erhalten.<br />
Das Kompositionsstrukturdiagramm ist in der UML2 neu hinzugekommen und wird auch<br />
als Architekturdiagramm bezeichnet. Damit wurde das „Capsule Collaboration Diagramm“,<br />
das im UML RT-Profil eingeführt wurde, in den Standard übernommen. Die<br />
Architektur bzw. der Aufbau eines Classifiers kann hiermit ähnlich der „Specification and<br />
Description Language“ (SDL) [ITU99] in hierarchischer Form spezifiziert werden.<br />
Das Komponentendiagramm stellt wie das Objektdiagramm das System zur Laufzeit dar,<br />
abstrahiert jedoch von Details und fokussiert Kommunikationsbeziehungen der einzelnen<br />
Komponenten.<br />
Das Verteilungsdiagramm verdeutlicht durch die Darstellung von Hard- und Softwarekomponenten<br />
deren Verteilung. Die Beziehungen zwischen den Hardwareknoten heben<br />
die möglichen Kommunikationswege hervor.<br />
Zur Verhaltsbeschreibung existieren folgende Diagramme in der UML:<br />
Das Aktivitätsdiagramm veranschaulicht Prozessabläufe durch eine zeitliche Verkettung<br />
von Einzelaktionen. Die Ablaufbedingungen sind durch eine Token-Semantik ähnlich der<br />
von Petrinetzen gegeben.
Superstructure<br />
Die Interaktionsdiagramme modellieren das Interaktionsverhalten von Objekten. Zur<br />
Betonung unterschiedlicher Aspekte stehen folgende fünf Diagrammtypen zur Verfügung:<br />
Das Sequenzdiagramm ist das meistgenutzte Interaktionsdiagramm und hebt die zeitliche<br />
Reihenfolge der Kommunikation zwischen Objekten hervor. Es besitzt alle relevanten<br />
Notationselemente der „Basic Message Sequence Charts (bMSC)“ [ITU96]. Das Kapitel<br />
3.6 widmet sich dem Sequenzdiagramm im Detail.<br />
Das Interaktionsübersichtsdiagramm ist neu in die UML2 hinzugekommen und gibt einen<br />
Überblick über den Kontrollfluss von Interaktionen. Es stellt eine Variante des Aktivitätsdiagramms<br />
dar und übernahm viele Konzepte der „High Level MSCs“ [ITU96].<br />
Das Kommunikationsdiagramm entspricht dem einfachen Sequenzdiagramm mit einer<br />
Betonung der Architektur und der inneren Struktur.<br />
Das Timingdiagramm wurde aus der Welt der Digitaltechnik neu hinzugenommen, es<br />
fokussiert die Zeit, Abläufe sind an einer Zeitachse aufgetragen.<br />
Der Anhang der Superstructure-Spezifikation enthält eine weitere optionale Darstellungsform<br />
für Interaktionen. In der Interaktionstabelle kann das Kommunikationsverhalten in<br />
tabellarischer Form aufgetragen werden.<br />
Das Anwendungsfalldiagramm (Use-Case-Diagramm) stellt Anwendungsfälle und die mit<br />
diesen in Verbindung stehenden externen Kommunikationsteilnehmer dar. Das System<br />
stellt eine Black-Box dar, dessen extern sichtbares Verhalten durch ein Statechart, ein<br />
Aktivitäts- oder ein Interaktionsdiagramm beschrieben werden kann.<br />
Das Statechart stellt eine Erweiterung der Mealy- und Moore-Automaten dar und geht auf<br />
Arbeiten von D. Harel [Har87] zurück. Kurz gefasst stellen Statecharts konventionelle<br />
Zustandsautomaten dar, die um drei Konzepte erweitert wurden.<br />
Das erste ist die Hierarchie, also die Möglichkeit, hierarchische Zustände in beliebiger<br />
Tiefe zu erstellen. Ein sog. zusammengesetzter Zustand kann also wiederum ein Statechart<br />
enthalten. Die Nebenläufigkeit stellt die zweite Erweiterung dar. Dies ermöglicht<br />
die Beschreibung von beliebig vielen nebenläufig agierenden Zustandsmaschinen. In der<br />
UML wird das Konzept durch „Regionen“ realisiert. In einer Region befindet sich genau<br />
ein Zustandsautomat, diese können in orthogonalen Zuständen zusammengesetzt werden<br />
und nebenläufig agieren. Das dritte neue Konzept sind erweitere Kommunikationsmöglichkeiten,<br />
insbesondere ein Broadcastmechanismus zwischen nebenläufigen Komponenten.<br />
41
42<br />
Die Unified Modeling Language 2<br />
Eine spezielle Variante ist der Protokoll-Zustandsautomat, der speziell zur Spezifikation<br />
von Kommunikationsprotokollen geeignet ist. Er beschreibt ausschließlich erlaubte Aufrufreihenfolgen<br />
von Operationen, was der einfachen Definition eines Protokolls entspricht.<br />
Der Protokollzustandsautomat unterscheidet sich von den Verhaltenszustandsautomaten<br />
in zwei Punkten. Protokollzustände können neben ihren Namen zusätzlich Invarianten<br />
enthalten, durch die sie definiert sind. Der zweite Unterschied ist das Fehlen jeglicher<br />
Aktivitäten in den Zuständen.<br />
Der Protokollzustandsautomat besteht also nur aus Zuständen, die durch Invarianten definiert<br />
sind, und aus Operationen, die durch Vor- und Nachbedingungen eingeschränkt<br />
sind. Abbildung 14 zeigt die Syntax der Protokolltransition.<br />
Abbildung 14 Protokolltransition<br />
3.5 XML Metadata Interchange (XMI)<br />
Die XMI ist das Austauschformat für Modelle der MOF und aller von ihr abgeleiteten<br />
Sprachen. Die Motivation war die Modellbeschreibung in einer herstellerunabhängigen<br />
Notation zum Austausch zwischen beliebigen UML-Werkzeugen. Sie ist von der OMG<br />
standardisiert und basiert auf der „Extensible Markup Language“ (XML) [W3C04a]. Mit<br />
Hilfe der XML lassen sich beliebige hierarchische Auszeichnungssprachen beschreiben,<br />
so sind z.B. die Namen der „Tag“-Bezeichner, deren Anordnung oder die Wertebereiche<br />
von Daten frei wählbar.<br />
Um einen sinnvollen Datenaustausch mit einer XML-Sprache zu ermöglichen, ist es notwendig,<br />
diese Freiheiten einzuschränken und eine Grammatik zu definieren, die für einen<br />
bestimmten Anwendungszweck „gültige“ <strong>Dokument</strong>e beschreibt. Das „World Wide Web<br />
Consortium“ (W3C) sieht für deren Definition zwei Möglichkeiten vor, mit einer „Document<br />
Type Definition“ (DTD) [W3C04a] oder mit einem XML-Schema [W3C04b]. Für<br />
eine Diskussion der Vorteile letzterer und der konzeptuellen Unterschiede sei auf umfangreiche<br />
XML-Literatur hingewiesen [W3C04b, BDD+01].<br />
Da die XMI als Austauschformat für alle auf MOF basierenden Sprachen konzipiert ist,<br />
enthält deren Spezifikation zwei Teile:<br />
- Produktionsregeln zur Erzeugung von XML-DTDs bzw. XML-Schematas aus<br />
XMI-kodierten Metadaten
XML Metadata Interchange (XMI)<br />
- Produktionsregeln zur Erzeugung von XML-<strong>Dokument</strong>en, um Metadaten in einem<br />
XMI-kompatiblen Format zu kodieren<br />
Abbildung 15 XMI in der Vier-Ebenen-Hierarchie, nach [Jec04]<br />
Abbildung 15 zeigt die XMI in der 4-Ebenen-Hierarchie der UML. Auf jeder Ebene kann<br />
nach der XMI-Spezifikation ein XML-Schema erzeugt werden. Diese können zur Konformitätsprüfung<br />
der XML-<strong>Dokument</strong>e verwendet werden, in denen die Modelle serialisiert<br />
sind.<br />
Versionen<br />
Die erste finale Version der XMI wurde im Jahre 2000 für die MOF 1.1 verabschiedet.<br />
Die XMI 1.0 verzichtete fast gänzlich auf den Gebrauch von XML-Attributen. Die XMI<br />
1.1 machte von ihnen stärker Gebrauch und führte die XML-Namespaces ein. Bis zur<br />
XMI-Version 1.2, die für die MOF 1.4 aktualisiert wurde, wurden ausschließlich Produktionsregeln<br />
für DTDs beschrieben. 2003 wurde mit der XMI 1.3 die Schema-<br />
Unterstützung nachgereicht. Im gleichen Zeitraum wurde das <strong>Dokument</strong>enformat stark<br />
überarbeitet und inklusive Schema-Unterstützung der Versionssprung auf die 2.0 vollzogen<br />
[OMG05c].<br />
43
44<br />
Die Unified Modeling Language 2<br />
Für die MOF 2.0, welche das Metamodell der UML2 ist, wurde die XMI wiederum bezüglich<br />
Struktur und Lesbarkeit überarbeitet. Anfangs bezeichnete man diese Version als<br />
„XMI 2.0 für MOF 2.0“, was jedoch zur Verwechslung mit der früheren Fassung führte.<br />
Die erste MOF 2.0 (und damit UML2) kompatible Version ist die XMI 2.1 [OMG05d].<br />
3.6 Sequenzdiagramme<br />
Die UML2 definiert Konzepte zur Beschreibung von Interaktionen, d.h. für die Kommunikation<br />
von Instanzen, die ihrerseits Verhalten realisieren. Interaktionen sind im Allgemeinen<br />
sowohl für Systementwickler als auch für Endnutzer verständlich, sie finden daher<br />
in vielen Entwicklungsphasen Verwendung. Von abstrakt gehaltenen Situationsbeschreibungen<br />
bis hin zur Darstellung präziser Interprozesskommunikation oder der Aufzeichnung<br />
einer Ablaufspur werden Interaktionsbeschreibungen für verschiedene Ziele<br />
eingesetzt.<br />
Je nach Situation und Kontext sind gewisse Interaktionskonzepte von besonderer Bedeutung<br />
oder im Gegenteil vernachlässigbar. Aus diesem Grund stehen dem Modellierer fünf<br />
Diagrammtypen zur Verfügung, um die relevanten Teilaspekte zu verdeutlichen. Eine<br />
Auflistung dieser Diagrammformen inklusive einer Kurzbeschreibung findet sich in Kapitel<br />
3.4.1. Dieser Abschnitt beschreibt das Sequenzdiagramm, den wichtigsten und umfangreichsten<br />
Vertreter zur Beschreibung von Interaktionen.<br />
Das Sequenzdiagramm ist die am stärksten überarbeitete und erweiterte Diagrammart der<br />
neuen UML-Version. Ein großes Manko der UML-1.x-Sequenzdiagramme war ihre Ausdrucksschwäche<br />
durch das Fehlen wichtiger Konzepte. Sie konnte sich daher nie gegen<br />
die „Message Sequence Charts“ (MSC) [ITU96] durchsetzen, die im Bereich der Telekommunikation<br />
eine etablierte Spurenbeschreibungssprache ist. In der überarbeiteten<br />
Version der Sequenzdiagramme sind nun alle relevanten Elemente der MSCs hinzugefügt<br />
worden. Ein Vorteil der ITU-Sprache bleibt jedoch weiterhin ihre vollständig formale<br />
Grammatik.<br />
Ein Sequenzdiagramm beschreibt eine Spur, d.h. eine Folge von Ereignissen. Diese Spur<br />
kann eine erlaubte oder eine verbotene Abfolge von Ereignissen des beschriebenen Systems<br />
sein. Die Vereinigungsmenge der legalen und illegalen Spuren beschreibt die Interaktionssemantik,<br />
sie umfasst jedoch nicht notwendigerweise die Gesamtheit aller möglichen<br />
Interaktionen. Über nicht beschriebene Spuren kann keine Aussage getroffen werden,<br />
sie können sowohl legale als auch nicht legale Ereignisabfolgen darstellen. Zwei
Sequenzdiagramme<br />
Interaktionen sind dann äquivalent, wenn ihre Menge der legalen und illegalen Spuren<br />
gleich sind.<br />
Die Spuren besitzen eine „Interleaving“-Semantik, d.h. bei der Vereinigung zweier oder<br />
mehrerer Spuren bleibt die Reihenfolge der Ereignisse pro Spur erhalten, die Ereignissequenz<br />
verschiedener Spuren ist unbestimmt. Wichtig ist das Fehlen „echter“ Parallelität,<br />
Ereignisse treten immer sequentiell auf. Die Beschreibung einer Quasi-Parallelität ist<br />
durch die Angabe aller möglichen Reihenfolgen möglich.<br />
Eine Spur beschreibt ohne Verwendung erweiterter Elemente eine partielle Ordnung der<br />
Ereignisse, d.h. es sind nur zwei Aussagen über die Ereignis-Reihenfolge erlaubt:<br />
Entlang jeder Lebenslinie sind Ereignisse strikt geordnet und der Empfang einer Nachricht<br />
erfolgt stets nach deren Versenden. Aussagen darüber hinaus sind nicht möglich. Zur<br />
Beschreibung alternativer Ordnungen ebenso wie zur Kontrollflusssteuerung stellt die<br />
UML Beschreibungsmöglichkeiten zur Verfügung, sog. „Kombinierte Fragmente“. In<br />
[HHR+05] findet sich eine genaue Betrachtung der Spurensemantik der Sequenzdiagramme<br />
inklusive ihrer kombinierten Fragmente.<br />
Kombinierte Fragmente<br />
Interaktionsfragmente, d.h. Ausschnitte einer Interaktion, können unterschiedlich miteinander<br />
kombiniert werden. Die Fragmente stellen die Operanden dar, ein Operator bestimmt<br />
die Art der Kombination.<br />
Die UML2 definiert folgende Operatoren:<br />
• Die lose Ordnung („weak sequencing“) entspricht der partiellen Ordnungsrelation,<br />
d.h. es sind lediglich zwei Aussagen über die Ereignisreihenfolge möglich: (1) ein<br />
Sendeereignis findet immer vor dem korrespondierenden Empfangsereignis statt,<br />
(2) entlang einer Lebenslinie sind die Ereignisse zeitlich von oben nach unten geordnet.<br />
Die lose Ordnung kann explizit angegeben werden, bei Fehlen jeglichen<br />
Operators gilt sie implizit.<br />
• Die strenge Ordnung („strict sequencing“) modelliert einen chronologischen Ablauf<br />
der Ereignisse, der durch ihre vertikale Position gegeben ist. Diese bestimmen<br />
die Ereignisreihenfolge bezüglich des gesamten kombinierten Fragments, nicht<br />
nur auf einer Lebenslinie.<br />
45
46<br />
Die Unified Modeling Language 2<br />
• Ein paralleles Fragment („par“) stellt die parallele Verschmelzung dar und entspricht<br />
einer Verschränkung der Operanden. Die Ereignisse verschiedener Operanden<br />
können in beliebiger Reihenfolge auftreten, die zeitliche Ordnung innerhalb<br />
der Operanden bleibt von der Verschränkung unberührt, d.h. ohne weitere<br />
Angabe eines Operators gilt die standardmäßig geltende lose Ordnung. Beschränken<br />
sich die Ereignisse, für die die zeitliche Reihenfolge nicht signifikant ist, auf<br />
eine Lebenslinie, dann gibt es als graphische Kurznotation die Coregion. Jede Coregion<br />
kann demnach auch als paralleles Fragment dargestellt werden, indem jedes<br />
Ereignis der Coregion als eigener Operand eines parallelen kombinierten<br />
Fragments dargestellt wird.<br />
• Die Alternative („alt“) stellt den Auswahloperator dar, der nach Auswertung der<br />
explizit bzw. implizit gegebenen Bedingungen maximal einen Operanden auswählt.<br />
• Das optionale Fragment („opt“) stellt ein mögliches Verhalten dar und entspricht<br />
semantisch einem alternativen Fragment mit nur einem Operanden.<br />
• Das Abbruchfragment („break“) stellt zwei alternative Fragmente dar, mit der<br />
Auswahl zwischen der Fortsetzung ohne Durchführung des Abbruchfragments,<br />
oder das Ausführen des Abbruchfragments und anschließendem Beenden des umschließenden<br />
Fragments.<br />
• Die Schleife („loop“) bezeichnet die Wiederholung des Fragments, deren Anzahl<br />
unbeschränkt oder durch eine untere und obere Schranke angegeben wird. Zudem<br />
kann ein boolscher Ausdruck definiert werden, der nach Erreichen der unteren<br />
Schranke vor jeder weiteren Iteration ausgewertet wird. Die einzelnen Schleifendurchgänge<br />
sind mit einer losen Ordnung verbunden.<br />
• Mittels der Negation („neg“) werden illegale Spuren beschrieben, d.h. der beschrieben<br />
Ablauf ist nicht erlaubt.<br />
• Der kritische Bereich („critical“) enthält eine Interaktion, die nicht verschränkbar<br />
ist, d.h. die enthaltene Spur muss atomar behandelt werden<br />
• Der Operator zum Ignorieren („ignore“) enthält eine Liste von Nachrichten, die<br />
im Operanden nicht aufgeführt sind. Der UML-Standard beschreibt zwei unter-
Sequenzdiagramme<br />
schiedliche Semantiken. Entweder gelten diese Nachrichten als unwichtig, was ihre<br />
Ignorierung beim etwaigen Auftreten zur Folge hat. Alternativ kann dies bedeuten,<br />
dass die Nachrichten in der Spur zu jedem Zeitpunkt auftreten können.<br />
• Für relevante Nachrichten („consider“) kann eine Liste an Nachrichten erstellt<br />
werden, die von Bedeutung sind. Der Operator stellt das Gegenstück zum letztgenannten<br />
dar und ist äquivalent zu einer „ignore“-Liste aller nicht aufgeführten<br />
Nachrichtentypen.<br />
• Die Sicherstellung („assert“) betont die enthaltene Interaktion als einzig erlaubte<br />
Fortsetzung der Spur, jede andersartige Ereignisabfolge ist illegal.<br />
Weitere wichtige Konzepte<br />
• Um zwei Ereignisse explizit in eine zeitliche Relation zu setzen, kann eine binäre<br />
Ordnungsbeziehung („general ordering“) festgelegt werden. Der Pfeilkopf innerhalb<br />
der gepunkteten Linke zeigt vom zeitlich früheren zum später auftretenden<br />
Ereignis. Abbildung 16 beschreibt das Versenden der Nachricht „m1“ vor der<br />
Nachricht „m2“.<br />
Abbildung 16 Ordnungsbeziehung<br />
Die folgenden zwei Konzepte dienen der besseren Übersichtlichkeit und unterstützen die<br />
Wiederverwendbarkeit wiederholender Interaktionsfragmente.<br />
• Die Interaktionsreferenz („interaction use“) substituiert eine Interaktion durch ihre<br />
Referenz. Eine Interaktion kann an mehreren Stellen referenziert werden und bildet<br />
durch die mögliche Angabe von Ein- und Ausgabeparametern einen synchronen<br />
Operationsaufruf nach. Abbildung 17 referenziert das Sequenzdiagramm<br />
„Login“ und setzt an dessen Ende mit der Nachricht „m1“ fort.<br />
47
48<br />
Abbildung 17 Interaktionsreferenz<br />
Die Unified Modeling Language 2<br />
• Die Verwendung von Sprungmarken („continuation“) ist nur in alternativen<br />
Fragmenten erlaubt. Sie stellen eine syntaktische Möglichkeit dar, Operanden an<br />
beliebiger Stelle fortzusetzen. Startmarken befinden sich an letzter, Zielmarken an<br />
erster Stelle eines Operanden, wobei mehrere Start- auf eine Zielmarke weisen<br />
dürfen.<br />
• Der Dekompositionsoperator („part decomposition“) beschreibt eine Lebenslinie<br />
mit einer internen Struktur. So kann durch die Zerlegung einer Lebenslinie die innere<br />
Kommunikation beschrieben werden. Die Abbildung 18 links beschreibt einen<br />
Nachrichtenaustausch mit einer Systeminstanz, welche aus mehreren Lebenslinien<br />
des „Zugangsmoduls“ besteht (siehe Abbildung 18 rechts).<br />
Abbildung 18 Dekomposition<br />
• Zustandsinvarianten („state invariant“) werden auf Lebenslinien platziert und beschreiben<br />
Bedingungen, die von den Kommunikationspartnern zur Laufzeit geprüft<br />
werden. Die Auswertung findet unmittelbar vor dem Auftreten des nächsten<br />
Ereignisses statt. Wird die Bedingung erfüllt, so gilt die Spur als erlaubt, eine unerfüllte<br />
Bedingung kennzeichnet die sie enthaltende Spur als unerlaubt. Für die
Sequenzdiagramme<br />
Zustandsinvarianten sind drei Notationsmöglichkeiten vorgegeben, in einem angehefteten<br />
Notizfeld, als boolesche Bedingung in geschweiften Klammern und in<br />
einem Zustandssymbol. Letzteres entspricht der Überprüfung des (internen oder<br />
extern sichtbaren) Zustands des Objekts, welches durch die Lebenslinie dargestellt<br />
wird. Abbildung 19 zeigt exemplarisch die zwei letztgenannten Darstellungsformen<br />
von Zustandsinvarianten.<br />
Abbildung 19 Zustandsinvarianten<br />
• Der Ausführungsfocus („execution occurrence“) beschreibt die Ausführung eines<br />
Verhaltens oder einer Aktion auf einer Lebenslinie. Typischerweise korrespondiert<br />
der Empfang bzw. das Senden einer Nachricht mit dem Start bzw. Ende einer<br />
Ausführungsspezifikation. Dargestellt wird er als ein dünnes Rechteck auf der Lebenslinie,<br />
wie Abbildung 20 beispielhaft zeigt. Alternativ kann das Rechteck breiter<br />
ausfallen, um die ausgeführte Aktion darin zu benennen.<br />
Abbildung 20 Ausführungsfocus<br />
49
50<br />
3.7 UML Profile<br />
Die Unified Modeling Language 2<br />
Die UML besitzt Erweiterungsmechanismen, die es erlauben, dem Metamodell neue Elemente<br />
hinzuzufügen, um dieses den eigenen Anforderungen anzupassen. Der Wunsch<br />
bzw. die Notwendigkeit kann aus mehreren Gründen entstehen. Dies kann die Anpassung<br />
der Terminologie an eine Zielumgebung sein, das Hinzufügen spezieller Notationssymbole<br />
oder die Konkretisierung ungenügend spezifizierter Semantik. Ein weiterer häufiger<br />
Verwendungszweck ist die Beschränkung der Anwendung existierender Konzepte bzw.<br />
des gesamten Metamodells.<br />
Explizit verboten ist die Modifizierung existierender Metamodelle durch Veränderung<br />
von Metaklassen oder durch das Entfernen vorhandener Einschränkungen. Die UML besitzt<br />
damit ein sog. leichtgewichtiges Erweiterungskonzept.<br />
Erweiterungen für eine bestimmte Anwendungsdomäne oder einen Anwendungszweck<br />
werden in Profilen zusammengefasst, die eine Referenz enthalten müssen, auf welches<br />
Metamodell sie Bezug nehmen. Die konkreten Erweiterungen werden mit Hilfe folgender<br />
dreier Konzepte beschrieben: Stereotypen, Eigenschaftswerten („tagged values“) und<br />
Einschränkungen („constraints“).<br />
Wie alle Konzepte waren auch diese Überarbeitungen unterworfen. In der UML 1.x waren<br />
sie als textbasierte Elementannotationen sehr flexibel anwendbar. In der UML2 fand<br />
eine Präzisierung statt, die Profil-Metaklasse erbt nun die Eigenschaften der Paket-Klasse,<br />
für Stereotypen existiert eine Metaklasse, und Eigenschaftswerte stellen ausschließlich<br />
(Meta-)Attribute dieser Stereotyp-Metaklassen dar. Beispiele für die Anwendung von<br />
Stereotypen mit Eigenschaftswerten finden sich in Abbildung 28 bis Abbildung 31.<br />
3.7.1 UML Profile for Schedulability, Performance and Time<br />
Das „UML Profile for Schedulability, Performance and Time Specification“ (SPT)<br />
[OMG05b] ist ein Profil für das UML-1.x-Metamodell und enthält leichtgewichtige Erweiterungen<br />
für die Echtzeit-Domäne. Die im Jahre 2003 erstmals erschienene OMG-<br />
Spezifikation dient der Beschreibung verschiedener Zeit- und Leistungsaspekte und von<br />
Zuteilbarkeitseigenschaften.<br />
Zielsetzung des Profils war die Definition einer standardisierten und damit einheitlichen<br />
Notation von zeitbezogenen Eigenschaften, um die Kommunikation zwischen Entwick-
UML Profile<br />
lern zu erleichtern und den einfachen Datenaustausch zwischen Werkzeugen zu ermöglichen.<br />
In der Anwendung bedeutet dies konkret, dass der Modellierer zur Beschreibung von Zeit<br />
und Nebenläufigkeit im System auf Annotationen des Standards zurückgreifen soll. Dies<br />
ermöglicht Analysetools, die Modelle zu lesen und quantitativ auszuwerten. Die Spezifikation<br />
beschränkt sich nicht auf eine bestimmte Analysemethode, sondern stellt Elemente<br />
für allgemeine Konzepte zur Verfügung, die es für existierende und kommende Techniken<br />
nutzbar machen sollen.<br />
Abbildung 21 zeigt den modularen Aufbau des Profils. Erweiterungen für verschiedene<br />
Aspekte wie die Modellierung von Zeit und Nebenläufigkeit wurden getrennt und bilden<br />
ihrerseits eigene Subprofile. Dies ermöglicht die spezifische Nutzung nur einer Untermenge<br />
des Profils.<br />
Abbildung 21 SPT-Profil Struktur [OMG05b]<br />
51
52<br />
Die Unified Modeling Language 2<br />
Die zwei genannten Profile und das Subprofil zur Ressourcen-Modellierung bilden zusammen<br />
das „General Resource Modeling Framework“, welches die grundlegenden Modellierungselemente<br />
für Echtzeitsysteme anbietet. Zentrales Element ist die Ressource,<br />
die Dienste mit bestimmten Dienstgütemerkmalen anbietet. Dem gegenüber steht der<br />
Klient, der diese Angebote in Anspruch nimmt und diverse Dienstgüte-Parameter verlangt.<br />
Die zweite Paketgruppierung besteht aus Subprofilen für analytische Methoden. Das<br />
„Schedulability Analysis“ (SA) Profil enthält Stereotypen, Eigenschaftswerte und Einschränkungen<br />
für allgemeine Analysemethoden der Zuteilbarkeit, das PA-Profil für Verfahren<br />
der Leistungsbewertung. Das RSA-Profil spezialisiert das SA-Profil hinsichtlich<br />
Echtzeit-CORBA-Anwendungen. Das dritte übergeordnete Paket des SPT-Profils enthält<br />
eine Modellbibliothek. Es stellt ein Infrastrukturmodell von Echtzeit-CORBA dar.<br />
In dieser Arbeit sind insbesondere Annotationen des Zeit- und des Leistungsprofils relevant,<br />
diese werden im Folgenden näher betrachtet. Die Konzepte des Zeit-Subprofils sind<br />
in folgende Pakete unterteilt:<br />
Abbildung 22 SPT - Time Modeling [OMG05b]<br />
Das „TimeModel“-Paket beschreibt die physikalische Zeit als das kontinuierliche und<br />
unbegrenzte Fortschreiten von Zeitpunkten. Diese unterliegen einer totalen Ordnung und<br />
bilden eine dichte Menge, d.h. zwischen zwei beliebigen Zeitpunkten liegt immer mindestens<br />
ein weiterer. Der Übergang zur technischen Welt findet durch Messung dieser Zeitpunkte<br />
und einer Abbildung auf Zeitwerte (dicht oder diskret) statt.<br />
Alle Zeitwerte besitzen eine Referenzuhr, die im Paket „TimingMechanisms“ beschrieben<br />
ist. Das Profil definiert zwei Zeitmechanismen, die Uhr und den (periodischen oder nicht
UML Profile<br />
periodischen) Timer. Beide besitzen spezifische Eigenschaften wie einen aktuellen oder<br />
maximalen Zeitwert, eine bestimmte Auflösung oder eine Drift, d.h. die Abweichungsrate<br />
gegenüber der Referenzuhr.<br />
Das Paket „TimedEvents“ führt Stimuli und Ereignisse ein, die zu einem bestimmten<br />
Zeitpunkt auftreten. Dazu lassen sie sich mit einem Zeitstempel assoziieren. Zusätzlich<br />
führt das Paket die „TimedAction“ ein, eine Aktion mit Start- und Endzeit zur Beschreibung<br />
einer Aktionsdauer. Hiermit lassen sich auch Verzögerungszeiten modellieren.<br />
Das letzte Paket „TimingService“ stellt ein Konzept zur Verfügung, um zeitbezogene<br />
Dienste zu beschreiben, wie sie z.B. in Echtzeitbetriebssystemen vorhanden sind. Das<br />
Konzept dient zum flexiblen Umgang mit Zeitmechanismen.<br />
Das Performance-Subprofil definiert verschiedene Anwendungsbereiche. Es dient zum<br />
Erfassen von Leistungsanforderungen und zur Beschreibung von Leistungseigenschaften<br />
ausgewählter Modellelemente. Weiterhin können annotierte Ausführungsparameter die<br />
Berechnung der Systemleistung unterstützen. Zusätzlich eignet sich das Profil zur reinen<br />
Darstellung errechneter oder gemessener Werte.<br />
Der Analysekontext, in dem Leistungsmerkmale von Interesse sind, wird als Zusammenspiel<br />
aus Ressourcen, der Arbeitslast, die auf sie einwirkt, und Performance-Szenarien<br />
beschrieben.<br />
Abbildung 23 SPT - Performance Modeling [OMG05b]<br />
53
54<br />
Die Unified Modeling Language 2<br />
Abbildung 23 listet alle Beschreibungselemente inklusive ihrer Beziehungen zueinander<br />
auf. Für die Last kann die Antwortzeit der Ressource, d.h. die Ausführungsdauer des Szenarios,<br />
angegeben werden, die durch die Workload getriggert wird. Eine Prioritätsangabe<br />
ist ebenso vorgesehen. Zudem unterscheidet der Standard nach offener und geschlossener<br />
(gleich bleibende Last im Gesamtsystem) Workload mit folgenden Attributen: es können<br />
die Populationsgröße (z.B. Paketanzahl), ein Verzögerungswert zwischen der Ausführung<br />
zweier Szenarien und ein Muster für die Zwischenankunftszeiten spezifiziert werden.<br />
Zur Beschreibung der beteiligten Ressourcen stehen dem Modellierer die Eigenschaften<br />
Auslastung, Durchsatz und das Zugriffsverfahren zur Verfügung. Unterschieden wird<br />
zwischen aktiven und passiven Ressourcen, wobei erstere Server mit Bedienzeiten darstellen<br />
wie z.B. Prozessoren. Passive Ressourcen werden während einer Szenarienausführung<br />
in Anspruch genommen und besitzen Wartezeiten. Typische Attribute aktiver Ressourcen<br />
sind die Angabe eines Geschwindigkeitsfaktors, die Zeitangabe für den Kontextwechsel,<br />
die Angabe der Prioritätsstufen und ob präemptive Verfahren unterstützt werden.<br />
Für passive Ressourcen stehen folgende Attribute zur Verfügung: Die Wartezeit bis zur<br />
Gewährung des Zugriffs, die Antwortzeit (die Zeit von der Anforderung bis zum Lösen<br />
des Ressourcenzugriffs), ihre Kapazität und die Zugriffszeit.<br />
Zudem enthält ein Performancekontext mindestens ein Szenario, um eine dynamische<br />
Situation zu beschreiben, die bezüglich Leistungsparametern von Interesse sind. Das Szenario<br />
kann mit der Ausführungszeit und seiner Gesamtanforderung bezüglich Ressourcen<br />
annotiert werden. Ein Szenario ist eine Sequenz von zeitlich geordneten Einzelschritten.<br />
Diese können folgende Eigenschaften besitzen: Die Ausführungswahrscheinlichkeit im<br />
Vergleich zu alternativen Schritten, die Anzahl der Wiederholungen und eine Verzögerungszeit<br />
innerhalb des Einzelschrittes. Weiter stehen die Angabe der ausgeführten Operation,<br />
das Zeitintervall zwischen zwei Wiederholungen und die Verzögerungszeit zur<br />
Ausführung des Schrittes zur Auswahl.<br />
Die Syntax zur Angabe komplexerer Leistungsparameter ist durch eine BNF-Notation<br />
vorgegeben. Die allgemeine Form der Eigenschaftswerte lautet:<br />
mit<br />
“(“ “,” “,” “)”<br />
::= ‘req’ | ‘assm’ | ‘pred’ | ‘msr’
UML Profile<br />
::= ‘mean’ | ‘sigma’ | ‘kth-mom’ , | ‘max’ |’percentile,’ | ‘dist’<br />
::= ( | | | < metricTimeStr> ) [“,” ]<br />
Neben den eigentlichen Werten sieht der Standard zwei Attribute für Performance-<br />
Annotationen vor. Das erste gibt die Quelle an, d.h. ob es sich um einen geforderten, geschätzten,<br />
vorausberechneten oder gemessenen Wert handelt. Das zweite beschreibt den<br />
Typ bzw. die statistische Bedeutung der angegebenen Größe. Es kann sich hierbei um den<br />
Mittelwert, die Varianz, das k-te Moment, das Maximum oder um eine Perzentilangabe<br />
handeln. Zudem ist die Syntax zur Definition von neun Standard-Verteilungsfunktionen<br />
angegeben. Die Syntax der Zeitwerte ist in Abbildung 24 zusammengefasst, Beispieldeklarationen<br />
mit dem SPT-Profil finden sich in Kapitel 4.1.2 mit der Abbildung 28 bis<br />
Abbildung 31.<br />
::= [“:” [“:” [“:” ] ] ]<br />
::= “00”..”23”<br />
::= “00”..”59”<br />
::= “00”..”59”<br />
::= “00”..”99”<br />
::= “/” “/” <br />
::= “0000”..”9999”<br />
::= “01”..”12”<br />
::= “01”..”31”<br />
::= “Mon” | “Tue” | “Wed” | “Thr” | “Fri” | “Sat” | “Sun”<br />
::= “(“ [ | ] “,” ”)”<br />
::= | <br />
::= “ ’ns’ ”|“ ’us’ ”|“ ’ms’ ”|“ ’s’ ”|“ ’hr’ ”|“ ’days’ ”|“ ’wks’ ”|“ ’mos’ ”|“ ’yrs’<br />
::= ‘TAI’ | ‘UT0’ | ‘UT1’ | ‘UTC’ | ‘TT’ | ‘TDB’ | ‘TCG’ | ‘TCB’ | ‘Sidereal’ |<br />
‘Local’ | <br />
::= “(“ | | | |<br />
| | | | “,” ”)”<br />
3.7.2 UML Profile MARTE<br />
Abbildung 24 Syntax der Zeitwerte<br />
Seit dem Jahre 2005 existiert ein „Request for Proposal“ (RfP) für eine Nachfolgeversion<br />
des SPT-Profils, das Profil MARTE („Modeling and Analysis of Real-Time and Embedded<br />
systems“) [OMG05e].<br />
Das SPT-Profil war die erste UML-Erweiterung zur Beschreibung von Echtzeiteigenschaften.<br />
In den ersten zwei Jahren nach Verabschiedung des SPT-Profils im Jahre 2003<br />
hat sich eine große Liste an Veränderungswünschen angesammelt. Diese rühren teilweise<br />
aus praktischen Erfahrungen im Umgang mit dem SPT-Profil her, teilweise haben sich<br />
55
56<br />
Die Unified Modeling Language 2<br />
andere OMG-Standards wie die MOF und die UML weiterentwickelt, die einen Einfluss<br />
auf das Echtzeitprofil haben. Der Anhang in [OMG05e] enthält eine Liste größerer Änderungswünsche<br />
und nötiger Verbesserungen für das SPT-Profil.<br />
Die zuständige Arbeitsgruppe, die sog. „Revision Task Force“ für die Pflege und Fehlerkorrektur<br />
des SPT-Profils kommt im Jahre 2004 zu der Erkenntnis, dass die gewünschten<br />
Änderungen zu gravierend für eine einfache Versions-Inkrementierung seien.<br />
Einreichungen für das MARTE-Profil sollen die erstellte Verbesserungsliste berücksichtigen,<br />
dabei jedoch kompatibel zum SPT-Profil bleiben bzw. Regeln für ein Mapping<br />
bereitstellen. Zusätzlich sollen Vorschläge in Einklang mit den neuesten OMG-Standards<br />
stehen, insbesondere mit der MOF, UML und der XMI in den Versionen 2.0 bzw. 2.1.<br />
Konkret soll MARTE folgende Punkte berücksichtigen: Erstens sollen verbesserte Modellierungsmöglichkeiten<br />
für Software- und Hardware-Aspekte angeboten werden. Zur Unterstützung<br />
der MDA [OMG03] (siehe Kapitel 2.2.4) sollen plattformspezifische und<br />
plattformunabhängige Modellsichten unterstützt werden. Des Weiteren sieht das Profil<br />
nicht nur Echtzeitanforderungen vor, es soll die Modellierung allgemeiner Quality-of-<br />
Service-Eigenschaften eingebetteter Systeme unterstützen. Dazu gehören u.A. Speichergrößen<br />
und der Energieverbrauch. Außerdem betreffen MARTE-Erweiterungen komponentenbasierte<br />
Architekturen und unterstützen die Modellierung von asynchronen, synchronen<br />
und realen Zeitmodellen.<br />
Das MARTE-RfP fordert explizit die Gliederung in drei Subprofile, ähnlich den Subprofilen<br />
des SPT-Profils (siehe Abbildung 25).<br />
Abbildung 25 MARTE – Subprofile [OMG05e]
UML Profile<br />
Das TCR-Subprofil entspricht dem GRM-Framwork des SPT-Profils (siehe Abbildung<br />
21), es soll demnach die grundlegenden Modellierungskonstrukte für allgemeine Ressourcen,<br />
Zeit und Nebenläufigkeit enthalten.<br />
Das SPA-Subprofil ist vergleichbar mit dem Paket „Analysis Models“ im SPT-Profil und<br />
ist für Konzepte zur Beschreibung von Leistungs- und Zuteilbarkeitseigenschaften vorgesehen.<br />
Im RTEM-Paket werden neue Anforderungen und Kategorien zusammengefasst, die die<br />
Modellierung von eingebetteten Systemen unterstützen.<br />
Das UML2-konforme MARTE-Profil ist jedoch noch nicht verabschiedet worden, eine<br />
erste Betaversion wurde im August 2007 freigegeben [OMG07c]. In dieser Arbeit fand<br />
das SPT-Profil in Kombination mit der UML2 Verwendung. Obwohl dies formal nicht<br />
korrekt ist, da das Profil explizit für die UML 1.x entwickelt wurde, lassen sich die Konzepte<br />
in dem hier benötigten Umfang problemlos auch auf die Nachfolgeversion anwenden.<br />
Dies liegt insbesondere am einfachen Annotationskonzept, Anweisungen innerhalb<br />
von Anmerkungsfeldern an UML Elemente zu binden. Diese Möglichkeit besteht auch in<br />
der UML2.<br />
3.7.3 UML Testing Profile<br />
Das UML2 Testing Profile (U2TP) [OMG05a] erweitert die UML2 um testspezifische<br />
Beschreibungsmöglichkeiten. Es definiert eine Sprache für den Entwurf, die Visualisierung,<br />
die Spezifikation, die Analyse, den Aufbau und die <strong>Dokument</strong>ation von Bestandteilen<br />
eines Testsystems.<br />
Die enthaltenen Konzepte sind in vier logische Gruppen unterteilt. Die „test architecture“<br />
enthält Erweiterungen zur Definition der Teststruktur und der Testkonfiguration. Neben<br />
Stereotypen zur Kennzeichnung des zu testenden Systems und zur Beschreibung von<br />
Testkomponenten wird der „Arbiter“ eingeführt. Dieser stellt eine Schnittstelle dar, um<br />
Testurteile zu setzen oder abzufragen. Des Weiteren wird ein Scheduler für die Testablaufkontrolle<br />
und ein Testkontext definiert, der Testfälle zu einer Gruppe zusammenfasst.<br />
Die „test data“-Gruppe definiert Konzepte zur Behandlung der Daten für die Testfälle. Es<br />
erweitert die UML-Datenkonzepte insbesondere um „Wildcards“ zur flexiblen Spezifikation<br />
von Testdaten und um Kodierungsregeln zur Beschreibung der Datenübertragung.<br />
Die verhaltensrelevanten Aspekte sind unter „test behavior“ zusammengefasst. Zu den<br />
Erweiterungen zählen die Metaklassen für das Testurteil, den Testfall und die Beschrei-<br />
57
58<br />
bung eines „Default-Handlers“. Dieser wird bei Auftreten von nicht spezifiziertem Testverhalten<br />
aufgerufen, er schließt demnach Spezifikationslücken der Testfälle. Weitere<br />
Konzepte für die Testprotokollierung komplettieren diese Gruppe.<br />
Für die Beschreibung des zeitlichen Verhaltens von Testfällen ist die „time“-Gruppe zuständig.<br />
Zum einen wird eine Timerschnittstelle definiert, die zur Manipulation von Testverhalten<br />
und zur Terminierung wartender Testfälle verwendet werden kann. Zusätzlich<br />
können Zeitzonen beschrieben werden, identisch zum Konzept der TimedTTCN-3<br />
[Neu04] (siehe Kapitel 2.3.8). Sie dienen der Kennzeichnung von Zeitwerten bei verteilten<br />
Tests. Die Werte unterschiedlicher Zeitzonen stammen von nicht synchron laufenden<br />
Uhren und dürfen nicht miteinander verglichen werden.<br />
Das Kapitel 4.4 zeigt in der Abbildung 46 und Abbildung 47 exemplarisch eine „UML2<br />
Testing Profile“-konforme Testkonfiguration und das Test-Package, welches den Testkontext<br />
und die Testkomponenten enthält.
4 Q.E.D. – Testentwurfsprozess<br />
Im Folgenden wird der im Rahmen dieser Arbeit entwickelte Entwurfsprozess für statistische<br />
Tests beschrieben. Abbildung 26 gibt einen Gesamtüberblick über die erforderlichen<br />
Teilschritte.<br />
Abbildung 26 Q.E.D.-Testentwurfsprozess<br />
59
60<br />
Q.E.D. – Testentwurfsprozess<br />
Der Q.E.D.-Entwurfsprozess (QoS-Enhanced test Development) beginnt mit einer Anforderungsspezifikation,<br />
der Basis für Systemdesign und -implementierung. Kapitel 4.1<br />
widmet sich diesem Ausgangspunkt für den Prozess. Die linke Seite der Abbildung 26<br />
stellt den Systementwurf dar, der in verschiedenen Phasen zum zu testenden System<br />
(SUT) führt.<br />
Zusätzlich stellen die Anforderungen eine gute Grundlage für die Generierung von Testfällen<br />
dar. Zur Unterstützung des Testprozesses und zur Gewinnung qualitativer Aussagen<br />
über das System wird ein Testmodell generiert, aus dem Testfälle gewonnen werden<br />
können. Das Testmodell stellt ein „Markov Chain Usage Model“ (MCUM) dar, einen<br />
endlichen Zustandsautomaten, der um Informationen aus einem oder mehreren Operationsprofilen<br />
erweitert wird. Diese beinhalten Wissen über die voraussichtliche Häufigkeitsverteilung<br />
der Benutzeroperationen. Das vollständige MCUM besteht aus Benutzungszuständen<br />
und Zustandstransitionen mit assoziierten Benutzungswahrscheinlichkeiten.<br />
Ein Algorithmus zur automatischen Modellgenerierung aus szenarienbasierten Anforderungen<br />
wird im Kapitel 4.2 vorgestellt.<br />
Steht das Testmodell zur Verfügung, lässt sich automatisiert eine beliebige Anzahl an<br />
Testfällen erzeugen (siehe Kapitel 4.3). Neben diversen Überdeckungskriterien sind aufgrund<br />
der integrierten Profile insbesondere zufällige Modelltraversierungen von Interesse.<br />
Die erzeugten Testfälle können in eine ausführbare Form übersetzt werden. Durch das<br />
Ergänzen noch fehlender Dateninformationen stehen die wesentlichen Informationen zur<br />
Erstellung einer Testsuite zur Verfügung (Kapitel 4.4).<br />
Während der Testausführung werden die erzeugten Testurteile protokolliert, welche in<br />
das Testmodell eingebracht werden können. Auf Basis dieser Informationen lässt sich<br />
statistisch die erreichte Benutzungszuverlässigkeit des Systems abschätzen (Kapitel<br />
4.2.4).<br />
Dieses Kapitel beleuchtet die unterschiedlichen Aspekte des Entwurfprozesses. Zunächst<br />
findet eine genauere Betrachtung der Anforderungsspezifikation statt, die den Startpunkt<br />
des Ansatzes bildet. Dem Testmodell als zentrales Element im Q.E.D.-Ansatz ist das anschließende<br />
Kapitel 4.2 gewidmet. Danach werden die Aufgaben während der Testerzeugung<br />
dargelegt. Dies schließt die automatische Testfallgenerierung und die Erzeugung<br />
einer Testsuite in ausführbarer Form ein.
Szenarienbasierte Anforderungsspezifikation<br />
4.1 Szenarienbasierte Anforderungsspezifikation<br />
Ganz gleich, mit welcher Entwurfsmethode Software entwickelt wird, eine Anforderungsspezifikation<br />
stellt die Basis einer jeden Softwareentwicklung dar. Fehler in dieser Phase<br />
ziehen im fortgeschrittenen Entwicklungsstadium den größten Aufwand zur Fehlerbehebung<br />
nach sich.<br />
Die Anforderungsdefinitionen stellen die Schnittstelle zwischen dem Kunden und dem<br />
Entwickler dar. Die Wahl des Beschreibungsmittels sollte demnach dem Kompromiss<br />
zwischen allgemeiner Verständlichkeit und formaler Eindeutigkeit folgen. In der Praxis<br />
besteht dieser Kompromiss meist aus in Prosa formulierten Anforderungen, denen eine<br />
gewisse Struktur vorgegeben ist. Neben der Baumstruktur ist die tabellarische Form der<br />
wichtigste Vertreter, bei der vordefinierte Felder helfen, durch Angabe von Zusatzinformationen<br />
und Randbedingungen Ungenauigkeiten zu vermeiden [Coc00].<br />
Eine weitere beliebte Darstellung ist die Beschreibung in Szenarienform. Dazu eignen<br />
sich z.B. „Use Case Maps“ [ITU03] oder insbesondere Sequenzdiagramme. Letztere bieten<br />
eine einfache Darstellung der beteiligten Komponenten und Akteure mit dem Fokus<br />
auf deren Kommunikation. Eine größere Bedeutung haben die „Life Sequence Charts“<br />
[DH01], im Bereich der Telekommunikation die „Message Sequence Charts“ (MSCs)<br />
[ITU96] und bei der allgemeinen objekt-orientierten Softwareentwicklung die Sequenzdiagramme<br />
der UML [OMG07a]. Sie besitzen neben ihrer intuitiven Verständlichkeit eine<br />
formale Basis zur Vermeidung mehrdeutiger Kommunikationsabschnitte.<br />
4.1.1 Use-Case-Diagramm<br />
Die UML bietet zur Anforderungsbeschreibung zudem eine eigene Diagrammart an, das<br />
Use-Case-Diagramm. Die Aussagekraft hält sich jedoch in Grenzen, da es nur wenige<br />
Modellierungselemente enthält. Es separiert Personen und externe Komponenten vom<br />
eigentlichen System und benennt dessen Anwendungsfälle.<br />
Das Use-Case-Diagramm besteht aus drei Konzepten. Das betrachtete System wird als<br />
„Subjekt“ bezeichnet und als Rechteck visualisiert. Die Benutzer und andere externe<br />
Komponenten, die mit dem Subjekt interagieren, sind „Akteure“ und werden standardmäßig<br />
als Strichmännchen dargestellt. Anwendungsfälle werden benannt und elliptisch innerhalb<br />
des Subjekts dargestellt. Das Beispiel in Abbildung 27 stellt als Use-Case den<br />
Datentransfer zwischen einem externen Client und dem betrachteten Server dar.<br />
61
62<br />
Q.E.D. – Testentwurfsprozess<br />
Anwendungsfälle stehen in Relation zu den beteiligten Akteuren. Eine Multiplizität am<br />
Use-Case-Ende einer Assoziation bedeutet, dass der Akteur an mehreren Anwendungsfallinstanzen<br />
beteiligt sein kann. Zusätzlich können Anwendungsfälle auch untereinander<br />
in gerichteten Beziehungen stehen. Dies können die extend- oder die include-Beziehung<br />
sein. Erstere gibt an, dass ein Use-Case einen zweiten an definierten Erweiterungspunkten<br />
um bestimmte Aspekte erweitert. Entscheidend ist, dass der Use-Case auch ohne Erweiterung<br />
sinnvoll ist. Die include-Beziehung zeigt an, dass ein Use-Case das Verhalten eines<br />
zweiten Use-Cases beinhaltet, welches an geeigneter Stelle eingefügt werden muss. In<br />
diesem Fall ist der Anwendungsfall nur in Kombination vollständig und sinnvoll.<br />
Abbildung 27 Use-Case-Diagramm<br />
Ein Use-Case spezifiziert geforderte Anwendungen des Systems, das gewünschte Systemverhalten<br />
wird in ihnen aus Sicht der Akteure definiert. Zur eigentlichen Verhaltensbeschreibung<br />
können alle dynamischen Diagrammarten der UML dienen, der UML2-<br />
Standard schränkt an dieser Stelle nicht ein. Aufgrund der Betonung der kommunikativen<br />
Wechselbeziehung zwischen dem modellierten System und vorhandenen Akteuren eignen<br />
sich insbesondere Interaktionsdiagramme mit ihrem wichtigsten Vertreter: dem Sequenzdiagramm.<br />
Anwendungsfallszenarien, also Sequenzdiagramme, die die Realisierung von Anwendungsfällen<br />
beschreiben, stellen Interaktionen zwischen Systembenutzern und einem System<br />
dar, welches nur durch seine extern sichtbaren Schnittstellen repräsentiert wird, also<br />
als eine Art „black-box“. Sie eignen sich demnach hervorragend als Grundlage für den<br />
Black-Box-Test.<br />
Der Q.E.D.-Ansatz basiert auf einer UML2-Anforderungsspezifikation, welche durch ein<br />
Use-Case-Diagramm und zugehörigen Anwendungsfallbeschreibungen durch Sequenzdiagramme<br />
gegeben ist. Die Szenarien können durch Annotationen aus dem UML-SPT-<br />
Profil [OMG05b] um nicht-funktionale Anforderungen erweitert werden.
Szenarienbasierte Anforderungsspezifikation<br />
4.1.2 Leistungsanforderungen<br />
Das UML-SPT-Profil [OMG05b] standardisiert die Syntax zur Beschreibung verschiedener<br />
zeit- und leistungsbezogener Anforderungen (siehe Kapitel 3.7.1). Da beim Black-<br />
Box-Testen ausschließlich Ende-zu-Ende-Zeitanforderungen überprüfbar sind, werden<br />
beim Testentwurfsprozess lediglich drei SPT-Annotationen berücksichtigt. Systeminterne<br />
Laufzeiten oder die Erfüllung modellierter Komponentenzuteilung können dagegen nicht<br />
direkt getestet werden. Gemessene Zeiten können zwar Rückschlüsse zulassen, von primärem<br />
Interesse sind jedoch die Ende-zu-Ende-Antwortzeiten, der Durchsatz und die<br />
Latenzzeiten verschickter Nachrichten.<br />
Die Abbildung 28 beschreibt eine geforderte Antwortzeit. Die Benutzerinstanz I_user<br />
interagiert mit der Systeminstanz INRES, um eine Verbindung zu R_user aufzubauen.<br />
Dazu verschickt sie ein ICONreq und erwartet die Bestätigungsnachricht ICONconf. Die<br />
Zeitspanne zwischen dem Sendeereignis und dem erwarteten Empfangsereignis soll maximal<br />
zehn Sekunden betragen.<br />
Abbildung 28 Antwortzeit - Anforderung<br />
Der Stereotyp „PAstep“ kennzeichnet allgemein Einzelschritte in Szenarien, die zur<br />
Durchführung ihrer Funktion Ressourcen bzw. Zeit benötigen. Das Kürzel „PA“ ordnet<br />
ihn innerhalb des SPT-Profils dem Subprofil „Performance“ zu. Die eigentliche Anforderung<br />
an den Schritt wird mit dem Eigenschaftswert konkretisiert. Die gesamte Annotation<br />
wird mit dem Ausführungsfocus („execution occurrence“) verbunden, welcher die relevanten<br />
Sende- und Empfangsereignisse beinhaltet.<br />
Die Latenzzeit, also die Verzögerungszeit zwischen Versenden und dem Empfang einer<br />
Nachricht, wird nicht direkt durch ein Schlüsselwort unterstützt. Sie kann nur indirekt<br />
über die Angabe eines „host execution demand“-Tags angegeben werden.<br />
63
64<br />
Abbildung 29 Latenz - Anforderung<br />
Q.E.D. – Testentwurfsprozess<br />
Allgemein gibt das Tag die vollständige Anforderung an seine Ressource wieder und wird<br />
entweder direkt mit der Nachricht oder mit einem vorhandenen Ausführungsfocus auf der<br />
Systeminstanz verbunden. Abbildung 29 ist ein Beispiel für die Forderung an den Einzelschritt,<br />
höchstens zwei Sekunden zu benötigen.<br />
Wird von einer Instanz ein bestimmter Durchsatz gefordert, so wird das Anmerkungsfeld<br />
direkt mit der Instanz verbunden. Abbildung 30 zeigt den Austausch von zehn Nachrichten<br />
zwischen den Instanzen I_user und R_user über die INRES-Instanz. Der Stereotyp<br />
„PAhost“ kennzeichnet eine aktive Ressource, der Eigenschaftswert fordert einen Durchsatz<br />
von zehn Nachrichten pro Zeiteinheit.<br />
Abbildung 30 Durchsatz - Anforderung<br />
Neben der Angabe harter Zeitgrenzen ermöglicht das SPT-Profil Eigenschaftswerte mit<br />
weichen und statistischen Eigenschaften. Das Kapitel 3.7.1 listet die Möglichkeiten des<br />
Standards auf. Abbildung 31 stellt eine Forderung an die auftretenden Antwortzeiten. Sie<br />
sollen einer exponentiellen Verteilung mit dem Mittelwert von 0,5 Sekunden folgen.
Markov Chain Usage Model<br />
Abbildung 31 Verteilungsfunktions - Anforderung<br />
Für alle Szenarien, in denen Aspekte der Leistung relevant sind, sieht das Performance-<br />
Subprofil die Zuweisung in einen sog. Performance-Kontext vor. Die Zugehörigkeit wird<br />
durch die Angabe des „PAContext“-Stereotyps über den Szenarien deutlich. Dies vereinfacht<br />
deren Identifizierung bei der automatisierten Verarbeitung der Sequenzdiagramme.<br />
4.2 Markov Chain Usage Model<br />
Die automatisierte modellgestützte Testfallgenerierung zur Unterstützung des Testprozesses<br />
findet ihren Einsatz in einer Reihe von Projekten (siehe Kapitel 2.2). In dieser Arbeit<br />
wird für diesen Zweck ein sog. „Markov Chain Usage Model“ (MCUM) erzeugt. Dieses<br />
Kapitel gibt einen Überblick über dessen Eigenschaften und beschreibt eine Möglichkeit<br />
zur automatischen Erstellung.<br />
4.2.1 Einführung<br />
Ein Markov Chain Usage Model findet in einem statistischen Testprozess Verwendung.<br />
Als Usage-Modell stellt es alle möglichen Aktionen eines Systems aus Benutzersicht dar.<br />
Dessen Benutzung als Testmodell legt den Schwerpunkt der Testfälle auf im Betrieb<br />
wahrscheinliche Operationen. Nach der Testausführung kann auf Basis der Testergebnisse<br />
eine Abschätzung gegeben werden, welche Zuverlässigkeit erreicht wurde.<br />
Das MCUM wurde 1993 von Whittaker und Poore [WP93] eingeführt. Sie bemängelten<br />
einen Umstand, den aktuelle Zuverlässigkeitsmodelle teilten [DN84, MMN+92]. Diese<br />
betrachteten in der Regel die gesamte Eingabedomäne des zu testenden Systems und wiesen<br />
jeder Eingabe eine vorausgesagte Auftretenswahrscheinlichkeit zu. Daraus gewonnene<br />
Testergebnisse wurden zur Abschätzung der erreichten Zuverlässigkeit verwendet.<br />
65
66<br />
Q.E.D. – Testentwurfsprozess<br />
Das Problem dieser Herangehensweise ist die Vernachlässigung der aktuellen Systemzustände.<br />
Üblicherweise ändern sich die Eingabewahrscheinlichkeiten im laufenden Betrieb,<br />
der aktuelle Zustand oder „Modus“ des Systems muss berücksichtigt werden. Das<br />
MCUM ist daher ein Zustandsautomat, die Wahrscheinlichkeiten können individuell für<br />
jeden Zustand angegeben werden.<br />
Mittlerweise wurden MCUMs in zahlreichen Projekten [WT94, Say99, GM02, DZ03]<br />
eingesetzt und verschiedene Facetten beleuchtet. Sie finden in der Softwareentwicklungsmethode<br />
„Cleanroom“ [PTL+99] ihren Einsatz, beim Web-Testen [KT01] und beim<br />
Partitionstest [SP00]. In [Gut97] werden seltene Ereignisse behandelt, [WP00] widmet<br />
sich der Gewinnung der Transitionswahrscheinlichkeiten und mit der „TML“ steht eine<br />
eigene Beschreibungssprache für MCUMs zur Verfügung [Pro00].<br />
4.2.2 Eigenschaften<br />
Ein MCUM ist eine zustandsendliche, zeitlich homogene, diskret parametrisierte und<br />
nicht reduzierbare Markowkette [Say99]. Es besitzt einen Startzustand, welcher den Systemstart<br />
bzw. Programmaufruf symbolisiert, einen für die Terminierung stehenden Endzustand<br />
und Zustände, welche die Benutzung des betreffenden Systems repräsentieren<br />
(einfaches Beispiel-MCUM in Abbildung 32).<br />
Ein MCUM wird als gerichteter Graph G = (S, T) und einer Funktion p: S × S → [0,1]<br />
mit folgenden Eigenschaften beschrieben [Gut00]:<br />
S: Die nichtleere Knotenmenge, die Zustände der Systembenutzung repräsentieren<br />
T: Die nichtleere Kantenmenge, bestehend aus Zustandstransitionen, die mit Benutzeraktionen<br />
korrespondieren.<br />
p(si, sj): Die Transitionswahrscheinlichkeit von Zustand si zu Zustand sj mit folgenden<br />
Eigenschaften:<br />
0 p ( s , ) ≤ 1<br />
∑<br />
s j∈S<br />
≤ i s j<br />
p( s , s ) = 1<br />
i<br />
j<br />
Der Endzustand ist absorbierend, d.h. für den Endzustand sn gilt p(sn, sn) = 1. Die Transitionswahrscheinlichkeiten<br />
p(si, sj) werden häufig in Matrixform mit (p(si, sj))i,j dargestellt.<br />
Aus dem MCUM lassen sich Testfälle gewinnen, sie entsprechen Pfaden vom Start- zum<br />
Endzustand.
Markov Chain Usage Model<br />
Operationelles Profil<br />
Abbildung 32 Einfaches MCUM<br />
Die Transitionswahrscheinlichkeiten stammen aus einem operationellen Profil des Systems.<br />
Es können mehrere Profile pro System existieren, für unterschiedliche Benutzertypen<br />
(z.B. Systemadministrator/Systembenutzer) oder zum Testen unterschiedlicher Lastsituationen<br />
[Wey03].<br />
Nach [WP93] existieren drei Herangehensweisen für die Erstellung eines operationellen<br />
Profils. Die erste wird „uninformiert“ bezeichnet, es steht keine Information über das<br />
spätere Verhalten zur Verfügung. In diesem Fall wird die Gleichverteilung angewendet,<br />
d.h. jede ausgehende Transition eines Zustands ist gleich wahrscheinlich. Bei der zweiten,<br />
„informierten“ Methode stehen Felddaten zur Verfügung. Diese können von einem Prototypen<br />
oder von einer früheren Version stammen. Beim Testen eines Webservers in<br />
[KT01] wurde das Benutzerverhalten durch Analyse umfangreicher Weblogs vergleichbarer<br />
Webserver abgeschätzt. In [VW98, WV00] war der Ausgabestrom eines bestehenden<br />
älteren Systems gleich dem Eingabestrom des zu testenden Systems, da diese in einer<br />
Reihenschaltung betrieben werden sollten. Zur Charakterisierung des Datenstroms wurde<br />
das bestehende System einem Monitoring unterzogen.<br />
Die dritte Methode ist der „vorgesehene“ oder „geplante“ Ansatz. Späteres Nutzerverhalten<br />
kann angenähert vorhergesagt bzw. gewünschtes Verhalten angenommen werden. Für<br />
diesen Ansatz beschreibt [WP00] ein regelbasiertes Verfahren zur Anpassung der Transitionsmatrix.<br />
Den Ausgangspunkt bildet, wie beim uninformierten Ansatz, die Gleichverteilung.<br />
Sowohl punktuelle Vorhersagen, also Wissen über einzelne Transitionswahrscheinlichkeiten,<br />
als auch relative Aussagen, d.h. Wissen über die Auftretenswahrscheinlichkeiten<br />
einzelner Transitionsaktionen in Relation zu anderen, werden in Regelform<br />
definiert. [WP00] enthält dazu mehrere Beispiele und beschreibt, wie mit einer geringen<br />
67
68<br />
Q.E.D. – Testentwurfsprozess<br />
Anzahl solcher Regeln die Ausgangsmatrix in großen Teilen angepasst werden kann, um<br />
realistischere Matrixwerte zu erzeugen.<br />
Statistische Aussagen<br />
Als Testmodell dient das MCUM nicht nur der Generierung von Testfällen, es unterstützt<br />
auch die Testplanungsphase. Einige Standardanalyseergebnisse für Markowketten ergeben<br />
[WT94] (s0: Startzustand):<br />
(1) Die Wahrscheinlichkeit für das Auftreten des Zustands sj in einem Testfall entspricht<br />
der Wahrscheinlichkeit der Auswahl des Pfades vom Startzustand zum Zustand sj:<br />
∑<br />
sk<br />
∈S<br />
y s , s ) = p(<br />
s , s ) + p(<br />
s , s ) y(<br />
s , s )<br />
( 0 j<br />
0<br />
j<br />
d.h. die gesuchte Wahrscheinlichkeit entspricht der Addition der Transitionswahrscheinlichkeit<br />
vom Startzustand zum gesuchten Zustand und der Summe aller möglichen Pfade<br />
vom Startzustand zum Zustand sj.<br />
(2) Die mittlere benötigte Anzahl von Testfällen zum Auftreten des Zustands sj in einem<br />
generierten Testfall ist der Kehrwert von y:<br />
1<br />
h ( s j ) =<br />
y(<br />
s , s )<br />
(3) Die Wahrscheinlichkeit für das Auftreten der Transition von Zustand sj zu Zustand sk<br />
in einem Testfall:<br />
0 j<br />
z ( s j , sk<br />
) = y(<br />
s0<br />
, s j ) p(<br />
s j , sk<br />
)<br />
(4) Die mittlere benötigte Anzahl an Testfällen zum Auftreten der Transition von Zustand<br />
sj zu Zustand sk ist der Kehrwert von z:<br />
1<br />
h ( s j , sk<br />
) =<br />
z(<br />
s , s )<br />
Eine Reihe weiterer für die Testplanung interessanter Metriken sind in [Say99] zusammengefasst.<br />
Die Berechnung der mittleren Testfalllänge gibt schon vor der Testdurchführung<br />
einen Hinweis auf die zu erwartende Dauer. Die Kontrolle der Überdeckungsrate der<br />
j<br />
o<br />
k<br />
k<br />
k<br />
j
Markov Chain Usage Model<br />
Modellzustände bzw. -transitionen erlaubt die Anwendung eines einfachen Haltekriteriums<br />
[Wey03].<br />
4.2.3 Erstellung eines MCUMs<br />
Alle konzeptionellen Vorteile eines MCUMs kommen nicht zum Tragen, wenn es aufgrund<br />
eines zu hohen Aufwandes nicht erstellt wird. In [DZ03] wird auf die Erzeugung<br />
eines MCUMS aus einer Menge von MSCs („Message Sequence Charts“) eingegangen.<br />
Es werden jedoch lediglich einfache Sequenzen betrachtet, die erweiterten Beschreibungsmöglichkeiten<br />
oder komplexere Abläufe werden nicht berücksichtigt. Letztere entstehen<br />
z.B. durch die Anwendung der sog. „inline expressions“, welche weitgehend den<br />
kombinierten Fragmenten der UML2 entsprechen. Darüber hinaus wird in der Literatur<br />
nur wenig auf den Erstellungsprozess eingegangen. Dieses Unterkapitel widmet sich dieser<br />
wichtigen Aufgabe.<br />
Im Q.E.D.-Ansatz stellt eine UML2-Anforderungsspezifikation das Ausgangsmaterial zur<br />
Erstellung des MCUMs als Testmodell dar. Wie in Kapitel 4.1 beschrieben, besteht diese<br />
aus Sequenzdiagrammen, die neben dem funktionalen Kommunikationsverhalten auch<br />
zeitliche Anforderungen beschreiben. Optional kann ein Use-Case-Diagramm externe<br />
Akteure darstellen und sie in Bezug zu Anwendungsfällen stellen.<br />
Es folgt nun eine detaillierte Abbildungsvorschrift der Anforderungsspezifikation auf das<br />
MCUM. Der Reihe nach werden alle Konzepte der Sequenzdiagramme diskutiert, ob und<br />
wie sie behandelt werden.<br />
Voraussetzungen<br />
Aus dem Modell werden Testfälle für einen Black-Box-Test generiert, demnach ist ausschließlich<br />
die extern sichtbare Systeminteraktion von Interesse. Die zu bearbeitenden<br />
Sequenzdiagramme besitzen lediglich eine Systeminstanz, alle anderen Objektinstanzen<br />
repräsentieren Benutzer des Systems. Sind mehrere Systeminstanzen vorhanden, müssen<br />
die Diagramme zunächst durch den Dekompositionsoperator (siehe Kapitel 3.6) angepasst<br />
werden.<br />
In den Szenarienbeschreibungen bleiben einige Interaktionskonzepte unberücksichtigt, da<br />
sie im verwendeten Kontext bedeutungs- oder sinnlos sind:<br />
• Ordnungsrelation: Die Operatoren zur expliziten Angabe der strikten bzw. losen<br />
Ordnung („strict“ und „seq“) können ignoriert werden, da ausschließlich die Ereignisreihenfolge<br />
auf der Systeminstanz von Relevanz ist. Die lose Ordnung er-<br />
69
70<br />
Q.E.D. – Testentwurfsprozess<br />
zeugt dagegen einen Freiheitsgrad bei den Sende- und Empfangszeitpunkten der<br />
Benutzerinstanzen.<br />
Die Abbildung 33 verdeutlicht diesen Umstand. Das Beispielszenario lässt offen,<br />
ob zunächst User_1 oder User_2 seine Nachricht verschickt. Aus Systemsicht ist<br />
jedoch festgelegt, dass die Nachricht m1 vor der Nachricht n1 empfangen wird.<br />
Um diese Reihenfolge beim Testen garantieren zu können, wird eine totale Ordnung<br />
in den Szenarienbeschreibungen angenommen (vgl. auch Kapitel 4.3 „Synchronisierung“).<br />
Abbildung 33 Ordnungsrelation<br />
• Ausführungsfocus: Auf der Systeminstanz modellierte Aktionssequenzen bleiben<br />
unberücksichtigt, da systeminternes Verhalten bei Black-Box-Verfahren nicht<br />
bzw. nur indirekt getestet wird.<br />
• Der „consider“-Operator des kombinierten Fragments wird bei der MCUM-<br />
Erstellung nicht betrachtet. Er zeigt an, dass alle nicht im Fragment aufgelisteten<br />
Nachrichten ignoriert werden sollen. Da diese zu ignorierenden Nachrichten nicht<br />
näher bestimmt sind, können zwei Fälle unterschieden werden:<br />
(1) Beliebige nicht aufgelistete Nachrichten von Benutzer- zur Systeminstanz sollen<br />
beim System zu keiner Reaktion führen. Dies führt zu keinem sinnvollen Testfall,<br />
für die Automatisierung sollte der Freiheitsgrad der Nachrichtenwahl beschränkt<br />
werden.<br />
(2) Innerhalb des Fragments können beliebige Nachrichten von der System- zur<br />
Benutzerinstanz auftreten, die irrelevant sind. Dieses Szenario ist für den Test bedeutungslos,<br />
da es keinen negativen Testlauf gäbe. Jede Systemreaktion ist als<br />
korrekt spezifiziert.
Markov Chain Usage Model<br />
Andere Interaktionskonzepte werden nur teilweise berücksichtigt bzw. werden vor dem<br />
Transformationsvorgang umgewandelt:<br />
• Zustandsinvarianten: Zustandsinvarianten beschreiben Regeln, die zur Laufzeit<br />
überprüft werden. Formal können u.A. bestimmte Attribut- bzw. Variablenwerte<br />
oder Zustände gefordert werden. Nur bei einer gültigen Invariante wird ein erlaubtes<br />
Szenario beschrieben. In dieser Arbeit werden nur Forderungen bezüglich des<br />
erreichten Systemzustands berücksichtigt, da sich nur diese zur Verknüpfung von<br />
Szenarien eignen.<br />
• Sprungmarken („continuations“) stellen spezielle Verknüpfungspunkte in alternativen<br />
Fragmenten dar (vgl. Kapitel 3.6). Für die nachfolgend beschriebene Transformation<br />
können diese ähnlich den Zustandsinvarianten interpretiert werden, d.h.<br />
sie stellen Verknüpfungspunkte verschiedener Szenarien dar.<br />
• Zwei Operatoren des kombinierten Fragments, die Sicherstellung „assert“ und<br />
der kritische Bereich „critical“, werden bei der Transformation zunächst ignoriert.<br />
Beide betonen die enthaltene Nachrichtensequenz, die dargestellte Reihenfolge<br />
ist wichtig bzw. nur in dieser gültig. Während des Abbildungsvorgangs werden<br />
sie jedoch gesondert behandelt (siehe Transformationsschritt 3), die in ihren<br />
Fragmenten enthaltenen Zustandsinvarianten werden daher eindeutig gekennzeichnet<br />
(durch Hinzufügen eines Namenpräfixes).<br />
• Die Negation „neg“ beschreibt Szenarien, die ungültig sind. Sie dienen der Erzeugung<br />
illegaler Testfälle, d.h. sie beschreiben explizite Antwortnachrichten des<br />
Systems, die zu einem „fail“-Testurteil führen, während alle anderen Nachrichten<br />
gültige Systemantworten darstellen. Die Szenarien können zunächst wie legale<br />
Szenarien auf das MCUM abgebildet werden. Aufgrund der gegensätzlichen Semantik<br />
müssen diese Zustandsübergänge jedoch für die automatisierte Testfallgenerierung<br />
erkennbar bleiben. Die enthaltenen Nachrichten werden daher durch<br />
Hinzufügen eines Namenpräfixes kenntlich gemacht.<br />
• Der „ignore“-Operator listet Nachrichten auf, die innerhalb des kombinierten<br />
Fragments nicht dargestellt sind (vgl. Kapitel 3.6). Die gelisteten Nachrichten<br />
können an jeder Stelle innerhalb des Fragments auftreten und sollen ignoriert werden,<br />
d.h. sie dürfen keine Reaktion hervorrufen. Er stellt somit das Gegenstück<br />
zum consider-Operator da, die für ihn genannten zwei Varianten gelten gleicher-<br />
71
72<br />
Q.E.D. – Testentwurfsprozess<br />
maßen. Die Nachrichtenauswahl im ersten beschriebenen Fall wird jedoch durch<br />
eine Liste eingeschränkt und ermöglicht damit eine sinnvolle Automatisierung.<br />
Das folgende Beispiel zeigt, wie dieser Operator vor der Transformation aufgelöst<br />
wird. Nach jedem Zustand des Fragments wird der Empfang jeden Elements der<br />
Nachrichtenliste eingefügt, jeweils gefolgt durch den vorherigen Zustand.<br />
Die Abbildung 34 links stellt ein Szenario dar, in der die Systeminstanz die Nachrichten<br />
m1, m2 und m3 ignorieren soll. Rechts ist das bearbeitete Sequenzdiagramm<br />
abgebildet, es stellt eine mögliche Empfangsreihenfolge der Nachrichten<br />
dar. Da durch die nachfolgenden Transformationsschritte ein Automatenmodell<br />
entsteht, kann ein daraus generierter Testfall dennoch jede beliebige Nachrichtenfolge<br />
enthalten und prüfen.<br />
Transformationsschritte<br />
Abbildung 34 Auflösung des „ignore“-Fragments<br />
Da die Anforderungen als Spezifikation in der UML2 vorliegen, liegt es nahe, das<br />
MCUM ebenso in der UML2 darzustellen. Das Modell kann somit in der gleichen Werkzeugumgebung<br />
betrachtet werden. Protokollzustandsautomaten eignen sich für diesen<br />
Zweck, die erweiterten Beschreibungsmöglichkeiten von Verhaltenszustandautomaten<br />
werden nicht benötigt. Es folgt eine detaillierte Beschreibung der benötigten Teilschritte:
Markov Chain Usage Model<br />
1. Einfügen von Zustandsinvarianten<br />
Im ersten Schritt werden auf der Systeminstanz der Anforderungsszenarien weitere Zustandsinvarianten<br />
eingefügt, die als sog. Zwischenzustände den jeweiligen Systemzustand<br />
repräsentieren. Dies erfolgt nach der Regel, dass in Kombination mit den bereits enthaltenen<br />
benutzerdefinierten Invarianten maximal zwei Ereignisse zwischen zwei Zuständen<br />
verbleiben - ein Sende- und das korrespondierende Empfangsereignis. In allen anderen<br />
Fällen stehen Ereignisse einzeln, voneinander durch Zustandsinvarianten getrennt. Diese<br />
stellen sicher, dass erkannte Fehler während der Testausführung im Szenario rückverfolgbar<br />
sind.<br />
2. Abbildung der Szenarien auf Zustandsmaschinen<br />
Abbildung 35 Transformation - Basisregeln<br />
73
74<br />
Q.E.D. – Testentwurfsprozess<br />
Anschließend wird jedes Szenario auf eine Zustandsmaschine abgebildet. Die kleinste<br />
Abbildungseinheit stellen die Ereignisse zwischen zwei Zustandsinvarianten dar. Wegen<br />
des vorhergehenden Transformationsschrittes gibt es drei Basisregeln, die in Abbildung<br />
35 zu sehen sind. Darin ist rechts die erzeugte Transition aus dem korrespondierenden<br />
Szenario links zu sehen.<br />
Die entstehenden Zustandsübergänge benennen die auszutauschenden Nachrichten. Ein<br />
Systemstimulus wird in der Syntax der Protokollzustandsmaschinen auf eine Vorbedingung<br />
abgebildet, folglich steht dieser in eckigen Klammern. Eine Systemantwort entspricht<br />
einer Operation und wird ohne Klammern notiert (vgl. Abbildung 14). Da in den<br />
Szenarien mehrere Benutzerinstanzen enthalten sein können, werden die Nachrichten um<br />
den Namen der Sende- bzw. Empfängerinstanz erweitert. Dies ermöglicht während der<br />
Testfallerstellung die korrekte Zuordnung des Verhaltens auf die Testkomponenten. Zur<br />
Verdeutlichung der verwendeten Transitionssyntax zeigt Abbildung 36 die erzeugte Zustandsmaschine<br />
für das INRES-Beispiel aus Abbildung 9.<br />
Abbildung 36 Zustandsmaschine des INRES-Protokolls<br />
Für die Konkatenation gilt Abbildung 37, darin ist M(i) der erzeugte Automat für Szenario<br />
i. Die Abbildungsvorschrift erzeugt aus einem fortlaufenden Szenario einen fortlaufenden<br />
Automatenpfad.<br />
Abbildung 37 Transformation - Konkatenation
Markov Chain Usage Model<br />
Abbildung 38 und Abbildung 39 zeigen die benötigten Transformationsregeln für verschiedene<br />
kombinierte Fragmente. Die erzeugten Automaten der Operatoren „alt“ und<br />
„opt“ machen deutlich, dass es sich bei letzterem um einen Spezialfall der Alternative<br />
handelt. Beim optionalen Fragment wird entweder das enthaltene Szenario ausgeführt<br />
oder das Verhalten wird an dessen Ende fortgesetzt.<br />
Abbildung 38 Transformation - Kombinierte Fragmente (Teil 1)<br />
75
76<br />
Q.E.D. – Testentwurfsprozess<br />
Im Falle des „par“-Operators wird ein zusammengesetzter Zustand mit orthogonalen Regionen<br />
erzeugt. Die im kombinierten Fragment enthaltenen Szenarien werden als Sub-<br />
Zustandsmaschinen in die erzeugten Regionen eingefügt. Der Automat aus der unbeschränkten<br />
Schleife kann die Zustände des Szenarios gar nicht oder beliebig oft durchlaufen,<br />
bei der beschränkten Schleife mindestens „min“, höchstens „max“ Mal.<br />
Die Operanden der Operatoren „alt“, „opt“ und „loop“ können außerdem mit einem booleschen<br />
Ausdruck versehen sein, welcher für einen ausgewählten Operanden mit „wahr“<br />
ausgewertet sein muss. Diese Ausdrücke haben keinen Einfluss auf die Transformation,<br />
sondern auf das operationelle Profil. So muss sich die Wahrscheinlichkeit einer wahren<br />
Bedingung in der Wahrscheinlichkeit dieser Verzweigung im MCUM widerspiegeln.<br />
Abbildung 39 Transformation - Kombinierte Fragmente (Teil 2)<br />
Für Szenarien mit SPT-Annotationen gelten grundsätzlich die gleichen Abbildungsregeln,<br />
hinzu kommt die Notwendigkeit, die Annotationen zu erhalten und Start- und Endpunkte<br />
für die zeitlichen Einschränkungen zu kennzeichnen.<br />
Da die Start- und Endzeitpunkte der nicht-funktionalen Anforderungen immer an Sende-<br />
bzw. Empfangsereignisse von Nachrichten gekoppelt sind, lassen sich die Annotationen
Markov Chain Usage Model<br />
gut auf die Zustandsautomaten übertragen. Hier gilt die Regel, dass die ursprüngliche<br />
Annotation - um einen nummerierten Start-Tag erweitert - an die Nachricht des Startzeitpunktes<br />
gebunden wird. Die Nachricht des Endzeitpunktes erhält eine Annotation mit<br />
einem End-Tag und einer - zum Start-Tag korrespondierenden - laufenden Nummer. Die<br />
Tags ermöglichen auch bei verschachtelten Anforderungen die eindeutige Zuordnung von<br />
Start- und Endpunkten. Die Abbildung 40 enthält dazu ein Beispiel.<br />
Abbildung 40 Transformation – SPT-Annotation<br />
3. Vereinigung der Zustandsmaschinen und Erstellung des MCUMs<br />
Vor diesem dritten Transformationsschritt existiert pro Szenario ein Zustandsautomat,<br />
diese werden nun zu einem MCUM vereint. Alle gleich benannten Zustände werden zusammengefasst,<br />
die neu entstehende Menge an ein- bzw. ausgehenden Transitionen ist die<br />
Vereinigung der alten ein- und ausgehenden Übergänge. Ebenso werden alle Endzustände<br />
zu einem verschmolzen. Da die UML2-Spezifikation für den Initialzustand nur eine ausgehende<br />
Transition erlaubt, wird dieser mit einem Zustand namens „Start“ verbunden,<br />
welcher die Initialzustände aller Szenarien ersetzt.<br />
Für diesen dritten Transformationsschritt gibt es mehrere Ausnahmen. Verschiedene Automatenzustände<br />
müssen atomar behandelt werden, d.h. sie dürfen mit anderen gleich<br />
benannten Zuständen nicht verschmolzen werden.<br />
Zum einen trifft diese Ausnahme auf Zustandsinvarianten aus den kombinierten Fragmenten<br />
Sicherstellung („assert“) und dem kritischen Bereich („critical“) zu. Beide Operatoren<br />
verbieten gültige Verzweigungen innerhalb ihres Fragments, durch eine Vereinigung<br />
mit Zuständen anderer Szenarien würde ihre Semantik verletzt werden.<br />
Die gleiche Ausnahme gilt für Automaten mit SPT-Annotationen. Zeitliche Einschränkungen<br />
erstrecken sich häufig über mehrere Systemzustände hinweg, nur die enthaltene<br />
77
78<br />
Q.E.D. – Testentwurfsprozess<br />
Sequenz besitzt eine gültige nicht-funktionale Anforderung. Ein Verschmelzen mit Zuständen<br />
anderer Szenarien kann zu fälschlicherweise annotierten Pfaden führen, für die<br />
keine Zeitanforderung gegeben ist. Folglich müssen die enthaltenen Automatenzustände<br />
ebenfalls atomar behandelt werden.<br />
Zur Fertigstellung des MCUMs wird jede Transition um ihre Auftretenswahrscheinlichkeit<br />
aus einem operationellen Profil erweitert (siehe Kapitel 4.2.2). Besteht die Anforderungsspezifikation<br />
zusätzlich aus einem Use-Case-Diagramm, in welchem mehrere Anwendungsfälle<br />
modelliert sind, ist das vorläufige Ergebnis ein MCUM pro Use-Case.<br />
Liegen Informationen über die Auftretenswahrscheinlichkeiten der Benutzer und Use-<br />
Cases vor, können die Modelle zu einem einzigen MCUM verbunden werden.<br />
Abbildung 41 zeigt ein Beispiel mit zwei Akteuren, es sei:<br />
qi: Auftretenswahrscheinlichkeit von Benutzer i<br />
pij: Wahrscheinlichkeit von Benutzer i, den Anwendungsfall j auszuführen<br />
Abbildung 41 Erweitertes Use-Case-Diagramm<br />
Das aus diesem Beispiel resultierende zusammengesetzte MCUM zeigt Abbildung 42.<br />
Abbildung 42 Zusammengesetztes MCUM
Markov Chain Usage Model<br />
Die Übergangswahrscheinlichkeit vom Startzustand zum MCUM für Anwendungsfall j<br />
berechnet sich aus:<br />
P ( j)<br />
∑<br />
= qi<br />
pij<br />
i∈Akteure<br />
Semantikvergleich UML Sequenzdiagramm – MCUM<br />
Zum Abschluss dieses Unterkapitels folgt ein Vergleich der Semantiken der UML2-<br />
Sequenzdiagramme und des erzeugten MCUM. Die UML erlaubt die Beschreibung von<br />
Systemverhalten durch die Angabe seiner internen bzw. externen Interaktionen. Dabei gilt<br />
eine Spurensemantik, d.h. die Semantik der Interaktionen wird durch das Mengenpaar<br />
[P, I] beschrieben, mit:<br />
P: die Menge der gültigen Spuren<br />
I: die Menge der ungültigen Spuren<br />
Ein Szenario mit einer Negation („neg“) beschreibt eine Spur der Menge I, alle anderen<br />
Szenarien beschreiben Spuren der Menge P. Szenarien beschreiben jedoch nicht das gesamte<br />
mögliche Systemverhalten, sie stellen lediglich eine Auswahl dar. Über nicht spezifizierte<br />
Spuren kann keine Aussage getroffen werden, sie gehören entweder zur Menge P<br />
oder zur Menge I.<br />
Das MCUM und ein aus ihm erzeugter Testfall hat notwendigerweise eine andere Semantik.<br />
Verhält sich das SUT beim Testen wie im MCUM spezifiziert, so gilt das Testurteil<br />
„pass“. Zeigt sich ein anderes Verhalten, so gilt dieser Testfall als fehlgeschlagen. Die<br />
Spurensemantik würde stattdessen ein „inconclusive“ vorschreiben, also das Testurteil<br />
ohne Korrektheitsaussage. Die Anwendung der Spurensemantik beim Testen ist jedoch<br />
nicht möglich, da jedes illegale SUT-Verhalten explizit angegeben werden müsste.<br />
Eine weitere Konsequenz der UML2-Spurensemantik ist, dass lediglich die gesamte Spur<br />
gültig ist, nicht jedoch einzelne Teilspuren daraus. Das MCUM besitzt stattdessen die<br />
Markow-Eigenschaft, d.h. für den weiteren Verlauf einer Spur ist dessen Historie irrelevant.<br />
Es ist also gleich, auf welchem Weg der aktuelle Zustand erreicht wurde, jede ausgehende<br />
Transition im MCUM gilt als gültige Fortsetzung. Dies stellt eine Grundannahme<br />
bei der MCUM-Erstellung dar, was durch das Vorhandensein von Systemzuständen in<br />
den Sequenzdiagrammen begründet ist. Durch die Spezifikation mehrerer gleich benannter<br />
Zustände werden implizit alternative gültige Spuren beschrieben, diese Eigenschaft<br />
macht sich der Transformationsalgorithmus zu Nutze.<br />
79
80<br />
4.2.4 Software-Zuverlässigkeit<br />
Q.E.D. – Testentwurfsprozess<br />
Der Begriff der Zuverlässigkeit wird in der Literatur und in Standards unterschiedlich<br />
definiert. Die DIN ISO Norm 9000 Teil 4 [DIN94] beschreibt den Begriff als „Beschaffenheit<br />
einer Einheit bezüglich ihrer Eignung, während oder nach vorgegebenen Zeitspannen<br />
bei vorgegebenen Anwendungsbedingungen die Zuverlässigkeitsanforderungen<br />
zu erfüllen“. Diese Definition wird jedoch meist mit dem Begriff der Verlässlichkeit<br />
(„dependability“) gleichgesetzt. Im Allgemeinen setzt sich die Verlässlichkeit aus den<br />
Komponenten Zuverlässigkeit („reliability“), Sicherheit („safety“) und Verfügbarkeit<br />
(„availability“) zusammen.<br />
[Bir97] beschreibt eine verbreitete Definition der Softwarezuverlässigkeit mit der Überlebenswahrscheinlichkeit,<br />
also der Wahrscheinlichkeit, in einer gegebenen Umgebung und<br />
Zeitraum ohne Reparaturen funktionsfähig zu sein.<br />
Die Anforderungen an die Zuverlässigkeit eines Systems können sich stark unterscheiden.<br />
Der Standard [IEC98] definiert „SIL“-Level mit verschiedenen Zuverlässigkeitsanforderungen<br />
für unterschiedliche Systemtypen.<br />
Beim statistischen Testen wird durch eine geeignete Auswahl der Testfälle die Softwarezuverlässigkeit<br />
abgeschätzt, wie sie die tatsächlichen Benutzer empfinden. Man spricht<br />
hier von der Benutzungszuverlässigkeit („usage reliability“).<br />
Whittaker und Thomason geben in [WT94] einen Algorithmus zur Berechnung der Benutzungszuverlässigkeit<br />
an. Darin erstellen sie neben dem MCUM ein weiteres Modell,<br />
das sog. Testkettenmodell („testing chain“), welches zunächst aus den gleichen Zuständen<br />
wie das MCUM besteht. Die Transitionswahrscheinlichkeiten des Testkettenmodells sind<br />
zunächst alle gleich null, erst während der Testausführung werden sie berechnet. Die Übergangswahrscheinlichkeit<br />
p(si, sj) von Zustand si zu Zustand sj berechnet sich aus:<br />
s(<br />
si<br />
, s j )<br />
p ( si<br />
, s j ) =<br />
v(<br />
s )<br />
Formel 1 Testkettenmodell - Transitionswahrscheinlichkeiten<br />
s(si, sj): Anzahl der erfolgreichen Transitionsübergänge von Zustand si zu Zustand sj<br />
v(si): Anzahl der Besuche von Zustand si<br />
Tritt beim Testen ein Fehler auf, wird an der entsprechenden Position im Testkettenmodell<br />
ein neuer Fehlerzustand eingefügt. Trat der k-te Fehler bei einer Transition aus Zu-<br />
i
Markov Chain Usage Model<br />
stand si auf, entspricht die Übergangswahrscheinlichkeit von si zum neuen Fehlerzustand<br />
fk der Differenz der Summe aller übrigen Übergangswahrscheinlichkeiten von si zu eins:<br />
S: Menge aller Modellzustände<br />
∑<br />
si∈S<br />
p ( s , f ) = 1−<br />
p(<br />
s , s )<br />
i<br />
k<br />
Die ausgehende Transition von fk wird entweder mit dem Endzustand oder mit dem ursprünglichen<br />
Nachfolgezustand im Testkettenmodell verbunden, dies hängt von der<br />
Schwere des Fehlers ab. Da der Fehlerzustand in jedem Fall eine einzige ausgehende<br />
Transition besitzt, ist deren Wahrscheinlichkeit eins: p ( f , ) = 1<br />
i<br />
j<br />
k s j<br />
Für die Berechnung der Softwarezuverlässigkeit werden alle Fehlerzustände als absorbierend<br />
betrachtet. Dann ist die Zuverlässigkeit gleich der Wahrscheinlichkeit eines fehlerfreien<br />
Pfades vom Start- zum Endzustand innerhalb des Testkettenmodells:<br />
∑<br />
s j∈S<br />
R ( s , s ) = p(<br />
s , s ) + p(<br />
s , s ) R(<br />
s , s )<br />
start<br />
end<br />
start<br />
end<br />
start<br />
Formel 2 Benutzungszuverlässigkeit nach [WT94]<br />
S: Menge aller Zustände des Testkettenmodells<br />
Das Testkettenmodell kann auch zur Definition eines möglichen Stoppkriteriums verwendet<br />
werden. Das MCUM repräsentiert das gewünschte, theoretische Verhalten bei Abwesenheit<br />
jeden Fehlers, während das Testkettenmodell das reale Verhalten darstellt. Vergleicht<br />
man die Wahrscheinlichkeitsmatrix des MCUMs (d.h. das operationelle Profil)<br />
mit der des Testkettenmodells, nähern sie sich mit der Anzahl der Testläufe einander an.<br />
Jeder gefundene Fehler verlangsamt diese Annäherung, sie vollzieht sich schneller, je<br />
weniger Fehler entdeckt werden. Betrachtet man die Differenz der zwei Matrizen als Maß<br />
für den Testfortschritts, kann das Unterschreiten einer vorgegebenen Differenz als Stoppkriterium<br />
für das Testen dienen.<br />
Die beschriebene Berechnung der Zuverlässigkeit besitzt den Nachteil, dass vor der Testdurchführung<br />
implizit ein Startwert von 1, also hundertprozentige Zuverlässigkeit angenommen<br />
wird. Dies kann schnell nachvollzogen werden: Vorinitialisiert besitzt das Testkettenmodell<br />
ausschließlich Transitionswahrscheinlichkeiten von null. Entlang eines feh-<br />
j<br />
j<br />
end<br />
81
82<br />
Q.E.D. – Testentwurfsprozess<br />
lerfrei getesteten Pfades berechnen sich diese nach Formel 1 zu eins. Nach Formel 2 wird<br />
anschließend die hundertprozentige Zuverlässigkeit berechnet.<br />
Erst auftretende Fehler bei der Testausführung reduzieren diesen Wert. Enthält das SUT<br />
nur wenige Fehler oder werden nur wenige Testfälle ausgeführt, sind fehlerfreie Testläufe<br />
wahrscheinlich und die Berechnung liefert diesen unrealistischen Wert.<br />
Nach Miller [MMN+92] und Sayre [Say99] lässt sich die Fehlerrate von Software durch<br />
eine Standard Beta-Verteilung beschreiben. Im Folgenden beschreibt die Zufallsvariable<br />
Fij die Fehlerrate des Zustandsübergangs von si zu sj, ij<br />
ij<br />
R = 1 − F ist die Wahrscheinlich-<br />
keit für den fehlerfreien Zustandswechsel von si nach sj. Der Erwartungswert der Zufallsvariablen<br />
Fij lässt sich demnach durch den Mittelwert der Beta-Verteilung angeben:<br />
f ( si<br />
, s j ) + a(<br />
si<br />
, s j )<br />
E(<br />
Fij<br />
) =<br />
f ( s , s ) + s(<br />
s , s ) + a(<br />
s , s ) + b(<br />
s , s )<br />
i<br />
j<br />
i<br />
Formel 3 Einführung der Miller-Parameter<br />
s(si,sj): Anzahl der erfolgreichen Transitionsübergänge von Zustand si zu Zustand sj<br />
f(si,sj): Anzahl der fehlerhaften Transitionsübergänge von Zustand si zu Zustand sj<br />
a(si,sj) und b(si,sj): a-priori Information über die Transition von Zustand si zu Zustand sj<br />
Die Parameter a(si,sj) und b(si,sj) werden als „Miller-Parameter“ bezeichnet und können<br />
dazu genutzt werden, vorhandenes Wissen oder aus Erfahrung abgeleitete Vermutungen<br />
in die Berechnung einfließen zu lassen. Ist z.B. bekannt, dass die Transition zwischen den<br />
Zuständen si und sj eine niedrige Fehlerrate aufweist, kann der Wert von a(si,sj) niedrig<br />
auf 1 und der Wert für b(si,sj) auf einen höheren Wert von 10 gesetzt werden. Dieses Zahlenbeispiel<br />
würde für zehn fiktiv durchgeführte und erfolgreich durchlaufene Testfälle<br />
stehen. Ist für eine Transition keine Information vorab bekannt, so werden beide Parameter<br />
mit dem Standardwert 1 belegt.<br />
Die Einführung der „Miller-Parameter“ bringt mehrere Vorteile mit sich. So liegt der<br />
Startwert der Softwarezuverlässigkeit vor Durchführung eines Testfalls standardmäßig<br />
bei 50 Prozent. Dies erlaubt eine bessere Zuverlässigkeitsaussage auch ohne Auffinden<br />
von Fehlern. Zum zweiten erlauben die Parameter das Einbringen von vorhandenem Wissen.<br />
Beide Effekte führen nach [Say99] zu einem schnelleren Konvergieren des berechneten<br />
an den realen Wert.<br />
j<br />
i<br />
j<br />
i<br />
j
Markov Chain Usage Model<br />
Importance Sampling<br />
In [WPT95] beschreiben Walton, Poore und Trammell einen generellen Nachteil des statistischen<br />
Testens mit einem MCUM. Die Testfälle werden ausschließlich nach dem Kriterium<br />
der Auftretenswahrscheinlichkeiten im realen Betrieb ausgewählt. Dies ermöglicht<br />
zwar eine erwartungstreue Abschätzung der erreichten Zuverlässigkeit, vernachlässigt<br />
jedoch andere wichtige Kriterien bei der Testfallauswahl wie die Fehleranfälligkeit und<br />
das Fehlerrisiko, also die unterschiedlichen Kosten, die durch Fehler verursacht werden.<br />
Seltene Ereignisse mit hohen Folgekosten im Fehlerfall werden so wenig getestet.<br />
Sie beschreiben dafür drei mögliche Lösungen. Die eine ist das Erstellen eines weiteren<br />
Benutzermodells für seltene, aber kritische Operationen. Zweitens schlagen sie das unabhängige<br />
manuelle Testen dieser Operationen vor. Drittens ist die Verwendung eines verschobenen<br />
operationellen Profils möglich, welches die Traversierung kritischer Pfade im<br />
MCUM begünstigt. Dies geht jedoch mit dem Verlust der Abschätzbarkeit der Systemzuverlässigkeit<br />
einher.<br />
Gutjahr beschreibt in [Gut97] eine mögliche Lösung dieses Problems durch die Anwendung<br />
des – aus der Simulation bekannten – „Importance Samplings“. Dazu wird der Kostenfaktor<br />
q eingeführt, der die Höhe der von einem Fehler verursachten Folgekosten darstellt<br />
und individuell für jede Transition angegeben werden kann. Damit verschieben sich<br />
die Wahrscheinlichkeiten des operationellen Profils gemäß des Vorschlags in [WPT95],<br />
es entsteht das sog. Testprofil. Nach [Gut95] werden die darin enthaltenen Transitions-<br />
TP<br />
wahrscheinlichkeiten p ( si<br />
, s j ) wie folgt berechnet:<br />
p<br />
TP<br />
( s , s ) =<br />
i<br />
j<br />
p<br />
OP<br />
i<br />
OP<br />
∑ p<br />
su<br />
, sv<br />
∈S<br />
( s , s ) q(<br />
s , s )<br />
u<br />
j<br />
( s , s ) q(<br />
s , s )<br />
Formel 4 Berechnung des Testprofils<br />
TP<br />
p ( si<br />
, s j ) : Transitionswahrscheinlichkeit von Zustand si zu Zustand sj im Testprofil<br />
OP<br />
p ( si<br />
, s j ) : Transitionswahrscheinlichkeit von Zustand si zu Zustand sj im op. Profil<br />
q : Kostenfaktor für Übergang von Zustand si zu Zustand sj<br />
( si<br />
, s j )<br />
S : Menge aller Modellzustände<br />
Testfälle, die aus einem MCUM auf Basis eines Testprofils generiert werden, eignen sich<br />
aufgrund der Verschiebung offensichtlich nicht mehr zur Abschätzung der erreichten<br />
v<br />
i<br />
u<br />
j<br />
v<br />
83
84<br />
Q.E.D. – Testentwurfsprozess<br />
Zuverlässigkeit. Vor deren Abschätzung muss das Testergebnis daher durch eine Gewichtung<br />
zurück verschoben werden. Nach [Gut97] kann diese Gewichtung mit dem sog. likelihood-Quotienten<br />
erfolgen:<br />
E )<br />
OP<br />
E ( F ) = E(<br />
F<br />
ij<br />
ij<br />
)<br />
TP<br />
p<br />
p<br />
OP<br />
TP<br />
( s , s<br />
i<br />
( s , s<br />
Formel 5 Rückberechnung der mittleren Fehlerrate<br />
OP<br />
( Fij<br />
: Mittl. Fehlerrate der Transition von Zustand si zu Zustand sj mit dem op. Profil<br />
E )<br />
TP<br />
( Fij<br />
: Mittl. Fehlerrate der Transition von Zustand si zu Zustand sj mit dem Testprofil<br />
Der errechnete Erwartungswert der Fehlerrate auf Basis des Testprofils wird mit dem<br />
Quotienten aus der Original- und der getesteten Wahrscheinlichkeit multipliziert. Gutjahr<br />
zeigt, dass das resultierende Ergebnis der erwartungstreuen Zuverlässigkeitsabschätzung<br />
entspricht.<br />
Damit ist es im Rahmen des Q.E.D.-Ansatzes möglich, die Benutzungszuverlässigkeit<br />
abzuschätzen, a-priori Wissen über die Softwarefehleranfälligkeit einzubringen und Systeme<br />
mit Operationen unterschiedlicher Risikoklassen zu testen.<br />
4.3 Testfallgenerierung<br />
Das „Marcov Chain Usage Model“ (MCUM) bildet als Testmodell den Kern des Testentwurfprozesses,<br />
es stellt die Quelle für die Testfallgenerierung dar. Dieses Unterkapitel<br />
widmet sich der Erzeugung der Testfälle, diese entsprechen einer Nachrichtensequenz auf<br />
einem möglichen Pfad vom Start- zum Endzustand des Automatenmodells.<br />
Beim statistischen Test erzeugt man Testfälle für zwei unterschiedliche Phasen der Testausführung.<br />
Zunächst werden Testfälle aus nicht zufälligen Modelltraversierungen erzeugt<br />
und ausgeführt. Beispiele hierfür sind Testfälle zur Abdeckung aller Zustände bzw.<br />
Übergänge oder zur Überprüfung einer bestimmten Funktionalität. Dies hilft bei der Validierung<br />
des MCUMs und dient zur Erfüllung von Vertragsbedingungen. In die Gewinnung<br />
der Zuverlässigkeitsaussage, die in Kapitel 4.2.4 vorgestellt wurden, gehen die Testergebnisse<br />
dieser Testphase nicht ein.<br />
i<br />
j<br />
j<br />
)<br />
)
Testfallgenerierung<br />
Im Anschluss daran wird der eigentliche statistische Test durchgeführt. Die Testfälle<br />
werden bezüglich der im MCUM enthaltenen Auftretenswahrscheinlichkeiten zufällig<br />
erzeugt und ausgeführt. Der Test spiegelt somit das tatsächliche bzw. vermutete spätere<br />
Nutzungsverhalten wider und erlaubt die Abschätzung der erreichten Zuverlässigkeit des<br />
Systems (siehe Kapitel 4.2.4).<br />
Nichtdeterministisches & paralleles Verhalten<br />
Die Erzeugung eines Testfalls weicht in zwei Fällen von der Grundregel des einfachen<br />
Modellpfads ab. Bei Zuständen mit mehreren ausgehenden Transitionen mit identischen<br />
Stimuli verhält sich das System nichtdeterministisch. Das bedeutet, dass für eine Systemeingabe<br />
mehrere unterschiedliche korrekte Reaktionen auftreten dürfen. Abbildung 43<br />
zeigt beispielhaft das Triggern des SUT mit einer Nachricht und zwei spezifizierten korrekten<br />
Antworten OK und NOT_OK.<br />
Abbildung 43 Nichtdeterminismus<br />
Die Beachtung nur eines Pfades im Testfall kann das Testergebnis verfälschen. Es ist<br />
daher notwendig, alle entsprechenden Folgepfade als alternative mögliche Fortsetzungen<br />
zu übernehmen. Im ungünstigen Fall kann das den Umfang des erzeugten Testfalls stark<br />
erhöhen, was z.B. durch eine „on-the-fly“-Generierung umgangen werden könnte. In diesem<br />
Fall würde der jeweils nächste Testschritt erst zur Testlaufzeit generiert werden, entsprechend<br />
der beobachteten Systemreaktion. Zur Realisierung müsste das gesamte<br />
MCUM zur Ausführung gebracht werden, was z.B. durch eine Übersetzung in die<br />
TTCN-3 möglich wäre.<br />
Die zweite Ausnahme zur Grundregel ist der Fall parallelen Verhaltens. Dies wird im<br />
MCUM durch einen orthogonalen zusammengesetzten Zustand beschrieben.<br />
85
86<br />
Abbildung 44 Paralleles Verhalten<br />
Q.E.D. – Testentwurfsprozess<br />
Abbildung 44 zeigt zwei, in der UML2 durch eine gestrichelte Linie angedeutete, Regionen<br />
mit jeweils einer Sub-Zustandsmaschine. Für die Testfallgenerierung müssen alle<br />
enthaltenen Zustandsmaschinen durchlaufen werden.<br />
Synchronisierung<br />
Bei Testkonfigurationen mit mehreren Testkomponenten muss für deren Synchronisierung<br />
gesorgt werden, um eine korrekte Sendereihenfolge zu gewährleisten. Dies gilt nicht<br />
nur für verteilte Tests, sondern auch für lokale Tests mit mehreren Prozessen bzw.<br />
Threads. Die Notwendigkeit zur Synchronisierung verdeutlicht folgendes Beispiel.<br />
Abbildung 45 Synchronisierung<br />
Abbildung 45 links zeigt ein zu testendes Verhalten. Darin wird für die Systeminstanz<br />
gefordert, dass zunächst die Nachrichten m1 und m2 mit der Benutzerinstanz User_1,<br />
danach die Nachrichten n1 und n2 mit der Instanz User_2 ausgetauscht werden. Weiter-
Erzeugung der Testsuite<br />
hin legt die partielle Ordnungsrelation der Sequenzdiagramme die zeitliche Reihenfolgen<br />
m2 nach m1 und n2 nach n1 fest.<br />
Die Freiheitsgrade liegen bei den Sendeereignissen der Nachrichten m1 und n1 und den<br />
Empfangsereignissen der Nachrichten m2 und n2, deren Reihenfolgen nicht festgelegt<br />
sind. Im vorliegenden Beispiel sind demnach folgende sechs Sendesequenzen erlaubt:<br />
(m1, m2, n1, n2), (m1, n1, n2, m2), (m1, n1, m2, n2), (m1, n2, m1, m2), (n1, m1, m2, n2),<br />
(n1, m1, n2, m2). Um die definierte Ereignisreihenfolge auf der Systeminstanz zu garantieren,<br />
ist daher der Austausch von Synchronisierungsnachrichten notwendig.<br />
Die Abbildung 45 rechts zeigt den resultierenden Testfall. Die spezielle Komponente<br />
MTC signalisiert mit dem Versenden der Nachricht sync_ack, welche Testkomponente<br />
eine Aktion durchführen darf. Der Empfang einer Nachricht wird durch eine sync-<br />
Meldung an die MTC-Komponente quittiert.<br />
Auch für diese Regel existiert ein Ausnahmefall. Für gefordertes paralleles Verhalten<br />
wird keine zusätzliche Synchronisierung benötigt, da keine explizite Nachrichtenabfolge<br />
definiert ist. Dies erzeugt die geforderte nichtdeterministische Verschränkung der beteiligten<br />
Nachrichten.<br />
4.4 Erzeugung der Testsuite<br />
Die generierten Testfälle beschreiben das Verhalten des Testsystems, zur Vervollständigung<br />
einer Testsuite muss auch dessen Struktur, also die Testkonfiguration, festgelegt<br />
werden. Für jede modellierte Benutzerinstanz wird eine Testkomponente erzeugt. Zusätzlich<br />
wird eine weitere Komponente zur Erfüllung folgender drei Aufgaben benötigt:<br />
(1) Berechnung des finalen Testurteils. (2) Synchronisierung aller erstellten Testkomponenten.<br />
(3) Protokollieren der Testausführung. Letzteres ist wichtig, um einen fehlerhaften<br />
Testschritt identifizieren zu können. Dazu benötigt sie von den Testkomponenten ihre<br />
zur Laufzeit erzeugten Testurteile. Um das Verschicken zusätzlicher Nachrichten zu vermeiden,<br />
lässt sich diese Information z.B. als Parameter in den Synchronisierungsnachrichten<br />
weitergeben.<br />
Jede Benutzerkomponente besitzt daher neben einer Kommunikationsverbindung zum<br />
„System Under Test“ einen zusätzlichen Port zu dieser Testkomponente. Das folgende<br />
UML2-Kompositionsstrukturdiagramm stellt eine Beispielkonfiguration mit drei Benutzer-Testkomponenten<br />
dar:<br />
87
88<br />
Abbildung 46 Beispiel-Testkonfiguration<br />
Q.E.D. – Testentwurfsprozess<br />
Die folgende Abbildung 47 fasst alle Bestandteile zur Beschreibung eines Tests als Paket<br />
zusammen, die darin enthaltenen Stereotypen entsprechen dem „UML2 Testing Profile“<br />
(U2TP) [OMG05a] (siehe Kapitel 3.7.3). Das Paket enthält die zur Abbildung 46 gehörenden<br />
Testkomponenten und den Testkontext, bestehend aus der Testkonfiguration, zehn<br />
Testfällen und dem Attribut verdict für das Testurteil.<br />
Abbildung auf die TTCN-3<br />
Abbildung 47 Beispiel-TestPackage<br />
Zur Ausführung muss der Test in eine ausführbare Sprache übersetzt werden, für U2TPkonforme<br />
Testsuiten existiert keine weitere Werkzeugunterstützung. Bei der Entwicklung
Erzeugung der Testsuite<br />
der U2TP wurde jedoch auf verbreitete Testsprachen und -konzepte Rücksicht genommen.<br />
Die Abbildung auf die TTCN-3 gelingt problemlos, der Standard [OMG05a] enthält<br />
neben Beschreibungen für das Mapping auch ausführliche Konzeptvergleiche. In [SG02]<br />
wird die größere Ausdrucksstärke der TTCN-3 im Vergleich zur U2TP beschrieben mit<br />
dem Ergebnis, dass ein vollständiges Mapping in Richtung der TTCN-3 möglich ist, jedoch<br />
nicht umgekehrt.<br />
Eine ausführliche Beschreibung der TTCN-3 findet sich in Kapitel 2.3. Jede Benutzerinstanz<br />
wird auf eine parallele Testkomponente (PTC) der TTCN-3 abgebildet. Die Sonderaufgaben<br />
der Synchronisierung, des Protokollierens und der Bildung des finalen Testurteils<br />
übernimmt die Haupt-Testkomponente (MTC).<br />
Die TTCN-3-Testkonfiguration entspricht der Konfiguration in der U2TP. Die MTC besitzt<br />
einen Port zu allen PTCs, letztere realisieren das eigentliche Verhalten der Testfälle<br />
über Ports zum getesteten System.<br />
Abschließend fehlen datenbezogene Informationen, d.h. die eigentlichen Testdaten müssen<br />
definiert, Datentypen und Templates müssen beschrieben werden (Beispiel siehe Kapitel<br />
2.3.5).<br />
Wie in Kapitel 2.3.8 beschrieben, können die nicht-funktionalen Anforderungen der Testfälle<br />
nur schlecht auf die TTCN-3 abgebildet werden, dazu sind ihre Mittel für die Zeitbehandlung<br />
zu ungenau. Dagegen ist eine Abbildung in die TimedTTCN-3 [Neu04] (siehe<br />
Kapitel 2.3.8) möglich, insbesondere durch das in ihr enthaltene Uhrenkonzept zur<br />
Abfrage der absoluten Zeit.<br />
Neben einer Konzeptbeschreibung enthält [Neu04] auch Entwurfsmuster zum Testen von<br />
Antwortzeiten, Latenzzeiten und Durchsatzanforderungen in der TimedTTCN-3. Der Test<br />
weicher Zeitgrenzen und der Test statistischer Verteilungen sind nicht beschrieben, jedoch<br />
auch möglich. In der TimedTTCN-3 lassen sich Algorithmen implementieren, die<br />
komplexere Berechnungen auf einer Menge von Zeitstempeln durchführen. Deren Ergebnisse<br />
können direkt in die Bildung eines Testurteils einfließen.<br />
Abbildung 48 stellt TimedTTCN-3 Code zum Test der Verteilungsfunktions-Anforderung<br />
in Abbildung 31 dar. Zwei Nachrichten werden zwanzigmal mit der SUT ausgetauscht,<br />
deren Antwortzeiten in einem Array gespeichert werden. Zusammen mit der Angabe der<br />
geforderten Verteilungsfunktion und Parametern wird die Auswertefunktion aufgerufen.<br />
89
90<br />
function user_function1() runs on user_type {<br />
var float respTime[], parameters[];<br />
var float timestamp1, timestamp2;<br />
var integer s, t;<br />
Q.E.D. – Testentwurfsprozess<br />
for(s := 0, t := 0; s < 20; s := s+1, t := t+1) {<br />
user_type2sut.send(ICONreq);<br />
timestamp1 := self.now;<br />
user_type2sut.receive(ICONconf);<br />
timestamp2 := self.now;<br />
respTime[t] := timestamp2 – timestamp1;<br />
}<br />
parameters[0] := 0.5;<br />
setverdict(eval_Kol_Smi(exponential, parameters, respTime));<br />
}<br />
function eval_Kol_Smi(distribution dist, float param_array, float<br />
time_array) {<br />
… // Kolmogorov-Smirnov test<br />
}<br />
Abbildung 48 Test einer Verteilungsfunktions-Anforderung<br />
In ihr kann ein Algorithmus eines klassischen „goodness-of-fit“ Tests implementiert sein.<br />
Neben des hier angedeuteten Kolmogorov-Smirnov-Tests gehören der Anderson-Darling-<br />
und der Chi-Quadrat-Test zu bekannten Verfahren, die zum Testen einer Verteilungsfunktions-Anforderung<br />
anwendbar sind [LK00]. Dazu empfiehlt sich die Bereitstellung verschiedener<br />
Auswertefunktionen in einer Funktionsbibliothek.<br />
Die beschriebenen Transformations- und Generierungsschritte sind automatisierbar, per<br />
Hand muss die Schnittstelle zwischen Testsystem und dem getesteten System implementiert<br />
werden. Ihre Realisierung ist stark von der jeweiligen Systemimplementierung abhängig,<br />
Hauptaufgabe dieser Schnittstelle ist die Umwandlung der Daten in die jeweils<br />
andere Repräsentation. Für die TTCN-3 existiert eine standardisierte API, das „TTCN-3<br />
Runtime Interface“ [ETS07b].<br />
Die abstrakte TTCN-3 Testsuite (ATS) ist damit vollständig beschrieben, Standardwerkzeuge<br />
für die TTCN-3 können diese in eine ausführbare Version (ETS) kompilieren und<br />
unter einer graphischen Oberfläche benutzerfreundlich ausführen.
Zusammenfassung<br />
4.5 Zusammenfassung<br />
Der Q.E.D.-Entwurfsprozess beschreibt die Möglichkeit, ausgehend von Szenarienbeschreibungen<br />
Testfälle zu erstellen, die es ermöglichen, aus den Testergebnissen Rückschlüsse<br />
auf die erreichte Softwarezuverlässigkeit zu ziehen.<br />
Möglich wird dies durch die Erstellung eines speziellen Testmodells, des „Markov Chain<br />
Usage Models“. Für dessen Erstellung wird in diesem Kapitel eine detaillierte Abbildungsvorschrift<br />
gegeben, die alle erlaubten Elemente der UML2-Sequenzdiagramme berücksichtigt.<br />
Nach der Betrachtung sinnvoller Zeit- und Leistungsanforderungen für den<br />
Black-Box-Test wird auch für diese die Abbildung auf das MCUM beschrieben. Schließlich<br />
wurde über die Semantikunterschiede diskutiert, die zwischen der Spurensemantik<br />
der Szenarien und der Testmodellsemantik des MCUMs auftreten. Dabei wurde festgestellt,<br />
dass zwar Differenzen existieren, diese jedoch zu akzeptieren sind (siehe Kapitel<br />
4.2.3).<br />
Bei der Testfallgenerierung aus dem MCUM wurde auf die benötigte Synchronisierung<br />
zwischen verschiedenen Testkomponenten aufmerksam gemacht. Für deren Regelung<br />
tauschen diese mit einer Kontrollinstanz Synchronisierungsnachrichten aus. Ebenso werden<br />
zwei Sonderfälle betrachtet (nichtdeterministisches und paralleles Verhalten), die bei<br />
der Testfallerzeugung gesondert behandelt werden müssen.<br />
Zur Testausführung wird im Q.E.D.-Prozess eine Testsuite in der Testsprache TTCN-3<br />
erzeugt. Für den Test von Zeit- und Leistungsanforderungen existiert eine Erweiterung<br />
der Sprache, die TimedTTCN-3, mit der auch das Testen von weichen Zeitgrenzen möglich<br />
ist. Für komplexere Auswertefunktionen von statistischen Vorgaben wird die Bereitstellung<br />
von Funktionsbibliotheken vorgeschlagen.<br />
Für die Auswertung der Testergebnisse wurden existierende Algorithmen beschrieben.<br />
Neben der Abschätzung der erreichten Benutzungszuverlässigkeit kann auch vorab vorhandenes<br />
Wissen über die Fehleranfälligkeit in die Berechnung mit einfließen. Schließlich<br />
lässt sich mit Hilfe der „Importance Sampling“-Technik auch Software mit verschiedenen<br />
Fehlerklassen auswerten.<br />
91
92<br />
Q.E.D. – Testentwurfsprozess
5 Anwendungsstudie DECT<br />
Alle Transformations- und Generierungsschritte des Q.E.D.-Ansatzes wurden im Rahmen<br />
dieser Arbeit implementiert. Die daraus entstandene Werkzeugkette konnte an einer realen<br />
Fallstudie erprobt werden [Bie06].<br />
Die Projektgruppe CCIOS (Competence Center for InterOperative Systems) des Fraunhofer<br />
Instituts für Integrierte Schaltungen stellte für diese Studie sechs DECT-Funkmodule<br />
M5 aus eigener Entwicklung zur Verfügung. DECT [ETS99] steht für „Digital Enhanced<br />
Cordless Telephony“ und ist ein Standard der ETSI (European Telecommunications<br />
Standards Institute) für die drahtlose Sprach- und Datenübertragung.<br />
DECT Funkmodul M5<br />
Das DECT Modul M5 stellt eine Basisplattform für die Entwicklung kundenspezifischer<br />
Produkte dar. Es kann sowohl im DECT-Frequenzbereich um 1,9 GHz funken als auch im<br />
ISM-Bereich um 2,4 GHz. Bis zu fünf Verbindungen können gleichzeitig aufgebaut werden,<br />
werden diese gebündelt, wird eine Datenrate von 160 kbit/s erreicht. Sprachkonferenzen<br />
sind mit bis zu fünf Teilnehmern möglich. Das Datenübertragungsprotokoll ist auf<br />
niedrige Verzögerungszeiten optimiert, Antennendiversität ist bei der Feststation („fixed<br />
part“, FP) oder beim Mobilteil („portable part“, PP) möglich, um auch unter ungünstigen<br />
Empfangsbedingungen sicheren Betrieb zu gewährleisten.<br />
Der Zugriff auf das Funkmodul ist über eine AT-Modem-Schnittstelle und über ein neu<br />
entwickeltes „DECT Host Controller Interface“ (DHCI) möglich. In der vorliegenden<br />
Fallstudie wurden die DECT-Module über das DHCI getestet.<br />
Das DHCI ist eine Schnittstelle zwischen dem Funkmodul und dem Host bzw. dem Benutzer.<br />
Darüber lassen sich sowohl Benutzerdaten als auch Signalisierungsinformationen<br />
zur Steuerung des DECT-Systems übertragen. Die genaue Schnittstellenspezifikation<br />
kann in [Stu05] nachgelesen werden.<br />
Die Module sind konfigurierbar, um sowohl als FP als auch als PP zu fungieren. Es wurden<br />
zwei verschiedene Testkonfigurationen verwendet. Die eine bestand aus zwei Basisstationen<br />
und zwei Mobilteilen, für erweiterte Testfälle kamen zwei weitere Mobilteile<br />
hinzu. Die maximale Testkonfiguration bestand demnach aus sechs DECT-Modulen bzw.<br />
sechs Testkomponenten (siehe Abbildung 49).<br />
93
94<br />
Werkzeugkette<br />
Abbildung 49 Testkonfiguration DECT-Fallstudie<br />
Anwendungsstudie DECT<br />
Für jeden benötigten Transformations- und Generierungsschritt wurde ein Werkzeug für<br />
die Automatisierung implementiert. Die Basisrepräsentation jedes Modells war das Standardaustauschformat<br />
der UML, die XMI in der Version 2.0 [OMG05c] (siehe Kapitel<br />
3.5). Da es sich dabei um eine XML-Notation handelt, kamen für die Implementierung<br />
der Werkzeugkette Sprachen mit guter XML-Unterstützung in Betracht.<br />
Die „Extensible Stylesheet Language Transformation“ (XSLT) [W3C99] ist als Sprache<br />
zur Manipulation von XML-<strong>Dokument</strong>en von der W3C („World Wide Web Consortium“)<br />
standardisiert. Die XSLT beschreibt die Transformation eines XML-<strong>Dokument</strong>s in<br />
ein anderes XML-<strong>Dokument</strong> oder in ein beliebig anderes Format.<br />
Ihre Verwendung bringt zwei Vorteile. Zum einen werden die nötigen Transformationsschritte<br />
ebenso in Form eines wohldefinierten XML-<strong>Dokument</strong>s beschrieben. Zum zweiten<br />
muss keine vollständige Anwendung implementiert werden, es genügt, Regeln anzugeben,<br />
in welcher Form das Quell- in ein Zielformat umzuwandeln ist. Dies vereinfacht<br />
ihre kaskadierte Anwendung in einer Toolkette.
Anwendungsstudie DECT<br />
JDOM 1 stellt eine API für die objekt-orientierte Programmiersprache Java dar. Es ermöglicht<br />
den einfachen Zugriff, die Manipulation und die Ausgabe von XML-<strong>Dokument</strong>en<br />
aus Java Code heraus. Bei vorhandener Kenntnis der Sprache Java bleibt der Implementierer<br />
somit in seiner gewohnten Programmierumgebung. Des Weiteren steht die gesamte<br />
Bibliotheksvielfalt von Java zur Verfügung, um erweiterte Funktionen während der<br />
Transformation durchzuführen.<br />
Als Modellierungswerkzeug für die UML wurde IBM Rational Software Architect (RSA) 2<br />
Version 6.0 gewählt, welches das Austauschformat XMI in der Version 2.0 unterstützt.<br />
Ein Problem der XMI war und ist das Fehlen einer Referenzimplementierung. Ein Ergebnis<br />
davon war das Entstehen von werkzeug- und herstellerspezifischen XMI-<br />
Implementierungen, die untereinander nur wenig kompatibel sind.<br />
Die stetig wachsende Eclipse-Gemeinschaft 3 , ein Open-Source-Vorhaben zur Bereitstellung<br />
einer einheitlichen Software-Entwicklungsplattform, trieb die Verbreitung der XMI<br />
2.0 voran. Eine wesentliche Komponente ihrer Plattform, das Eclipse Modeling Framework<br />
(EMF) 4 , welches Aufgaben zur Modellbearbeitung und Codegenerierung vereint,<br />
nutzt diese XMI-Version als kanonisches Speicherformat aller Modelle.<br />
Die Eclipse gründete ein UML2-Projekt 5 mit der Zielvorgabe, eine anwendbare Referenzimplementierung<br />
des UML2-Metamodells bereitzustellen, um die Entwicklung von Modellierungstools<br />
zu unterstützen. Die Verwendung eines gemeinsamen XMI-Schemas<br />
ermöglicht den Austausch von semantischen Modellen. Im Jahre 2004 veröffentlichte das<br />
Projekt ihre erste Implementierung des Metamodells der UML 2.0.<br />
Da das UML2-Projekt auf der EMF basiert, können UML-2.0-konforme Modelle erstellt<br />
und im – vom EMF unterstützten – XMI-2.0-Format serialisiert werden. Kommerzielle<br />
Tools von IBM und von Omondo 6 setzen auf die Implementierung des UML2-Projekts als<br />
Basisplattform.<br />
1 http://www.jdom.org<br />
2 http://www.ibm.de<br />
3 http://www.eclipse.org<br />
4 http://www.eclipse.org/emf/<br />
5 http://www.eclipse.org/uml2/<br />
6 http://www.omondo.de<br />
95
96<br />
Anwendungsstudie DECT<br />
Standardkonform ist dieses Speicherformat für die UML 2.x jedoch nicht, da die XMI 2.0<br />
auf MOF 1.4 basiert (siehe Kapitel 3.5). Seit Anfang 2006 unterstützt eine neue EMF<br />
Version 2.2 die für MOF 2.0 entwickelte Version XMI 2.1. Auch das UML2-Projekt veröffentlicht<br />
aktualisierte Versionen, so existieren bereits Vorversionen einer Metamodellimplementierung<br />
der UML 2.1 [OMG06a]. Die gesamte – in dieser Arbeit implementierte<br />
– Werkzeugkette verarbeitet Modelle im XMI-2.0-Format.<br />
Durchführung des Fallbeispiels<br />
Für die DECT-Module wurden ca. 230 Anforderungsszenarien definiert und im Tool RSA<br />
in Form von Sequenzdiagrammen beschrieben. Benutzerdefinierte Zustände in Form von<br />
Zustandsinvarianten können in der aktuellen Werkzeug-Version nicht modelliert werden,<br />
sie mussten daher nachträglich mit dem Baumeditor von Eclipse eingefügt werden. Zeit-<br />
und Leistungsanforderungen wurden in dieser Anwendungsstudie nicht beschrieben, da<br />
diese durch die Zielsprache TTCN-3, wie in Kapitel 2.3.8 beschrieben, nicht unterstützt<br />
werden. Für deren Erweiterung, die TimedTTCN-3, existiert noch keine Werkzeugunterstützung.<br />
Die folgenden Abbildungen wurden mit dem Werkzeug RSA erstellt.<br />
Abbildung 50 On-Air Subscription
Anwendungsstudie DECT<br />
Abbildung 50 zeigt exemplarisch die Durchführung einer „On-Air Subscription“, also<br />
eines Einlernvorgangs zwischen Mobilteil und Feststation über die Luftschnittstelle. Die<br />
Empfangsreihenfolge der Indication-Nachrichten vom System ist beliebig, die Nachrichten<br />
sind daher in einem parallelen Fragment modelliert.<br />
Für die Generierung des MCUM wurde der Algorithmus aus Kapitel 4.2.3 in Form von<br />
XSLT-Stylesheets implementiert [Sus05]. Ein XSLT-Prozessor wird mit der Quelldatei<br />
und den Transformationsregeln in den implementierten Stylesheets aufgerufen. Dies erzeugte<br />
beim Fallbeispiel eine UML-Protokollzustandsmaschine mit ca. 900 Zuständen,<br />
die Erstellungszeit lag bei 15 bis 20 Minuten. Die folgende Abbildung 51 stellt eine Skizze<br />
des resultierenden MCUM dar. Es enthält Zustände für verschiedene Sprach-, Daten-<br />
und kombinierte Verbindungen, für „Streaming“-Dienste und verschiedene Telefonkonferenz-Modi.<br />
Abbildung 51 DECT - MCUM<br />
Für das operationelle Profil kann durch ein XSLT-Stylesheet eine Adjazenzliste ausgegeben<br />
werden. Diese enthält die Zustände des MCUM und standardmäßig gleichverteilte<br />
Übergangswahrscheinlichkeiten. Die Liste kann bezüglich eines operationellen Profils<br />
angepasst werden und anschließend automatisch in das MCUM eingelesen werden. Zu<br />
97
98<br />
Anwendungsstudie DECT<br />
diesem Zweck wurde die XMI-Syntax für die Statechart-Transition um ein Attribut zur<br />
Aufnahme des Wahrscheinlichkeitswerts erweitert. Für die Anpassung der Gleichverteilung<br />
im Rahmen der Fallstudie gingen nach Gesprächen mit Entwicklern der DECT-<br />
Module deren Erfahrungen mit Vorgängerversionen ein.<br />
Für die Testfallgenerierung wurde zunächst ein weiteres Stylesheet implementiert. Es<br />
stellte sich jedoch heraus, dass auf Grund des rekursiven Charakters von XSLT die Modelltraversierung<br />
unerwartet zeitaufwändig war. Trotz 2 GB an Arbeitsspeicher im Testrechner<br />
kam es zu Abbrüchen aus Speichergründen, so kam es trotz manueller Erhöhung<br />
der Speicherzuweisung an die JavaVM zu häufigen Stapelüberläufen. Durch Evaluierung<br />
von Kombinationen verschiedener Betriebssysteme, XSLT-Prozessoren und Virtuellen<br />
Maschinen von Java wurde eine Erstellungszeit pro Testfall von ca. 5 Minuten erreicht.<br />
[Bie05] listet Details zu den durchgeführten Experimenten auf. Eine Reimplementierung<br />
des Prozesses für die Testfallgenerierung in Java mit JDOM brachte mit 1 Minute pro<br />
Testfall eine Geschwindigkeitsoptimierung [Kol06].<br />
Abbildung 52 Beginn eines Testfalls
Anwendungsstudie DECT<br />
Testfälle lassen sich durch zufällige Traversierung oder mit dem Ziel einer Zustands-<br />
bzw. Transitionsüberdeckung erzeugen. In Abbildung 52 ist der Beginn eines Testfalls<br />
mit automatisch eingefügten Synchronisierungsnachrichten (siehe Kapitel 4.3) zu sehen.<br />
Ein weiteres XSLT-Stylesheet steht zur Verfügung, um nach den Regeln gemäß Kapitel<br />
4.4 eine TTCN-3-Testsuite zu erzeugen [Li05]. Ca. 200 Testfälle wurden erzeugt und<br />
übersetzt, die Testsuite um benötigte Dateninformationen und die Schnittstelle zur DHCI<br />
ergänzt. Das Werkzeug Telelogic Tau G2 1 kompilierte die komplette Testsuite in eine<br />
ausführbare Form in ca. drei Stunden. Pro Testfall erzeugte der Compiler 3-20 MB C-<br />
Code. Neben der Testfalllänge war insbesondere das Auflösen vorhandener interleave-<br />
Anweisungen (siehe Kapitel 2.3.6) für die Codegröße verantwortlich.<br />
Die Testausführung förderte zehn Fehler unterschiedlichen Typs zu Tage. Unter anderem<br />
wurden falsche Werte in den Nachrichtenfeldern erkannt. Ein Beispiel ist die Statusabfrage<br />
der aufgebauten Verbindungen mittels der CON_STATE+REQ-PDU, die mit einem<br />
falschen „MBC“-Wert beantwortet wurde. Dieser gibt die Anzahl der Slots für Daten-<br />
und Streamingverbindungen wieder.<br />
Ein weiterer Fehlertyp war der Empfang einer – im aktuellen Zustand – nicht spezifizierten<br />
Nachricht. Im unsynchronisierten Zustand bekam das Mobilteil beispielsweise auf<br />
eine Anfrage zum Setzen eines Parameters zusätzlich zur spezifizierten Antwortnachricht<br />
eine Synchronisationsanzeige mit der Information „Out Of Sync“.<br />
Weiterhin ließ sich nach einer „On-Air Subscription“ keine Vierer-Konferenz aufbauen.<br />
Schließlich wurden mehrmals „On Air Subscriptions“ oder Verbindungsaufbauwünsche<br />
oder -abbauwünsche mit einem Timeout quittiert.<br />
Die Anwendbarkeit des Q.E.D.-Ansatzes wurde somit demonstriert. Weiterhin wurde ein<br />
Algorithmus zur Abschätzung der erreichten Benutzungszuverlässigkeit nach Whittaker<br />
und Thomason (siehe Kapitel 4.2.4) in Java implementiert [Shi05]. Leider verhinderte die<br />
zu diesem Zeitpunkt langwierige Erzeugung die Generierung einer aussagekräftigen Anzahl<br />
von Testfällen. So konnte nur eine Zustandsüberdeckung von unter zehn Prozent<br />
erreicht werden. Die Berechnung einer sinnvollen Zuverlässigkeitsabschätzung war unter<br />
diesen Umständen nicht möglich.<br />
1 http://www.telelogic.de<br />
99
100<br />
Fazit<br />
Anwendungsstudie DECT<br />
Die durchgeführte Anwendungsstudie zeigt die Einsatzfähigkeit des Q.E.D.-Ansatzes im<br />
realen Umfeld. Durch den Einsatz der implementierten Werkzeugkette waren nur wenige<br />
manuelle Eingriffe nötig, um aus Szenarienbeschreibungen in der UML2 statistische Testfälle<br />
in der TTCN-3 zu erzeugen und auszuführen.<br />
Ein Problem stellte die schlechte Performanz der Testfallerzeugung mit Hilfe des XSLT-<br />
Stylesheets dar, so dass die Berechnung einer sinnvollen Zuverlässigkeitsaussage mit der<br />
erreichten niedrigen Zustandsüberdeckung nicht möglich war. Eine schnellere Version in<br />
Java wurde erst mit Abgabe dieser Arbeit fertig gestellt. Eine Möglichkeit zur Umgehung<br />
des Performanzproblems stellt zudem die „on-the-fly“-Generierung dar, bei der im Vorfeld<br />
keine Testfälle erzeugt werden müssen. Stattdessen würde während der Testausführung<br />
jeweils nur der nächste Testschritt erzeugt werden. Dies würde jedoch zu Lasten<br />
möglicher Regressionstests gehen, also die Wiederholung bereits durchgeführter Testfälle<br />
erschweren.
6 Zusammenfassung<br />
In dieser Arbeit wurde der Q.E.D.-Testentwurfsprozess vorgestellt, eine systematische<br />
Vorgehensweise zur Erzeugung von statistischen Testfällen. Der Prozess zeichnet sich<br />
durch mehrere Merkmale aus:<br />
Zum einen ist der Prozess szenarienbasiert, d.h. den Ausgangspunkt bilden Szenarien, die<br />
in Form von Objektinteraktionen Anforderungen an ein System beschreiben. Ein weiteres<br />
Kennzeichen ist die Verwendung von aktuellen Sprachstandards, die in ihren Domänen<br />
eine hohe Bedeutung besitzen. So findet der Großteil des Entwurfprozesses innerhalb der<br />
UML2 statt, dem de-facto-Standard für die modellgestützte Softwareentwicklung. Als<br />
dedizierte Testsprache dient die TTCN-3, die einzige standardisierte Notation für diese<br />
wichtige Phase des Softwareentwurfs. Die statistische Auswahl der Testfälle ermöglicht<br />
es auf Basis der Testergebnisse Aussagen über die erreichte Systemzuverlässigkeit aus<br />
Benutzersicht zu treffen. Diese Metrik unterstützt den Entscheidungsprozess bezüglich<br />
einer Systemfreigabe.<br />
Die Idee des szenarienbasierten statistischen Tests hat ihren Ursprung im europäischen<br />
IST Projekt „Markov Test Logic“ (MaTeLo) [BD03, BD04, DZ03]. Darin wurden einfache<br />
Szenarien als „Message Sequence Charts“ betrachtet, die in ein Modell mit einer eigenentwickelten<br />
Beschreibungssprache übersetzt wurden, um statistische Testfälle zu<br />
erzeugen.<br />
Im Q.E.D.-Entwurfsprozess wird konsequent auf die UML2 gesetzt, ihre große Verbreitung<br />
fördert sowohl das Verständnis als auch die Anwendbarkeit des Ansatzes. Zur Beschreibung<br />
der Anforderungsszenarien dienen die Sequenzdiagramme, deren voller<br />
Sprachumfang unterstützt wird. So sind auch komplexere Beschreibungen möglich, die<br />
durch unterschiedliche Kombination einfacher Szenarien entstehen können. Außerdem<br />
wurden relevante Zeit- und Leistungsaspekte diskutiert, die während des Black-Box-Tests<br />
evaluiert werden können. Dazu gehören Antwort- und Latenzzeiten, der Durchsatz und<br />
die Überprüfung von Nachrichtenankunftszeiten auf eine geforderte Verteilung hin. Auf<br />
die Notwendigkeit der Synchronisierung verschiedener Testkomponenten wird eingegangen.<br />
Es wird eine Vorschrift für den Austausch von Synchronisierungsnachrichten gegeben,<br />
mit der die Einhaltung der korrekten Sende- und Empfangsreihenfolge gewährleistet<br />
wird. Außerdem wurden die Sonderfälle von nichtdeterministischem und parallelem Ver-<br />
101
102<br />
Zusammenfassung<br />
halten identifiziert, bei denen der generierte Testfall vom einfachen Pfad im Testmodell<br />
abweicht.<br />
Zur Demonstration der Anwendbarkeit wurden alle benötigten Transformations- und<br />
Auswertungsschritte prototypisch in einer Werkzeugkette implementiert und in einer realen<br />
Fallstudie eingesetzt.<br />
6.1 Ausblick<br />
Aus Sicht des Entwurfsprozesses wäre eine weitere Fokussierung auf die UML denkbar<br />
und wünschenswert, indem die TTCN-3 als eingesetzte Testsprache obsolet werden würde.<br />
Die implementierte Werkzeugkette generiert bereits eine Testsuite in der UML2 (vgl.<br />
Kapitel 4.4), welche jedoch aus mehreren Gründen in die TTCN-3 übersetzt wird. Zum<br />
einen ist das Testprofil der UML2 ausdrucksschwächer, es gibt keine standardisierten<br />
Schnittstellen, und es fehlt im Gegensatz zur TTCN-3 die Werkzeugunterstützung für die<br />
Testausführung.<br />
Ein weiterer Punkt betrifft den Zeitpunkt der Testfallgenerierung. Wie in Kapitel 4.3 diskutiert,<br />
werden die Testfälle vollständig vor der Testausführung erzeugt. Dieser Generierungsvorgang<br />
ist zwar zeitunkritisch, er kann jedoch zum Speicherproblem führen, da<br />
durch die nötige Beachtung aller nichtdeterministischer Systemreaktionen sehr große<br />
Testfälle entstehen. Eine mögliche Lösung wäre ein ausführbares Testmodell, also z.B.<br />
die Übersetzung des gesamten MCUM in die TTCN-3. Der jeweils nächste Testschritt<br />
könnte „on-the-fly“ erst während der Testausführung generiert werden und so der speicherintensive<br />
Vorgang der Generierung vollständiger Testfälle umgangen werden.<br />
Außerdem ist für die Evaluierung der geforderten Zeit- und Leistungsvorgaben eine<br />
Werkzeugunterstützung für die TimedTTCN-3 wünschenswert. Zur Überprüfung von<br />
statistischen Anforderungen wäre, wie in Kapitel 4.4 beschrieben, der Aufbau einer Bibliothek<br />
sinnvoll, in der verschiedene Auswertefunktionen zur Verfügung gestellt werden.<br />
Damit würde auch das Testen erweiterter Leistungsanforderungen größere Verbreitung<br />
erfahren.
Abbildungsverzeichnis<br />
Abbildung 1 V-Modell, nach [Bal98] ................................................................................. 6<br />
Abbildung 2 Modellbasiertes Testen – Szenarien, nach [PP05] ....................................... 10<br />
Abbildung 3 „Model Driven Testing“ [ZDS+05] ............................................................. 16<br />
Abbildung 4 Benutzersicht auf die TTCN-3 [ETS07a]..................................................... 19<br />
Abbildung 5 Allgemeine Struktur eines TTCN-3 Testsystems, nach [ETS07c]............... 19<br />
Abbildung 6 Allgemeines verteiltes TTCN-3 Testsystem, nach [ETS07c] ...................... 21<br />
Abbildung 7 Typische TTCN-3 Testkonfiguration [ETS07a] .......................................... 21<br />
Abbildung 8 Anweisung für alternatives Verhalten.......................................................... 24<br />
Abbildung 9 INRES - Protokoll ........................................................................................ 25<br />
Abbildung 10 INRES - Testfall......................................................................................... 26<br />
Abbildung 11 Vier-Ebenen Hierarchie der UML, nach [OMG07b] ................................. 37<br />
Abbildung 12 Die Rolle des „Core“-Pakets im MOF-Umfeld [OMG07b]....................... 38<br />
Abbildung 13 UML2-Diagrammtypen, nach [JRH+04] ................................................... 39<br />
Abbildung 14 Protokolltransition...................................................................................... 42<br />
Abbildung 15 XMI in der Vier-Ebenen-Hierarchie, nach [Jec04] .................................... 43<br />
Abbildung 16 Ordnungsbeziehung.................................................................................... 47<br />
Abbildung 17 Interaktionsreferenz.................................................................................... 48<br />
Abbildung 18 Dekomposition ........................................................................................... 48<br />
Abbildung 19 Zustandsinvarianten.................................................................................... 49<br />
Abbildung 20 Ausführungsfocus....................................................................................... 49<br />
Abbildung 21 SPT-Profil Struktur [OMG05b].................................................................. 51<br />
Abbildung 22 SPT - Time Modeling [OMG05b].............................................................. 52<br />
Abbildung 23 SPT - Performance Modeling [OMG05b].................................................. 53<br />
Abbildung 24 Syntax der Zeitwerte .................................................................................. 55<br />
Abbildung 25 MARTE – Subprofile [OMG05e] .............................................................. 56<br />
Abbildung 26 Q.E.D.-Testentwurfsprozess....................................................................... 59<br />
Abbildung 27 Use-Case-Diagramm .................................................................................. 62<br />
Abbildung 28 Antwortzeit - Anforderung........................................................................ 63<br />
Abbildung 29 Latenz - Anforderung ................................................................................. 64<br />
Abbildung 30 Durchsatz - Anforderung............................................................................ 64<br />
Abbildung 31 Verteilungsfunktions - Anforderung .......................................................... 65<br />
Abbildung 32 Einfaches MCUM....................................................................................... 67<br />
Abbildung 33 Ordnungsrelation........................................................................................ 70<br />
Abbildung 34 Auflösung des „ignore“-Fragments............................................................ 72<br />
103
104<br />
Abbildungsverzeichnis<br />
Abbildung 35 Transformation - Basisregeln ..................................................................... 73<br />
Abbildung 36 Zustandsmaschine des INRES-Protokolls.................................................. 74<br />
Abbildung 37 Transformation - Konkatenation ................................................................ 74<br />
Abbildung 38 Transformation - Kombinierte Fragmente (Teil 1) .................................... 75<br />
Abbildung 39 Transformation - Kombinierte Fragmente (Teil 2) .................................... 76<br />
Abbildung 40 Transformation – SPT-Annotation............................................................. 77<br />
Abbildung 41 Erweitertes Use-Case-Diagramm............................................................... 78<br />
Abbildung 42 Zusammengesetztes MCUM ...................................................................... 78<br />
Abbildung 43 Nichtdeterminismus.................................................................................... 85<br />
Abbildung 44 Paralleles Verhalten.................................................................................... 86<br />
Abbildung 45 Synchronisierung........................................................................................ 86<br />
Abbildung 46 Beispiel-Testkonfiguration......................................................................... 88<br />
Abbildung 47 Beispiel-TestPackage ................................................................................. 88<br />
Abbildung 48 Test einer Verteilungsfunktions-Anforderung ........................................... 90<br />
Abbildung 49 Testkonfiguration DECT-Fallstudie........................................................... 94<br />
Abbildung 50 On-Air Subscription ................................................................................... 96<br />
Abbildung 51 DECT - MCUM.......................................................................................... 97<br />
Abbildung 52 Beginn eines Testfalls ................................................................................ 98
Literatur<br />
[AKW+02] A. Avritzer, J. Kondek, E. J. Weyuker et.al.. Software Performance<br />
Testing Based on Workload Characterization, In: Proceedings of WOSP<br />
02, Rom, Juli 2002<br />
[AW95] A. Avritzer, E. J. Weyuker. The Automatic Generation of Load Test<br />
Suites and the Assessment of the Resulting Software. IEEE Transac-<br />
tions on Software Engineering, Vol. 21, No. 9, September 1995<br />
[Bal98] H. Balzert. Lehrbuch der Software-Technik, vol. 2, Spektrum Akademi-<br />
scher Verlag, Heidelberg, Berlin, Oxford, 1998<br />
[BD03] M. Beyer, W. Dulz. Scenario-Based Statistical Testing of Quality-of-<br />
Service Requirements, Scenarios: Models, Transformations and Tools.<br />
International Workshop, Dagstuhl, September 2003<br />
[BD04] M. Beyer. QED - A Framework for QoS-Enhanced Development based<br />
on the UML and TTCN-3. Interner Bericht. <strong>Erlangen</strong>: <strong>Friedrich</strong>-<br />
<strong>Alexander</strong>-<strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg. Februar 2004<br />
[BDD+01] M. Birbeck, J. Diamon, J. Duckett et.al.. Professional XML 2nd Edition,<br />
Wrox Press Verlag, 2001<br />
[BDH06] M. Beyer, W. Dulz, K.-S. Hielscher. Performance Issues in Statistical<br />
Testing, In: Proceedings of the Conference on Measurement, Modeling<br />
and Evaluation of Computer and Communication Systems (MMB),<br />
Nürnberg, März 2006<br />
[BFG+99] M. Bozga, J-C. Fernandez, L. Ghirvu et.al.. IF: An intermediate repre-<br />
sentation and validation environment for timed asynchronous systems.<br />
In: Proceedings of the World Congress on Formal Methods in the De-<br />
velopment of Computing Systems, Volume I (FM 1999), Springer Ver-<br />
lag, 1999<br />
[Bie05] M. Biegel. Statistisches Testen von DECT-Modulen, Diplomarbeit,<br />
Institut für Informatik 7, <strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg, November<br />
2005<br />
[Bie06] M. Biegel. Statistical Testing of DECT modules, In: Proceedings of the<br />
MMB Workshop, Model-Based Testing, Nürnberg, März 2006<br />
105
106<br />
Literatur<br />
[Bir97] A. Birolini. Zuverlässigkeit von Geräten und Systemen, Springer Ver-<br />
lag, Berlin, Heidelberg, New York, 1997<br />
[BJK+05] M. Broy, B. Jonsson, J.-P. Katoen, et. al.. „Model-Based Testing of<br />
Reactive Systems”, Springer LNCS 3472. 2005<br />
[Coc00] A. Cockburn. Writing Effective Use Cases, Addison-Wesley, Oktober<br />
2000<br />
[DH01] W. Damm, D. Harel. LSCs: Breathing Life into Message Sequence<br />
Charts, Formal Methods in System Design, Kluwer Academic Publish-<br />
ers, 19, 45-80, 2001<br />
[DIN94] DIN ISO 9000-4. Normen zu Qualitätsmanagement und zur Darlegung<br />
von Qualitätsmanagementsystemen; Leitfaden zum Management von<br />
Zuverlässigkeitsprogrammen, Beuth Verlag, Berlin, Juni 1994<br />
[DN84] J. W. Duran, S. C. Ntafos. “An evaluation of random testing”, IEEE<br />
Transactions on Software Engineering, Vol. 10, No. 4, Juli 1984<br />
[Dou04] B. P. Douglass. Real Time UML Third Edition, Addison-Wesley, 2004<br />
[DZ03] W. Dulz, F. Zhen. „MaTeLo - Statistical Usage Testing by Annotated<br />
Sequence Diagrams, Markov Chains and TTCN-3”, Third International<br />
Conference on Quality Software (QSIC 2003), Dallas, Texas , Novem-<br />
ber 6-7 2003<br />
[ECM+99] A. S. Evans, S. Cook, S. Mellor et.al. Advanced Methods and Tools for<br />
a Precise UML, In: 2nd International Conference on the Unified Model-<br />
ing Language. Editors: B.Rumpe and R.B.France, Colorado, LNCS<br />
1723, 1999.<br />
[ETS07a] ETSI. Methods for Testing and Specification (MTS); The Testing and<br />
Test Control Notation version 3; Part 1: TTCN-3 Core Language, ES<br />
201 873-1 V3.2.1, Februar 2007<br />
[ETS07b] ETSI. Methods for Testing and Specification (MTS); The Testing and<br />
Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface<br />
(TRI), ES 201 873-5 V3.2.1, Februar 2007<br />
[ETS07c] ETSI. Methods for Testing and Specification (MTS); The Testing and<br />
Test Control Notation version 3; Part 6: TTCN-3 Control Interface<br />
(TCI), ES 201 873-6 V3.2.1, Februar 2007<br />
[ETS99] ETSI. Digital Enhanced Cordless Telecommunications (DECT); Com-<br />
mon Interface (CI); Part 1: Overview, EN 300 175-1, Juni 1999
Literatur<br />
[FHP02] E. Farchi, A. Hartman, S. S. Pinter. Using a Model-based Test Genera-<br />
tor to Test for Standard Conformance, IBM System Journal - special is-<br />
sue on Software Testing. Volume 41(1) (2002), S. 89 - 110.<br />
[GJV96] Erich Gamma, Ralph Johnson, John Vlissides. "Entwurfsmuster - Ele-<br />
mente wiederverwendbarer objektorientierter Software", Addison-<br />
Wesley 1996, ISBN 3-8273-1862-9<br />
[GKO+00] Y. Gurevich, P. Kutter, M. Odersky et.al.. Abstract State Machines:<br />
Theory and Applications, Lecture Notes in Computer Science, vol.<br />
1912, Springer Verlag, 2000<br />
[GM02] H. L. Guen, R. Marie. “Visiting Probabilities in Non-Irreducible<br />
Markov Chains with Strongly Connected Components”, European<br />
Simulation Multiconference: Modelling and Simulation 2002, Darm-<br />
stadt, Juni 2002<br />
[GNS+94] J. Grabowski, R. Nahm, A. Spichiger, et. al.. Die SAMSTAG Methode<br />
und ihre Rolle im Konformitätstesten, Praxis der Informationsverarbei-<br />
tung und Kommunikation (PIK) Heft 4/94, Dezember 1994, S. 214-224<br />
[Gut95] W. J. Gutjahr. Optimal Test Distributions for Software Failure Cost<br />
Estimation, Department of Statistics, Operations Research and Com-<br />
puter Science, <strong>Universität</strong> Wien, 1995<br />
[Gut97] W. J. Gutjahr. Importance Sampling of Test Cases in Markovian Soft-<br />
ware Usage Models, Department of Statistics, Operations Research and<br />
Computer Science, <strong>Universität</strong> Wien, 1997<br />
[Gut00] W. J. Gutjahr. Software Dependability Evaluation Based on Markov<br />
Usage Model, Department of Statistics, Operations Research and Com-<br />
puter Science, <strong>Universität</strong> Wien, 2000<br />
[Har04] A. Hartman. AGEDIS – Final Project Report. http://www.agedis.de,<br />
Februar 2004<br />
[Har87] D. Harel. Statecharts: A Visual Formalism for Complex Systems, Sci-<br />
ence of Computer Programming 8, 231-274. Elsevier. 1987<br />
[HD03] A. Hartman, K. Dussa-Ziegler. TorX: Automated Model-Based Testing,<br />
J. Tretmans, E. Brinksma Editors, First European Conference on Model-<br />
Driven Software Engineering, Nürnberg, 2003<br />
107
108<br />
[HHR+05] Ø. Haugen, K. E. Husa, R. K. Runde et. al.. STAIRS towards formal<br />
design with sequence diagrams, Software & System Modeling (So-<br />
SyM), 2005<br />
Literatur<br />
[Hog91] D. Hogrefe. OSI Formal Specification Case Study: The INRES Protocol<br />
and Service. Technical Report IAM-91-012, <strong>Universität</strong> Bern, Mai 1991<br />
[Hol91] G. J. Holzmann. Design and Validation of Protocols. Prentice-Hall<br />
Software Series, 990157918X, 1991<br />
[IEC98] IEC 61508-4, Funktionale Sicherheit sicherheitsbezogener elektri-<br />
scher/elektronischer/programmierbarer elektronischer Systeme - Teil 4:<br />
Begriffe und Abkürzungen, 1998<br />
[IEE90] IEEE. 610.12-1990 IEEE Standard Glossary of Software Engineering<br />
Terminology, 1990<br />
[ISO88] ISO. LOTOS – A formal description technique based on the temporal<br />
ordering of observational behaviour, International Standard 8807, Sep-<br />
tember 1988<br />
[ISO89] ISO. Estelle – Formal Description Technique Based on an Extended<br />
State Transition Model, International Standard 9074, 1989<br />
[ISO92] ISO. ISO/IEC JTC 1/SC 21, Information Technology - Open Systems<br />
Interconnection - Conformance Testing Methodology and Framework.<br />
International Multipart Standard 9646, 1992<br />
[ITU03] ITU-T, Draft Recommendation Z.152, Use Case Map Notation, Version<br />
3.0, September 2003<br />
[ITU96] ITU-T. Recommendation Z.120, Message Sequence Chart, 1996<br />
[ITU99] ITU-T. Recommendation Z.100, Specification and Description Lan-<br />
guage, November 1999<br />
[Jec04] M. Jeckle. OMG’s XML Metadata Interchange Format XMI, In: Pro-<br />
ceedings of the 1st Workshop of German Informatics Society e.V. (GI)<br />
in conjunction with the 7th GI Conference “Modellierung 2004“, Mar-<br />
burg, März 2004<br />
[JJ02] C. Jard, T. Jéron. TGV: Theory, principles and algorithms, In: Proceed-<br />
ings of the 6th World Conference on Integrated Design and Process<br />
Technology (IDPT 2002), Juni 2002<br />
[JRH+04] M. Jeckle, C. Rupp, J. Hahn et.al.. UML2 glasklar, Hanser Verlag,<br />
München, 2004
Literatur<br />
[Kel76] R. M. Keller. Formal verification of parallel programs, Communications<br />
of the ACM, Vol. 19, Issue 7, Juli 1976<br />
[Kol06] A. K. Kolla. Generation of a U2TP-compatible Test Suite from a UML<br />
2.0 Markov Chain Usage Model, Master Thesis, Institut für Informatik<br />
7, <strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg, Mai 2006<br />
[KT01] C. Kallepalli, J. Tian. “Measuring and Modeling Usage and Reliability<br />
for Statistical Web Testing”, IEEE Transactions on Software Engineer-<br />
ing, Vol. 27, No. 11, November 2001<br />
[Li05] J. Li. Test Suite-Erzeugung aus UML2.0-Modellen, Diplomarbeit, Insti-<br />
tut für Informatik 7, <strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg, August 2005<br />
[LK00] A. M. Law, W. D. Kelton. Simulation Modeling and Analysis, Third<br />
Edition, McGraw-Hill Companies, 2000<br />
[MK99] J. Magee, J. Kramer. Concurrency: State Models & Java Programs. John<br />
Wiley & Sons, 1999<br />
[MMN+92] K. W. Miller, L. J. Morell, R. E. Noonan et.al.. Estimating the Probabil-<br />
ity of Failure When Testing Reveals No Failures, IEEE Transactions on<br />
Software Engineering, Vol. 18, No. 1, Januar 1992<br />
[MMN+92] K. W. Miller, L. J. Morrell, R. E. Noonan et.al.. Estimating the prob-<br />
ability of failure when testing reveals no failures, IEEE Transactions on<br />
Software Engineering, Vol. 18, No. 1, Januar 1992<br />
[Mus93] J. D. Musa. Operational Profiles in Software-Reliability Engineering,<br />
IEEE Software, März 1993<br />
[Mus98] J. D. Musa. Software Reliability Engineering Testing, McGraw-Hill<br />
Education, 1998<br />
[Mye79] G. Myers. The Art of Software Testing, Wiley Verlag, 1979<br />
[Neu04] H. W. Neukirchen. Languages, Tools and Patterns for the Specification<br />
of Distributed Real-Time Tests. Dissertation, <strong>Universität</strong> Göttingen,<br />
2004<br />
[OMG03] Object Management Group. MDA Guide Version 1.0.1, omg/03-06-01,<br />
Juni 2003<br />
[OMG05a] Object Management Group. UML Testing Profile, version 1.0, for-<br />
mal/05-07-07, Juli 2005<br />
[OMG05b] Object Management Group. UML Profile for Schedulability, Perform-<br />
ance and Time Specification, version 1.1, formal/05-01-02, Januar 2005<br />
109
110<br />
Literatur<br />
[OMG05c] Object Management Group. XML Metadata Interchange (XMI) Specifi-<br />
cation, version 2.0, formal/05-05-01, Mai 2005<br />
[OMG05d] Object Management Group. MOF 2.0/XMI Mapping Specification,<br />
version 2.1, formal/05-09-01, September 2005<br />
[OMG05e] Object Management Group. UML Profile for Modeling and Analysis of<br />
Real-Time and Embedded systems (MARTE), RfP, realtime/05-02-06,<br />
Februar 2005<br />
[OMG06a] Object Management Group. Unified Modeling Language: Superstruc-<br />
ture, version 2.1, ptc/2006-04-02, April 2006<br />
[OMG06b] Object Management Group. Meta Object Facility (MOF) Core Specifi-<br />
cation, version 2.0, formal/06-01-01, Januar 2006<br />
[OMG06c] Object Management Group. Unified Modeling Language: Infrastructure,<br />
version 2.0, formal/05-07-05, März 2006<br />
[OMG06d] Object Management Group. Diagram Interchange, version 1.0, for-<br />
mal/06-04-04, April 2006<br />
[OMG06e] Object Management Group. Object Constraint Language, version 2.0,<br />
formal/06-05-01, Mai 2006<br />
[OMG06f] Object Management Group. Unified Modeling Language: Infrastructure,<br />
version 2.1, ptc/06-04-03, April 2006<br />
[OMG07a] Object Management Group. Unified Modeling Language: Superstruc-<br />
ture, version 2.1.1, formal/2007-02-05, Februar 2007<br />
[OMG07b] Object Management Group. Unified Modeling Language: Infrastructure,<br />
version 2.1.1, formal/07-02-06, Februar 2007<br />
[OMG07c] Object Management Group. A UML Profile for MARTE, Beta 1,<br />
ptc/07-08-04, August 2007<br />
[PP05] A. Pretschner, J. Philipps. Methodological Issues in Model-Based Test-<br />
ing, M. Broy et al. (Eds.): Model-Based Testing of Reactive Systems,<br />
LNCS 3472, pp. 281-291. Springer-Verlag Berlin Heidelberg 2005<br />
[Pro00] S. J. Prowell. TML: a description language for Markov chain usage<br />
models, Information and Software Technology, 42 (2000)<br />
[PTL+99] S. J. Prowell, C. J. Trammell, R. C. Linger et.al.. Cleanroom Software<br />
Engineering – Technology and Process, Addison-Wesley, Februar 1999<br />
[RJB04] J. Rumbaugh, I. Jacobson, G. Booch. The Unified Modeling Language<br />
Reference Manual, Second Edition, Addison-Wesley, 2004
Literatur<br />
[Say99] K. Sayre. “Improved Techniques for Software Testing Based on<br />
Markov Chain Usage Models”, Dissertation, University of Tennessee,<br />
Knoxville, Dezember 1999<br />
[SD04] R. Schieber, F. Derichsweiler. Testautomatisierung in der Automobilin-<br />
dustrie, SIGS-DATACOM, Objekt Spektrum April 2004,<br />
[SEG00] M. Schmitt, M. Ebner, J. Grabowski. Test Generation with Autolink and<br />
TestComposer. In: Proceedings of the 2nd Workshop of the SDL Forum<br />
Society on SDL and MSC, Grenoble (France), 2000<br />
[SG02] I. Schieferdecker, J. Grabowski. The Graphical Format of TTCN-3 in<br />
the context of MSC and UML, Telecommunications and beyond: The<br />
Broader Applicability of SDL and MSC (Editor: E. Sherratt). Proceed-<br />
ings of the Third International Workshop on SDL and MSC (SAM<br />
2002), Aberystwyth, UK, Juni 2002<br />
[Shi05] J. Shi. Statistische Auswertung von Testergebnissen, Studienarbeit,<br />
Institut für Informatik 7, <strong>Universität</strong> <strong>Erlangen</strong>-Nürnberg, Oktober 2005<br />
[SL03] A. Spillner, T. Linz. Basiswissen Softwaretest, dpunkt Verlag Heidel-<br />
berg, 2003<br />
[SP00] K. Sayre, J. H. Poore. “Partition Testing With Usage Models”, Informa-<br />
tion and Software Technology, Vol. 42, No. 12, 2000<br />
[SSR97] I. Schieferdecker, B. Stepien, A. Rennoch. PerfTTCN, a TTCN lan-<br />
guage extension for performance testing, 10th Intern. Workshop on<br />
Testing of Communicating Systems, IWTCS`97, Cheju Island, Korea,<br />
September 1997.<br />
[Stu05] Roland Sturm, DHCI Spezifikation, Version 01.05, 2005, Fraunhofer<br />
Institut für Integrierte Schaltungen, Abteilung Kommunikationssysteme<br />
[Sus05] O. Sushanskyy. Statistische Testfallgenerierung aus UML2.0 Interakti-<br />
onsdiagrammen, Diplomarbeit, Institut für Informatik 7, <strong>Universität</strong> Er-<br />
langen-Nürnberg, Januar 2005<br />
[TB02] J. Tretmans, E. Brinksma. Côte de Resyste – Automated Model Based<br />
Testing, Progress 2002 – 3rd Workshop on Embedded Systems, Okto-<br />
ber 2002<br />
[Tre96] J. Tretmans. Test Generation with Inputs, Outputs and Repetitive Qui-<br />
escence, Software – Concepts and Tools, 17(3):103-120, 1996<br />
111
112<br />
Literatur<br />
[Vee06] E. v. Veenendaal. Standard glossary of terms used in Software Testing,<br />
Version 1.2, Glossary Working Party, International Software Testing<br />
Qualification Board, 4. Juni 2006<br />
[VW98] F. I. Vokolos, E. J. Weyuker. Performance Testing of Software Sys-<br />
tems. Workshop on Software and Performance (WOSP98), Santa Fe,<br />
New Mexico, 1998<br />
[W3C04a] World Wide Web Consortium. Extensible Markup Language (XML) 1.0<br />
(Third Edition), W3C Recommendation 04 February 2004<br />
[W3C04b] World Wide Web Consortium. XML Schema Part 0: Primer Second<br />
Edition, W3C Recommendation 28 October 2004<br />
[W3C99] World Wide Web Consortium. XSL Transformations (XSLT) Version<br />
1.0, W3C Recommendation 16 November 1999<br />
[Wey03] E. J. Weyuker. “Using Operational Distributions to Judge Testing Pro-<br />
gress. In: Proceedings of the 2003 ACM symposium on Applied com-<br />
puting, 2003<br />
[WG99] T. Walter, J. Grabowski. A Framework for the Specification of Test<br />
Cases for Real Time Distributed Systems. Information and Software<br />
Technology, Vol. 41 (781-798), Juli 1999<br />
[WP00] G. H. Walton, J.H. Poore. “Generating transition probabilities to support<br />
model-based software testing”, Software-Practice and Experience, Vol.<br />
30, 2000<br />
[WP93] J. A. Whittaker, J. H. Poore. “Markov Analysis of Software Specifica-<br />
tions”, ACM Transactions on Software Engineering and Methodology,<br />
Vol. 2, No. 1, Januar 1993<br />
[WPT95] G. H. Walton, J. H. Poore, C. J. Trammell. “Statistical Testing of Soft-<br />
ware Based on a Usage Model”, Software-Practice and Experience, Vol.<br />
25, No. 1, Januar 1995<br />
[WT94] J. A. Whittaker, M. G. Thomason. “A Markov Chain Model for Statisti-<br />
cal Software Testing”, IEEE Transactions on Software Engineering,<br />
Vol. 20, No. 10, Oktober 1994<br />
[WV00] E. J. Weyuker, F. I. Vokolos. Experience with Performance Testing of<br />
Software Systems: Issues, an Approach and Case Study. IEEE Transac-<br />
tions on Software Engineering, Vol. 26, No. 12, Dezember 2000
Literatur<br />
[ZDS+05] J. Zander, Z. R. Dai, I. Schieferdecker, et.al.. From U2TP Models to<br />
Executable Tests with TTCN-3 – An Approach to Model Driven Test-<br />
ing, IFIP 17th Intern. Conf. on Testing Communicating Systems - Test-<br />
Com 2005, Montreal, Canada, ISBN: 3-540-26054-4, Mai 2005<br />
113