Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

forderungen bei der Testfallgenerierung ist wünschenswert, aber momentan noch Ziel umfangreicher
Forschung und für den Produktionseinsatz noch nicht verfügbar. Ähnliches gilt
auch für kontinuierliche Systeme: Teststrategien für kontinuierliche Systeme wären wünschenswert
(insbesondere, da die SysML derartige Konstrukte explizit unterstützt), sind
aber noch nicht in Form fertiger Produkte verfügbar.
(d) Modellierungsparadigma [UPL06, S. 7] - durch dieses Merkmal wird festgelegt, durch welchen
Modellierungsansatz das Modell erstellt wurde. Im Rahmen des zitierten Papiers fallen
UML und SysML-Modell in die Kategorie der Transitions-basierten Notationen (Zustandsmaschinen)
bzw. Datenfluss-basierten Notationen (Aktivitätsdiagramme).
(e) Testfallgenerierung [UPL06, S. 8/9] - hierbei wird unterschieden, wie Testfälle aus dem
Modell abgeleitet werden. Relevant für die hier angestellten Betrachtungen ist dabei nur
die Unterscheidung in manuelle und automatische Testfallgenerierung. Zur Erfüllung von
Ziel B muss das Werkzeug die automatische Generierung von Testfällen unterstützen.
6.4.5.3. Verfahren und Werkzeuge
Aus den Zielen in Abschnitt 6.4.5.1 und Taxonomie für die Testfallgenerierung im vorherigen
Abschnitt 6.4.5.2 lassen sich das im Folgenden beschriebene, prinzipielle Verfahren und Aussagen
zu den benötigten Werkzeugen ableiten.
Die Umsetzung von Ziel A ist unabhängig von der vorgestellten Taxonomie und erfolgt durch
die Verwendung eines modellbasierten Testausführungswerkzeuges. Dieses soll das Freischneiden
des Systems entlang der in der Systemabgrenzungssicht definierten Systemgrenze, die Stimulierung
des Systems mit den Eingabestimuli aus den Szenarien und die Aufzeichnung der
Reaktionen des Systems ermöglichen. Ein Beispiel für ein geeignetes Werkzeug für UML/SysML-
Umgebungen ist der TestConductor der OSC AG, der sich in IBM/telelogic Rhapsody integrieren
lässt [OSC08-1] und der im Rahmen dieser Arbeit verwendet wurde. Bei entsprechender sorgfältiger
Erstellung der Szenariensicht 4 können deren Diagramme direkt als Testfälle verwendet
werden. Auch die Testausführung erfolgt weitgehend automatisiert: Aus dem ausführbaren Modell
wird Quellcode erzeugt, dieser wird compiliert, ausgeführt und das Modell daraufhin den
in den Testfällen definierten Stimuli (in Form der auf das SuB zulaufenden Nachrichten) unterworfen.
Die Antworten des Modells werden vom TestConductor aufgezeichnet und mit den
in den Szenarien vorgegebenen Soll-Ausgaben (entsprechen den aus dem SuB herausströmenden
Nachrichten) verglichen. Das Ergebnis dieses Vergleichs bestimmt anschließend das Urteil
darüber, ob der Testfall bestanden wurde oder nicht.
Die Erreichung von Ziel B erfordert eine Analyse des tatsächlich vorliegenden Modellverhaltens
und eine darauf basierende automatische Testfallerstellung. Dabei muss das verwendete
Werkzeug die in 6.4.5.2 beschriebenen Merkmale erfüllen. Ein Beispiel für ein entsprechendes
Werkzeug ist ATG der OSC AG [OSC08-2], das sich, wie auch TestConductor, in IBM/telelogic
Rhapsody integrieren lässt. ATG ermöglicht die Analyse von UML/SysML-Modellen des zukünftigen
Systems (erfüllt Merkmal (a)), deren Verhalten in Form von Zustandsmaschinen oder
Aktivitätsdiagrammen definiert ist (erfüllt Merkmal (d)) und erzeugt anhand dieser Analyse innerhalb
des Modells Szenarien, die als Testfälle verwendet werden können (erfüllt Merkmal (b)
und (e)). Die hinter ATG stehende Algorithmik (die Grundlagen sind in [LET05] beschrieben)
versucht, für ein gegebenes Modell Sequenzen von Eingangsstimuli zu finden, die alle Zustände,
Transitionen, Ereignisaufrufe und Operationen in den Verhaltensdiagrammen anfahren. Ergebnis
des ATG-Laufs ist eine Menge an Szenarien, die in ihrer Charakteristik den manuell erstellten
4 Dies betrifft insbesondere die Verwendung korrekter Namen für Signale und Argumente
136