Entwicklung von Zustandsautomaten mit testgetriebener Entwicklung

Da Zustandsmaschinenmodelle in eingebetteten Systemen weit verbreitet sind, untersucht dieser Artikel verschiedene Strategien zur Entwicklung von Zustandsmaschinen-(SM-)Software unter dem Test-Driven-Development-(TDD)-Ansatz. Diese Veröffentlichung beginnt mit der Erläuterung grundlegender Zustandsmaschinenkonzepte und der TDD-Technik. Schließlich werden einfache und geordnete Methoden zur Entwicklung von in C geschriebener Zustandsmaschinensoftware unter Verwendung des TDD-Ansatzes vorgestellt.

Ein SM-Modell besteht aus Zuständen, Übergängen und Aktionen. Während ein Zustand ein Zustand eines Systems oder eines Elements ist, ist ein Übergang ein Weg von einem Zustand in einen anderen, der normalerweise durch ein interessierendes Ereignis eingeleitet wird, das einen Vorgänger-(Quell-)Zustand mit einem nachfolgenden (Ziel-)Zustand verbindet. Die tatsächlichen Verhaltensweisen, die vom Element ausgeführt werden, werden in Aktionen dargestellt.

In der UML-Zustandsmaschine können Aktionen mit dem Eintritt in einen Zustand, dem Verlassen eines Zustands, einem Übergang an sich oder einer sogenannten „internen Transition“ oder „Reaktion“ verbunden sein. Alle Formalismen eines Zustandsautomaten (einschließlich UML-Zustandsautomaten) gehen allgemein davon aus, dass ein Zustandsautomat die Verarbeitung jedes Ereignisses abschließt, bevor er mit der Verarbeitung des nächsten beginnen kann. Dieses Ausführungsmodell wird Run To Completion (RTC) genannt. In diesem Modell können Aktionen einige Zeit dauern, aber alle ausstehenden Ereignisse müssen warten, bis die Zustandsmaschine abgeschlossen ist – einschließlich der gesamten Ausgangsaktion, der Übergangsaktion und der Eingangsaktionssequenz in dieser Reihenfolge.

Bevor wir uns mit den Strategien zur Entwicklung von Zustandsautomaten unter Verwendung von TDD befassen, ist es wert, deren Definition, Bedeutung und Anwendung zu erwähnen.

Zunächst einmal ist TDD eine Technik zum inkrementellen Erstellen von Software. Einfach ausgedrückt, wird kein Produktionscode geschrieben, ohne zuerst einen fehlgeschlagenen Komponententest zu schreiben. Tests sind klein. Tests sind automatisiert. Test-Driving ist logisch, d. h. anstatt in den Produktionscode einzutauchen (das Testen für später aufzugeben), drückt der TDD-Praktiker das gewünschte Verhalten des Codes in einem Test aus. Sobald der Test fehlschlägt, schreibt der TDD-Praktiker den Code und macht den Test erfolgreich. Das Herzstück des TDD-Prozesses ist ein sich wiederholender Zyklus, der aus kurzen Schritten besteht, die als „TDD-Mikrozyklen“ bekannt sind.

Die Schritte des TDD-Zyklus in der folgenden Liste basieren auf James Grennings Buch „Test-Driven Development for Embedded C“:

• Füge einen kleinen Test hinzu.
• Führen Sie alle Tests aus und wenn der neue fehlschlägt, wird er möglicherweise nicht einmal kompiliert.
• Nehmen Sie die kleinen Änderungen vor, die zum Bestehen des Tests erforderlich sind.
• Führen Sie alle Tests durch und beweisen Sie, ob der neue Test besteht.
• Refactoring, um Duplikate zu entfernen und die Ausdruckskraft zu verbessern.

Lassen Sie uns das Diagramm in Abbildung 1 verwenden, um einen einfacheren Weg zu finden, um eine Zustandsmaschine mit TDD zu entwickeln. Wenn die Zustandsmaschine initialisiert wird, beginnt sie mit dem StateA Zustand. Sobald es das Alpha erhält Ereignis wechselt die Zustandsmaschine in den StateB Zustand, indem Sie die Aktionen xStateA(), effect() und nStateB() in dieser Reihenfolge ausführen. Wie kann man also den SM von Abbildung 1 testen, um festzustellen, ob er sich angemessen verhält?

Abbildung 1. Grundlegende Zustandsmaschine (Quelle:VortexMakes)

Die traditionellste und einfachste Methode zum Testen eines SM wie in Abbildung 1 besteht hauptsächlich darin, die Zustandsübergangstabelle des SMUT (State Machine Under Test) zu überprüfen. Dies macht einen Testfall pro Bundesstaat , in dem das SMUT durch die interessierenden Ereignisse stimuliert wird, um zu überprüfen, welche Übergänge ausgelöst werden. Gleichzeitig bedeutet dies, den Zielzustand und die ausgeführten Aktionen für jeden ausgelösten Übergang zu überprüfen. Wenn eine Aktion ausreichend komplex ist, ist es besser, dafür einen speziellen Testfall zu erstellen. (Der Artikel Testen von Zustandsautomaten mit Komponententests erläutert diese Strategie ausführlich.)

Jeder Testfall ist nach xUnit-Mustern in vier verschiedene Phasen unterteilt:

• Einrichtung legt die Voraussetzungen für den Test fest, wie den aktuellen Zustand des SM (StateA ), das zu verarbeitende Ereignis (Alpha ) und die erwarteten Testergebnisse, die den Übergangszielzustand (StateB .) darstellen ) und die sortierte Liste der auszuführenden Aktionen (xStateA(), effect() und nStateB()).
• Übung stimuliert den Zustandsautomaten mit dem Alpha Veranstaltung.
• Bestätigen überprüft die erhaltenen Ergebnisse.
• Aufräumen bringt die zu testende Zustandsmaschine nach dem Test in ihren Anfangszustand zurück. Es ist optional.

Die oben erwähnte Strategie reicht aus, um ein SM mit TDD zu entwickeln. In einigen Fällen ist jedoch mehr als ein einzelner Übergang erforderlich, um die Funktionalität zu überprüfen. Dies liegt daran, dass der Effekt erst durch eine Aktionskette nachfolgender Transitionen sichtbar wird, was bedeutet, dass die Funktionalität eine Menge von Zuständen, Ereignissen und Transitionen des SMUT umfasst. In diesen Fällen ist es sinnvoller, ein vollständiges und funktionsfähiges Szenario zu testen, als isolierte Zustandsübergänge. Dadurch sind Testfälle funktionaler und weniger abstrakt als die zuvor genannten Strategien.

Lassen Sie uns die Zustandsmaschine in Abbildung 2 verwenden, um dieses Konzept zu untersuchen.

Abbildung 2. Die DoWhile-Zustandsmaschine (Quelle:VortexMakes)

Abbildung 2 zeigt eine Zustandsmaschine namens DoWhile, die eine Ausführungsschleife ähnlich der „do-while“-Schleife modelliert. DoWhile wurde mit dem Yakindu Statechart Tool gezeichnet. Die Aktionen „x =0“ und „output =0“ werden aufgerufen, wenn DoWhile erstellt wird und diese Aktionen setzen den Standardwert aller DoWhile-Attribute. Die Anzahl der Schleifeniterationen muss durch ‚x++‘ oder ‚x =(x> 0) ? x–:x’ Aktionen. Die Aktion „i =0“ legt Anfangsbedingungen für die Schleife fest. Der Schleifenkörper wird durch die Aktion ‚i++‘ ausgeführt, die die Schleifeniterationen aufrechterhält, dann wird die Beendigungsbedingung durch den Pseudozustand der Wahl durch den Wächter ‚i ==x‘ ausgewertet. Wenn es wahr ist, wird der Schleifenkörper erneut ausgewertet und so weiter. Wenn die Abbruchbedingung falsch wird, beendet die Schleife die Ausführung der Aktion ‚output =i‘.

Es ist hilfreich, eine Testliste zu erstellen, bevor Sie neue Funktionen entwickeln. Die Testliste leitet sich aus der Spezifikation ab und definiert die beste Vorstellung davon, was zu tun ist. Da es nicht perfekt sein muss, ist die erste Liste nur ein temporäres Dokument, das später geändert werden könnte. Die anfängliche Testliste für DoWhile ist unten dargestellt:

• Alle Daten werden standardmäßig eingestellt, nachdem SM initialisiert wurde
• X-Attribut erhöhen
• X-Attribut verringern
• Eine einzelne Iterationsschleife kann ausgeführt werden
• Eine Schleife mit mehreren Iterationen kann ausgeführt werden
• Eine Schleife ohne Iteration kann ausgeführt werden
• Überprüfen Sie die Werte außerhalb des zulässigen Bereichs

Um die DoWhile-Zustandsmaschine zu entwickeln, werden Ceedling und Unity zusammen mit der einfachsten, aber klarsten Programmiertechnik verwendet:der Verwendung von „switch-case“-Sätzen. Ceedling ist ein Build-System zum Generieren einer kompletten Test- und Build-Umgebung für ein C-Projekt; Unity ist ein leichtes, tragbares, ausdrucksstarkes C-Sprachtestgeschirr für C-Projekte.

Zwei Dateien stellen diese Zustandsmaschine dar, DoWhile.h und DoWhile.c, sie sind also der zu testende Quellcode. Code-Listing 1 zeigt ein Fragment der Datei test_DoWhile.c, die die obige Testliste durch Anwendung der zuvor erwähnten Strategie implementiert. Um diesen Artikel einfach zu halten, zeigt Code-Listing 1 nur den Testfall:  ‘Eine einzelne Iterationsschleife kann ausgeführt werden‘, der von test_SingleIteration() implementiert wird. Sowohl Code als auch Modell sind im https://github.com/leanfrancucci/sm-tdd.git-Repository verfügbar.

Codelisting 1:Einzeliterationstest (Quelle:VortexMakes)

Dieser Test überprüft, ob DoWhile nur eine Iteration korrekt ausführen kann. Dazu initialisiert test_SingleIteration() die DoWhile-Zustandsmaschine durch Aufrufen von DoWhile_init() (Zeile 96). Es legt die Iterationsnummer für Null fest, die von der DoWhile-Schleife ausgeführt werden soll. Danach ist die DoWhile bereit, Ereignisse zu verarbeiten, indem sie DoWhile_dispatch() aufruft. Um eine einzelne Iteration auszuführen, sendet test_SingleIteration() das Up -Ereignis an DoWhile (Zeile 97). Dieses Ereignis erhöht die Iterationsnummer auf eins. Der Test startet die Schleife durch Senden des Start Ereignis (Zeile 98), dann sendet es das Alpha -Ereignis, sodass DoWhile eine einzelne Iteration ausführt (Zeile 99). Dies wird überprüft, indem überprüft wird, ob der Wert des out-Attributs gleich der Anzahl der ausgeführten Iterationen ist (Zeile 101). Schließlich muss DoWhile im StateC bleiben Zustand (Zeile 102).

Um zu beweisen, dass DoWhile mehr als eine Iteration ausführen kann, wird test_SingleIteration() wie in Code-Listing 2 gezeigt erweitert.

Code Listing 2:Multiple Iteration Test (Quelle:VortexMakes)

Der in Codelisting 3 gezeigte test_NoneIteration()-Test überprüft, ob DoWhile beim Empfang eines Alpha . keine Iteration ausführt Ereignis, ohne zuvor die Iterationsnummer durch Up festzulegen Ereignisse.

Codelisting 3:Nicht-Iterationstest (Quelle:VortexMakes)

Obwohl die Implementierungsdetails von DoWhile nicht das Ziel dieses Artikels sind, zeigen Codelisting 4 und Codelisting 5 einen Teil der Dateien DoWhile.c und DoWhile.h. Diese Dateien stellen tatsächlich eine demonstrative Implementierung von DoWhile dar, die „switch-case“-Sätze in C verwenden.

Code-Listing 4:Fragment der DoWhile-Implementierung (Quelle:VortexMakes)

Code-Listing 5:Fragment der DoWhile-Spezifikation (Quelle:VortexMakes)

Beide oben vorgestellten Strategien bieten einfache und geordnete Methoden zur Entwicklung von Zustandsautomaten-Software mit TDD – einer der wichtigsten Ansätze zur Steigerung der Softwarequalität.

Die erste Strategie besteht hauptsächlich darin, die Zustandsübergangstabelle des SMUT zu verifizieren. Diese Methode  macht einen Testfall pro Bundesstaat . Die andere Strategie schlägt vor, einen Testfall für ein vollständiges und funktionsfähiges Szenario zu realisieren , die häufig eine Reihe von Zuständen, Ereignissen und Aktionen des SMUT umfasst. Diese zweite Strategie macht den Test funktionaler und weniger abstrakt als die erste. Obwohl diese Strategien unabhängig von einer bestimmten Art von System, Programmiersprache oder Werkzeug sind, sind sie in eingebetteten Systemen sehr nützlich, da viele von ihnen ein zustandsbasiertes Verhalten aufweisen, das typischerweise in einer oder mehreren Zustandsmaschinen definiert ist.

Die Sprache C wurde gewählt, weil sie eine der beliebtesten Sprachen für die Entwicklung eingebetteter Software ist. Um TDD in dieser Sprache anzuwenden, wurden Ceedling und Unity gewählt. Zusammenfassend lässt sich sagen, dass diese Methoden es Entwicklern definitiv ermöglichen, auf einfachere und geordnetere Weise eine viel flexiblere, wartbare und wiederverwendbare Software zu entwickeln als herkömmliche Ansätze.