Allgemeines

• mit 1 Prozess inkl. Multi-Threading: JA
• mit n Prozessen: ?!?

Implementierung flacher Statecharts

Wie implementiert man jetzt die Statechart-Bilder?

• Klassen finden: Zustand, Transition, etc.
• technisch: codieren in C -->
  • anstelle von Klassen werden Strukturen verwendet
  • anstelle von Methoden werden Operationen auf der Datenstruktur definiert
  • Kapselung fehlt

Timer

• Annahme: separater, paralleler Timer-Service verwaltet die Timer
• pro Timer T gibt es:
  • eine Aktion setT: bei Aufruf "aus der Spezifikation" wird der Timer T gestartet
  • ein Ereignis elapsedT: sobald der Timer T abgelaufen ist, tritt das Ereignis "in der Spezifikation" auf
• die entsprechenden Datenstrukturen sind komplett vorgegeben

z.B. struct sctransition

Anmerkungen:

• Strukturdefinition (aus pragmatischen Gründen) etwas anders als bei todolib.h:
  struct sctransition { ... };
  anstatt typedef sctransition struct { ... };
  praktischer Unterschied: man muß immer struct dazuschreiben
• Zeiger auf Feld vs. Feld von Zeigern:
  • Feld von Zeigern auf int-Werte: int *intPointerArray[];
  • Zeiger auf ein Feld von int-Werten: int (*pIntArray)[];
  • Zeiger auf ein Feld von Zeigern auf int-Werte: int *(*pIntPointerArray)[];
• Verwendung von Funktionszeigern (function pointer):
  1. Herkömmliche Funktion:
     int myfunction (float p1, int p2) { ... }
  2. Deklaration eines Zeigers auf eine Funktion mit Parameterliste (float,int) und Rückgabewert int namens "pMyfunction":
     int (*pMyfunction)(float,int);
     
  3. Zuweisung der Adresse von myfunction zu pMyfunction:
     pMyfunction = &myfunction;
     
  4. Aufruf der Funktion, auf die pMyfunction zeigt:
     int result = (*pMyfunction)(17.3, 99);

Zustandsbasiertes Testen

Idee

• pro paralleler Komponente (d.h. pro Statechart) eine abstrakte Maschine (Checker)
• Simulation des jeweiligen Statecharts (sclib verwenden)
• parallel läuft der Testling
• Outputs schreiben beide in separate Kopien
• Inputs (und Parameter) lesen beide parallel
• parallel dafür der Generator

Simulationsablauf

1. Aufbau der Datenstruktur (inkl. der Funktionen für die Guards und Actions)
2. Beginn beim Startzustand
3. Schleife über die Testlaufzeit ...
4. Immer, wenn im derzeitigen Zustand eine Transition möglich ist, wird diese simuliert.
5. Sonst wird gewartet.
6. Nach der Simulation einer Transition prüfen, ob der Testling das gleiche gemacht hat.
7. und weiter wie oben

Fragen

• Wie wartet man gescheit darauf, daß eine Transition freigeschaltet wird? @rttWaitCondition(...)
• Was ist, wenn mehrere Transitionen gleichzeitig freigeschaltet sind?
• Warum interessiert uns das für das PLS-Beispiel nicht?

Wie wird getestet?

Hinweise

• die Timer Tfsb und Trts sind in specs/timeservice.rts definiert