Finite-State-Maschinen sind vielleicht eines der grundlegendsten und am weitesten verbreiteten Konzepte in der Programmierung. Finite-State-Maschinen (KA) werden in vielen angewandten Nischen aktiv eingesetzt. Insbesondere in Nischen wie APCS und Telekommunikation, mit denen man sich befassen konnte, sind Raumfahrzeuge etwas seltener anzutreffen als bei jedem Schritt.

Daher werden wir in diesem Artikel versuchen, über Raumfahrzeuge zu sprechen, hauptsächlich über hierarchische endliche Zustandsmaschinen und ihre erweiterten Fähigkeiten. Und erzählen Sie ein wenig über die Unterstützung von Raumfahrzeugen in SObjectizer-5 , dem "Actor" -Framework für C ++. Eine der beiden wenigen, die offen, frei, plattformübergreifend und noch am Leben sind.

Selbst wenn Sie nicht an SObjectizer interessiert sind, aber noch nie von hierarchischen Finite-State-Maschinen gehört haben oder wie nützlich solche erweiterten Funktionen eines Raumfahrzeugs wie Eingabe- / Ausgabehandler für Zustände oder Statusverlauf sind, sind Sie möglicherweise daran interessiert, unter die Katze und zu schauen Lesen Sie mindestens den ersten Teil des Artikels.

Allgemeine Worte zu endlichen Zustandsmaschinen

Wir werden nicht versuchen, ein vollständiges Bildungsprogramm in dem Artikel zum Thema Automaten und einer solchen Vielfalt wie endlichen Zustandsmaschinen durchzuführen. Der Leser muss mindestens ein grundlegendes Verständnis für diese Art von Entitäten haben.

Erweiterte Finite-State-Maschinen und ihre Fähigkeiten

Das Raumschiff verfügt über mehrere "erweiterte" Funktionen, die die Benutzerfreundlichkeit des Raumfahrzeugs im Programm erheblich verbessern. Werfen wir einen kurzen Blick auf diese "erweiterten" Funktionen.

Haftungsausschluss: Wenn der Leser mit Zustandsdiagrammen von UML gut vertraut ist, findet er hier nichts Neues für sich.

Hierarchische Zustandsmaschinen

Die vielleicht wichtigste und wertvollste Gelegenheit ist die Organisation einer Hierarchie / Verschachtelung von Staaten. Denn gerade die Fähigkeit, Zustände ineinander zu versetzen, eliminiert die „Explosion“ der Anzahl der Übergänge von Zustand zu Zustand, wenn die Komplexität des Raumfahrzeugs zunimmt.

Es ist schwieriger, dies in Worten zu erklären, als es anhand eines Beispiels zu zeigen. Stellen wir uns daher vor, wir haben einen Infokiosk, auf dessen Bildschirm zuerst eine Begrüßungsnachricht angezeigt wird. Der Benutzer kann das Element "Dienste" auswählen und in den Abschnitt zur Auswahl der Dienste gehen, die er benötigt. Oder er kann den Eintrag "Persönliches Konto" auswählen und zum Abschnitt über die Arbeit mit seinen persönlichen Daten und Diensten gehen. Oder er kann den Abschnitt Hilfe auswählen. Bisher scheint alles einfach zu sein und kann durch das folgende Zustandsdiagramm (so vereinfacht wie möglich) dargestellt werden:



Versuchen wir jedoch sicherzustellen, dass der Benutzer durch Klicken auf die Schaltfläche "Abbrechen" mit einer Begrüßungsnachricht von jedem Abschnitt zur Startseite zurückkehren kann:



Das Schema wird kompliziert, aber immer noch unter Kontrolle. Wir möchten jedoch daran erinnern, dass wir im Abschnitt "Dienste" möglicherweise mehrere weitere Unterabschnitte haben, z. B. "Beliebte Dienste", "Neue Dienste" und "Vollständige Liste". Und von jedem dieser Abschnitte müssen Sie auch zur Startseite zurückkehren. Unser einfaches Raumschiff wird immer schwieriger:



Aber das ist noch lange nicht alles. Wir haben den "Zurück" -Button noch nicht berücksichtigt, mit dem wir zum vorherigen Abschnitt zurückkehren müssen. Fügen wir eine Reaktion auf die Schaltfläche "Zurück" hinzu und sehen, was wir erhalten:



Ja, jetzt sehen wir den Weg zu echtem Spaß. Aber wir haben noch nicht einmal die Unterabschnitte in den Abschnitten "Mein Konto" und "Hilfe" berücksichtigt ... Wenn wir anfangen, wird unser einfaches Raumschiff fast sofort zu etwas Unvorstellbarem.

Hier hilft uns die Verschachtelung von Staaten. Stellen wir uns vor, wir haben nur zwei Zustände der obersten Ebene: WelcomeScreen und UserSelection. Alle unsere Abschnitte (dh "Dienste", "Mein Konto" und "Hilfe") werden im UserSelection-Status "verschachtelt". Sie können sagen, dass die Status ServicesScreen, ProfileScreen und HelpScreen untergeordnete Elemente der UserSelection sind. Und da sie Kinder sind, erben sie die Reaktion auf einige Signale aus ihrem elterlichen Zustand. Daher können wir die Antwort auf die Schaltfläche Abbrechen in UserSelection definieren. Wir müssen diese Reaktion jedoch nicht in allen Nebengebieten bestimmen. Was macht unser Raumschiff prägnanter und verständlicher:



Hier können Sie feststellen, dass die Reaktion für "Abbrechen" und "Zurück" wir in UserSelection definiert haben. Diese Reaktion auf die Schaltfläche Abbrechen funktioniert ausnahmslos für alle UserSelection-Unterzustände (einschließlich eines weiteren zusammengesetzten ServicesSelection-Unterzustands). Im Unterzustand ServicesSelection ist die Reaktion auf die Schaltfläche Zurück bereits anders - die Rückgabe erfolgt nicht in WelcomScreen, sondern in ServicesScreen.

Zertifizierungsstellen, die eine Hierarchie / Verschachtelung von Zuständen verwenden, werden als hierarchische endliche Zustandsmaschinen (ICA) bezeichnet.

Reaktion auf Ein- / Ausstieg in / aus dem Staat

Eine sehr nützliche Funktion ist die Möglichkeit, eine Antwort auf das Eintreten in einen bestimmten Zustand sowie eine Reaktion auf das Verlassen eines Zustands zuzuweisen. Im obigen Beispiel mit einem Infokiosk kann ein Handler aufgehängt werden, um in jeden der Zustände einzutreten, wodurch der Inhalt des Infokioskbildschirms geändert wird.

Das vorige Beispiel kann etwas erweitert werden. Angenommen, wir haben zwei Unterzustände in WelcomScreen: BrightWelcomScreen, in dem der Bildschirm normal hervorgehoben wird, und DarkWelcomScreen, in dem die Bildschirmhelligkeit verringert wird. Wir können einen DarkWelcomScreen-Eingabehandler erstellen, der den Bildschirm dimmt. Und ein DarkWelcomScreen-Exit-Handler, der die normale Helligkeit wiederherstellt.

Automatische Zustandsänderung nach einer festgelegten Zeit

Manchmal kann es erforderlich sein, den Aufenthalt des Raumfahrzeugs in einem bestimmten Zustand zu begrenzen. Im obigen Beispiel können wir die Zeit, in der unser ICA im BrightWelcomScreen-Status bleibt, auf eine Minute beschränken. Sobald die Minute abgelaufen ist, wechselt der ICA automatisch in den DarkWelcomScreen-Status.

Raumfahrzeuggeschichte

Ein weiteres sehr nützliches Merkmal von ICA ist die Geschichte des Zustands des Raumfahrzeugs.

Stellen wir uns vor, wir haben eine Art abstrakte ICA dieser Art:



Dies kann unser ICA von TopLevelState1 zu TopLevelState2 und umgekehrt gehen. In TopLevelState1 gibt es jedoch mehrere verschachtelte Zustände. Wenn der ICA einfach von TopLevelState2 zu TopLevelState1 wechselt, werden sofort zwei Status aktiviert: TopLevelState1 und NestedState1. NestedState1 ist aktiviert, da es sich um den anfänglichen Unterzustand des Status TopLevelState1 handelt.

Stellen Sie sich nun vor, dass unser ICA seinen Status weiter von NestedState1 in NestedState2 geändert hat. In NestedState2 wurde der SubState InternalState1 aktiviert (da dies der ursprüngliche Unterzustand für NestedState2 ist). Und von InternalState1 gingen wir zu InternalState2. Somit sind gleichzeitig die folgenden Zustände aktiv: TopLevelState1, NestedState2 und InternalState2. Und hier gehen wir zu TopLevelState2 (d. H. Wir haben TopLevelState1 im Allgemeinen verlassen).

Aktiv wird zu TopLevelState2. Danach wollen wir zu TopLevelState1 zurückkehren. Es befindet sich in TopLevelState1 und nicht in einem bestimmten Unterzustand in TopLevelState1.

Also, von TopLevelState2 gehen wir zu TopLevelState1 und wo kommen wir hin?

Wenn TopLevelState1 keinen Verlauf hat, kommen wir zu TopLevelState1 und NestedState1 (da NestedState1 der anfängliche Unterzustand für TopLevelState1 ist). Das heißt, Die ganze Geschichte über die Übergänge in TopLevelState1, die vor dem Verlassen von TopLevelState2 stattfanden, ging vollständig verloren.

Wenn TopLevelState1 eine sogenannte hat flacher Verlauf, dann kommen wir bei der Rückkehr von TopLevelState2 zu TopLevelState1 zu NestedState2 und InternalState1. Wir gelangen in NestedState2, weil es im Statusverlauf von TopLevelState1 aufgezeichnet ist. Und wir kommen zu InternalState1, weil es der Start für NestedState2 ist. Es stellt sich heraus, dass in der oberflächlichen Historie für TopLevelState1 Informationen nur über die Unterzustände der allerersten Ebene gespeichert werden. Die Geschichte der eingebetteten Zustände in diesen Unterzuständen bleibt nicht erhalten.

Wenn TopLevelState1 jedoch eine lange Geschichte hat, gelangen wir bei der Rückkehr von TopLevelState2 zu TopLevelState1 in NestedState2 und InternalState2. Denn in einer tiefen Geschichte werden vollständige Informationen über aktive Unterzustände gespeichert, unabhängig von ihrer Tiefe.

Orthogonale Zustände

Bisher haben wir ICA untersucht, bei der nur einer der Unterzustände innerhalb des Staates aktiv sein konnte. Manchmal kann es jedoch Situationen geben, in denen in einem bestimmten ICA-Zustand mehrere gleichzeitig aktive Unterzustände vorhanden sein sollten. Solche Unterzustände werden orthogonale Zustände genannt.

Ein klassisches Beispiel, das orthogonale Zustände demonstriert, ist die bekannte Computertastatur und ihre Modi NumLock, CapsLock und ScrollLock. Wir können sagen, dass die Arbeit mit NumLock / CapsLock / ScrollLock durch orthogonale Unterzustände im aktiven Zustand beschrieben wird:

Alles, was Sie über endliche Zustandsmaschinen wissen wollten, aber ...

Im Allgemeinen gibt es einen grundlegenden Artikel über formale Notation für Zustandsdiagramme von David Harel: Zustandsdiagramme : Ein visueller Formalismus für komplexe Systeme (1987) .

Dort werden am Beispiel der Steuerung einer gewöhnlichen elektronischen Uhr verschiedene Situationen untersucht, die beim Arbeiten mit Finite-State-Maschinen auftreten können. Wenn jemand es nicht gelesen hat, kann ich es nur empfehlen. Grundsätzlich ging alles, was Harel beschrieb, in die UML-Notation. Wenn Sie jedoch die Beschreibung von Zustandsdiagrammen aus der UML lesen, verstehen Sie nicht immer, was, warum und wann Sie sie benötigen. In dem Artikel von Harel geht die Präsentation jedoch von einfachen zu komplexeren Situationen über. Und Sie sind sich der Macht bewusst, die endliche Zustandsmaschinen in sich selbst verbergen.

Finite-State-Maschinen in SObjectizer

Weiter werden wir über SObjectizer und seine Besonderheiten sprechen. Wenn Sie die folgenden Beispiele nicht ganz verstehen, ist es möglicherweise sinnvoll, mehr über SObjectizer zu erfahren. Zum Beispiel aus unserem Übersichtsartikel über SObjecizer und mehreren nachfolgenden Artikeln, in denen Leser SObjectizer kennenlernen und von einfach zu komplex wechseln ( erster Artikel, zweiter und dritter ).

Agenten in SObjectizer sind Zustandsautomaten

Agenten in SObjectizer waren von Anfang an Zustandsautomaten mit expliziten Zuständen. Selbst wenn der Entwickler des Agenten keinen seiner eigenen Status in seiner Agentenklasse beschrieben hat, hatte der Agent immer noch einen Standardstatus, der standardmäßig verwendet wurde. Wenn ein Entwickler beispielsweise einen so trivialen Agenten erstellt hat:

class simple_demo final : public so_5::agent_t { public: //   ,       . struct how_are_you final : public so_5::signal_t {}; //   ,     . struct quit final : public so_5::signal_t {}; // ..   ,      . simple_demo(context_t ctx) : so_5::agent_t{std::move(ctx)} { so_subscribe_self() .event<how_are_you>([]{ std::cout << "I'm fine!" << std::endl; }) .event<quit>([this]{ so_deregister_agent_coop_normally(); }); } }; 

dann kann er nicht einmal vermuten, dass in Wirklichkeit alle Abonnements, die er gemacht hat, für den Standardzustand gemacht wurden. Wenn der Entwickler dem Agenten jedoch seine eigenen Status hinzufügt, müssen Sie bereits darüber nachdenken, den Agenten ordnungsgemäß im richtigen Status zu signieren. Hier beispielsweise eine einfache (und wie üblich) falsche Modifikation des oben gezeigten Agenten:

 class simple_demo final : public so_5::agent_t { // ,  ,   . state_t st_free{this}; // ,  ,   . state_t st_busy{this}; public: //   ,       . struct how_are_you final : public so_5::signal_t {}; //   ,     . struct quit final : public so_5::signal_t {}; // ..   ,      . simple_demo(context_t ctx) : so_5::agent_t{std::move(ctx)} { so_subscribe_self() .event<quit>([this]{ so_deregister_agent_coop_normally(); }); //   how_are_you   ,    . st_free.event([]{ std::cout << "I'm free" << std::endl; }); st_busy.event([]{ std::cout << "I'm busy" << std::endl; }); //     st_free. this >>= st_free; } }; 

Wir setzen zwei verschiedene Handler für das how_are_you-Signal, jeder für seinen eigenen Status.

Und der Fehler bei dieser Modifikation des Agenten "simple_demo" besteht darin, dass der Agent in st_free oder st_busy überhaupt nicht auf das Beenden reagiert, weil Wir haben das Beendigungsabonnement im Standardzustand belassen, aber die entsprechenden Abonnements für st_free und st_busy nicht erstellt. Eine einfache und offensichtliche Möglichkeit, dieses Problem zu beheben, besteht darin, st_free und st_busy die entsprechenden Abonnements hinzuzufügen:

  simple_demo(context_t ctx) : so_5::agent_t{std::move(ctx)} { //   how_are_you   ,    . st_free .event([]{ std::cout << "I'm free" << std::endl; }) .event<quit>([this]{ so_deregister_agent_coop_normally(); }); st_busy .event([]{ std::cout << "I'm busy" << std::endl; }) .event<quit>([this]{ so_deregister_agent_coop_normally(); }); //     st_free. this >>= st_free; } 

Richtig, diese Methode riecht nach Kopieren und Einfügen, was nicht gut ist. Sie können das Kopieren und Einfügen entfernen, indem Sie einen gemeinsamen übergeordneten Status für st_free und st_busy eingeben:

 class simple_demo final : public so_5::agent_t { //      . state_t st_basic{this}; // ,  ,   . //      st_basic. state_t st_free{initial_substate_of{st_basic}}; // ,  ,   . //     st_basic. state_t st_busy{substate_of{st_basic}}; public: //   ,       . struct how_are_you final : public so_5::signal_t {}; //   ,     . struct quit final : public so_5::signal_t {}; // ..   ,      . simple_demo(context_t ctx) : so_5::agent_t{std::move(ctx)} { //   quit   st_basic    //  ""  . st_basic.event<quit>([this]{ so_deregister_agent_coop_normally(); }); //   how_are_you   ,    . st_free.event([]{ std::cout << "I'm free" << std::endl; }); st_busy.event([]{ std::cout << "I'm busy" << std::endl; }); //     st_free. this >>= st_free; } }; 

Aus Gründen der Gerechtigkeit sollte hinzugefügt werden, dass Agenten in SObjectizer zunächst nur einfache Zustandsmaschinen sein konnten. Die Unterstützung für hierarchische Raumfahrzeuge erschien vor relativ kurzer Zeit im Januar 2016.

Warum sind SObjectizer-Agenten Finite-State-Maschinen?

Diese Frage hat eine sehr einfache Antwort: So kam es , dass die Wurzeln von SObjectizer aus der Welt der Prozessleitsysteme stammen und dort sehr oft Finite-State-Maschinen verwendet werden. Daher hielten wir es für notwendig, dass die Agenten in SObjectizer auch Zustandsmaschinen sind. Dies ist sehr praktisch, wenn in der Anwendung, für die SObjectizer angewendet werden soll, Zertifizierungsstellen verwendet werden. Und der Standardzustand, den alle Agenten haben, erlaubt es uns, nicht an Raumfahrzeuge zu denken, wenn die Verwendung von Raumfahrzeugen nicht erforderlich ist.

Wenn Sie sich das Actors-Modell selbst und die Prinzipien ansehen, auf denen dieses Modell basiert, gilt im Prinzip Folgendes:

• Ein Schauspieler ist eine Einheit mit Verhalten.
• Akteure reagieren auf eingehende Nachrichten;
• Nach Erhalt der Nachricht kann der Schauspieler:
  
  • eine bestimmte Anzahl von Nachrichten an andere Akteure senden;
  • eine Reihe neuer Akteure schaffen;
  • Definieren Sie ein neues Verhalten für die Verarbeitung nachfolgender Nachrichten.

Man kann eine starke Ähnlichkeit zwischen einfachen Raumfahrzeugen und Schauspielern finden. Man könnte sogar sagen, dass Schauspieler einfache endliche Zustandsmaschinen sind.

Welche Funktionen von Advanced State Machines unterstützt SObjectizer?

Von den oben genannten Funktionen fortschrittlicher Finite-State-Maschinen unterstützt SObjectizer alles außer orthogonalen Zuständen. Andere Extras wie verschachtelte Status, Eingabe- / Ausgabehandler, Einschränkungen für die im Status verbrachte Zeit und der Verlauf für die Status werden unterstützt.

Mit der Unterstützung orthogonaler Zustände ist das erste Mal nicht zusammengewachsen. Einerseits sollte die interne Architektur von SObjectizer nicht mehrere unabhängige und gleichzeitig aktive Zustände des Agenten unterstützen. Andererseits gibt es ideologische Fragen, wie sich ein Agent mit orthogonalen Zuständen verhalten sollte. Das Gewirr dieser Fragen erwies sich als zu kompliziert, und der nützliche Auspuff war zu klein, um dieses Problem zu lösen. Ja, und in unserer Praxis gab es noch keine Situationen, in denen orthogonale Zustände erforderlich wären, aber es wäre beispielsweise unmöglich, die Arbeit auf mehrere Agenten aufzuteilen, die an einen gemeinsamen Arbeitskontext gebunden sind.

Wenn jedoch jemand eine Funktion wie orthogonale Zustände benötigt und Sie Beispiele aus der Praxis für Aufgaben haben, bei denen dies erforderlich ist, lassen Sie uns sprechen. Wenn wir konkrete Beispiele vor Augen haben, können wir diese Funktion möglicherweise zu SObjectizer hinzufügen.

Wie die Unterstützung für erweiterte Funktionen von ICA im Code aussieht

In diesem Teil der Geschichte werden wir versuchen, die SObjectizer-5-API schnell zu überprüfen, um mit ICA zu arbeiten. Ohne tief in die Details zu gehen, nur damit der Leser eine Vorstellung davon hat, was ist und wie es aussieht. Weitere Informationen finden Sie auf Wunsch in der offiziellen Dokumentation .

Verschachtelte Staaten

Um einen verschachtelten Status zu deklarieren, müssen Sie den Ausdruck initial_substate_of oder substate_of an den Konstruktor des entsprechenden state_t-Objekts übergeben:

 class demo : public so_5::agent_t { state_t st_parent{this}; //  . state_t st_first_child{initial_substate_of{st_parent}}; //   . //    . state_t st_second_child{substate_of{st_parent}}; //   . state_t st_third_child{substate_of{st_parent}}; //   . state_t st_first_grandchild{initial_substate_of{st_third_child}}; //    . state_t st_second_grandchild{substate_of{st_third_child]}; ... }; 

Wenn der Zustand S mehrere Unterzustände C1, C2, ..., Cn hat, sollte einer von ihnen (und nur einer) als initial_substate_of markiert werden. Verstöße gegen diese Regel werden zur Laufzeit diagnostiziert.

Die maximale Verschachtelungstiefe in SObjectizer-5 ist begrenzt. In Version 5.5 sind dies 16 Ebenen. Verstöße gegen diese Regel werden zur Laufzeit diagnostiziert.

Der wichtigste Trick bei verschachtelten Zuständen besteht darin, dass bei Aktivierung eines Zustands mit verschachtelten Zuständen mehrere Zustände gleichzeitig aktiviert werden. Angenommen, es gibt einen Zustand A mit den Unterzuständen B und C, und in Unterzustand B gibt es die Unterzustände D und E:



Wenn Zustand A aktiviert ist, werden tatsächlich sofort drei Zustände aktiviert: A, AB und ABD

Die Tatsache, dass mehrere Staaten gleichzeitig aktiv sein können, hat die schwerwiegendste Auswirkung auf zwei Archivierungssachen. Erstens, um nach einem Handler für die nächste eingehende Nachricht zu suchen. In dem gerade gezeigten Beispiel wird der Nachrichtenhandler zuerst im ABD-Zustand durchsucht. Wenn dort kein geeigneter Handler vorhanden ist, wird die Suche in seinem übergeordneten Zustand fortgesetzt, d. H. in AB Und bei Bedarf bereits verletzt, wird die Suche in Zustand A fortgesetzt.

Zweitens beeinflusst das Vorhandensein mehrerer aktiver Zustände die Reihenfolge des Aufrufs von Eingabe- / Ausgabehandlern für Zustände. Dies wird jedoch weiter unten erörtert.

Status-E / A-Handler

Für einen Status können Status-Handler für den Statusein- und -ausgang angegeben werden. Dies erfolgt mit den Methoden state_t :: on_enter und state_t :: on_exit. In der Regel werden diese Methoden in der Methode so_define_agent () aufgerufen (oder direkt im Agentenkonstruktor, wenn der Agent trivial ist und keine Vererbung von ihm bereitgestellt wird).

 class demo : public so_5::agent_t { state_t st_free{this}; state_t st_busy{this}; ... void so_define_agent() override { // :       , //     . st_free.on_enter([]{ ... }); st_busy.on_exit([]{ ...}); ... this >>= st_free; } ... }; 

Der wahrscheinlich schwierigste Moment mit on_enter / on_exit-Handlern besteht darin, sie für verschachtelte Zustände zu verwenden. Kehren wir zum Beispiel mit den Zuständen A, B, C, D und E zurück.



Angenommen, jeder Status verfügt über einen Handler on_enter und on_exit.

Lassen Sie A. zum aktuellen Status des Agenten werden. Zustände A, AB und ABD werden aktiviert Während der Zustandsänderung eines Agenten werden A.on_enter, ABon_enter und ABDon_enter aufgerufen. Und in dieser Reihenfolge.

Angenommen, es gibt einen Übergang zu ABE. ABDon_exit und ABEon_enter werden aufgerufen.

Wenn wir dann den Agenten in den AC-Status versetzen, wird ABEon_exit, ABon_exit, ACon_enter aufgerufen.

Wenn sich der Agent im AC-Status abmeldet, werden unmittelbar nach Abschluss der Methode so_evt_finish () die Handler ACon_exit und A.on_exit aufgerufen.

Fristen

Das Zeitlimit für den Agenten, um in einem bestimmten Status zu bleiben, wird mithilfe der Methode state_t :: time_limit festgelegt. Wie bei on_enter / on_exit werden die Methoden time_limit normalerweise aufgerufen, wenn der Agent für die Arbeit im SObjectizer konfiguriert ist:

 class led_indicator : public so_5::agent_t { state_t inactive{this}; state_t active{this}; ... void so_define_agent() override { //        15s. //        inactive. active.time_limit(15s, inactive); ... } ... }; 

Wenn das Zeitlimit für den Status festgelegt ist, beginnt SObjectizer, sobald der Agent in diesen Status eintritt, die im Status verbrachte Zeit zu zählen. Wenn der Agent den Status verlässt und dann wieder in diesen Status zurückkehrt, beginnt der Countdown erneut.

Wenn für eingebettete Zustände Zeitlimits festgelegt sind, müssen Sie vorsichtig sein, weil neugierige Tricks sind möglich:

 class demo : public so_5::agent_t { //   . state_t A{this}, B{this}; //   first . state_t C{initial_substate_of{A}}, st_D{substate_of{A}}; ... void so_define_agent() override { A.time_limit(15s, B); C.time_limit(10s, D); D.time_limit(20s, C); ... } ... }; 

Angenommen, ein Agent tritt in den Zustand A ein. Die Zustände A und C sind sowohl für A als auch für C aktiviert. Zuvor wird es für Status C beendet und der Agent wechselt zu Status D. Dies startet den Countdown für den Aufenthalt in Status D. Der Countdown für den Aufenthalt in A wird jedoch fortgesetzt! Da der Agent während des Übergangs von C nach D weiterhin in Zustand A blieb. Und fünf Sekunden nach dem erzwungenen Übergang von C nach D geht der Agent in Zustand B über.

Geschichte für das Glück

Standardmäßig haben Agentenstatus keinen Verlauf. Um das Speichern des Verlaufs für einen Status zu aktivieren, übergeben Sie die Konstante flat_history (der Status hat einen flachen Verlauf) oder deep_history (der Status hat einen tiefen Verlauf) an den Konstruktor state_t. Zum Beispiel:

 class demo : public so_5::agent_t { state_t A{this, shallow_history}; state_t B{this, deep_history}; ... }; 

Die Geschichte für Staaten ist ein schwieriges Thema, insbesondere wenn eine anständige Verschachtelungstiefe von Staaten verwendet wird und die Unterzustände ihre eigene Geschichte haben. Ausführlichere Informationen zu diesem Thema finden Sie in der Dokumentation . Nun, um uns zu fragen, ob Sie es nicht selbst herausfinden können;)

just_switch_to, transfer_to_state, unterdrücken

Die Klasse state_t verfügt über eine Reihe der am häufigsten verwendeten Methoden, die oben bereits gezeigt wurden: event () zum Abonnieren von Ereignissen für eine Nachricht, on_enter () und on_exit () zum Festlegen von Eingabe- / Ausgabehandlern, time_limit () zum Festlegen eines Grenzwerts für die in einem Status verbrachte Zeit.

Neben diesen Methoden sind bei der Arbeit mit ICA die folgenden Methoden der Klasse state_t sehr nützlich:

Methode just_switch_to (), die für den Fall entwickelt wurde, dass die einzige Reaktion auf eine eingehende Nachricht darin besteht, den Agenten in einen neuen Zustand zu versetzen. Sie können schreiben:

 some_state.just_switch_to<some_msg>(another_state); 

statt:

 some_state.event([this](mhood_t<some_msg>) { this >>= another_state; }); 

Die Methode transfer_to_state () ist sehr nützlich, wenn eine Nachricht M in zwei oder mehr Zuständen S1, S2, ..., Sn auf dieselbe Weise verarbeitet wird. Wenn wir uns jedoch in den Zuständen S2, ..., Sn befinden, müssen wir zuerst zu S1 zurückkehren und erst dann die Verarbeitung M durchführen.

Wenn dies schwierig klingt, wird diese Situation in einem Codebeispiel möglicherweise besser verstanden:

 class demo : public so_5::agent_t { state_t S1{this}, S2{this}, ..., Sn{this}; ... void actual_M_handler(mhood_t<M> cmd) {...} ... void so_define_agent() override { S1.event(&demo::actual_M_handler); ... //           S1, //      M  . S2.event([this](mhood_t<M> cmd) { this >>= S1; actual_M_handler(cmd); }); ... //      . Sn.event([this](mhood_t<M> cmd) { this >>= S1; actual_M_handler(cmd); }); } ... }; 

Verwenden Sie transfer_to_state, anstatt sehr ähnliche Ereignishandler für S2, ..., Sn zu definieren:

 class demo : public so_5::agent_t { state_t S1{this}, S2{this}, ..., Sn{this}; ... void actual_M_handler(mhood_t<M> cmd) {...} ... void so_define_agent() override { S1.event(&demo::actual_M_handler); ... //           S1, //      M  . S2.transfer_to_state<M>(S1); ... //      . Sn.transfer_to_state<M>(Sn); } ... }; 

Die Methode replace () unterdrückt eine Ereignishandlersuche nach dem aktuellen Unterzustand und allen übergeordneten Unterzuständen. Angenommen, wir haben einen übergeordneten Status A, in dem std :: abort () für Nachricht M aufgerufen wird. Und es gibt einen untergeordneten Zustand von B, in dem M sicher ignoriert werden kann. Wir müssen die Reaktion auf M in Unterzustand B bestimmen, denn wenn wir dies nicht tun, wird der Handler für B in A gefunden. Daher müssen wir etwas schreiben wie:

 void so_define_agent() override { A.event([](mhood_t<M>) { std::abort(); }); ... B.event([](mhood_t<M>) {}); //    ,      //   M   . ... } 

Mit der Methode suppress () können Sie diese Situation expliziter und grafischer in Code schreiben:

 void so_define_agent() override { A.event([](mhood_t<M>) { std::abort(); }); ... B.suppress<M>(); //    ,      //   M   . ... } 

Sehr einfaches Beispiel

Zu den Standardbeispielen von SObjectizer v.5.5 gehört ein einfaches Beispiel, blinking_led , das den Betrieb einer blinkenden LED-Anzeige simuliert. Das Agentenstatusdiagramm aus diesem Beispiel lautet wie folgt:



Und hier ist der vollständige Agentencode aus diesem Beispiel:

 class blinking_led final : public so_5::agent_t { state_t off{ this }, blinking{ this }, blink_on{ initial_substate_of{ blinking } }, blink_off{ substate_of{ blinking } }; public : struct turn_on_off : public so_5::signal_t {}; blinking_led( context_t ctx ) : so_5::agent_t{ ctx } { this >>= off; off.just_switch_to< turn_on_off >( blinking ); blinking.just_switch_to< turn_on_off >( off ); blink_on .on_enter( []{ std::cout << "ON" << std::endl; } ) .on_exit( []{ std::cout << "off" << std::endl; } ) .time_limit( std::chrono::milliseconds{1250}, blink_off ); blink_off .time_limit( std::chrono::milliseconds{750}, blink_on ); } }; 

Hier wird die gesamte eigentliche Arbeit in den E / A-Handlern für den Unterzustand blink_on ausgeführt. Außerdem sind die Aufenthaltsdauer in den Unterzuständen blink_on und blink_off begrenzt.

Kein sehr einfaches Beispiel

Zu den Standardbeispielen von SObjectizer v.5.5 gehört auch ein viel komplexeres Beispiel, intercom_statechart , das das Verhalten der Türsprechanlage nachahmt. Das Zustandsdiagramm des Hauptagenten in diesem Beispiel sieht ungefähr so ​​aus:



Alles ist so hart, weil diese Nachahmung nicht nur das Anrufen einer Wohnung nach Nummer unterstützt, sondern auch Dinge wie einen eindeutigen Geheimcode für jede Wohnung sowie einen speziellen Servicecode. Mit diesen Codes können Sie das Türschloss öffnen, ohne irgendwo zu wählen.

In diesem Beispiel gibt es noch interessante Dinge. Es ist jedoch zu groß, um im Detail beschrieben zu werden (selbst ein separater Artikel reicht möglicherweise nicht aus). Wenn Sie also daran interessiert sind, wie wirklich komplexe ICAs in SObjectizer aussehen, können Sie dies in diesem Beispiel sehen. Und wenn etwas nicht klar ist, können Sie uns eine Frage stellen. Zum Beispiel in den Kommentaren zu diesem Artikel.

Ist es möglich, die Unterstützung für in SObjectizer-5 integrierte Raumfahrzeuge nicht zu verwenden?

Daher bietet SObjectizer-5 eine integrierte Unterstützung für ICA mit einer Vielzahl von unterstützten Funktionen. Diese Unterstützung wird natürlich gemacht, um sie zu nutzen. Insbesondere die Debugging-Mechanismen von SObjectizer, wie die Ablaufverfolgung der Nachrichtenübermittlung , kennen den Status des Agenten und zeigen den aktuellen Status in ihren jeweiligen Debug-Nachrichten an.

Wenn der Entwickler jedoch aus irgendeinem Grund die integrierten SObjectizer-5-Tools nicht verwenden möchte, kann er dies möglicherweise nicht tun.

Sie können beispielsweise die Verwendung von SObjectizer state_t und ähnlichen Programmen ablehnen, da state_t ein ziemlich schweres Objekt mit einem inneren std :: string, einigen std :: -Funktionen und mehreren Zählern wie std :: size_t ist. fünf Zeiger auf verschiedene Objekte und eine andere Kleinigkeit. Zusammen ergibt dies unter 64-Bit-Linux und GCC-5.5 beispielsweise 160 Bytes pro state_t (abgesehen von dem, was im dynamischen Speicher zugewiesen werden kann).

Wenn Sie beispielsweise eine Million Agenten in der Anwendung benötigen, von denen jeder 10 Status hat, ist der Overhead von SObjectizer state_t möglicherweise nicht akzeptabel. In diesem Fall können Sie einen anderen Mechanismus für die Arbeit mit Zustandsautomaten verwenden und die Nachrichtenverarbeitung manuell an diesen Mechanismus delegieren. So etwas wie:

 class external_fsm_demo : public so_5::agent_t { some_fsm_type my_fsm_; ... void so_define_agent() override { so_subscribe_self() .event([this](mhood_t<msg_one> cmd) { my_fsm_.handle(*cmd); }) .event([this](mhood_t<msg_two> cmd) { my_fsm_.handle(*cmd); }) .event([this](mhood_t<msg_three> cmd) { my_fsm_.handle(*cmd); }); ... } ... }; 

In diesem Fall zahlen Sie für die Effizienz, indem Sie den manuellen Arbeitsaufwand und den Mangel an Hilfe durch die Debugging-Mechanismen von SObjectizer erhöhen. Aber hier ist es Sache des Entwicklers, zu entscheiden.

Fazit

Der Artikel erwies sich als umfangreich, viel mehr als ursprünglich geplant. Vielen Dank an alle, die diesen Ort gelesen haben. Wenn einer der Leser es für möglich hält, Ihr Feedback in den Kommentaren zum Artikel zu hinterlassen, ist es großartig.

Wenn etwas unklar bleibt, dann stellen Sie Fragen, wir werden gerne antworten.

Bei dieser Gelegenheit möchte ich auch diejenigen, die sich für SObjectizer interessieren, darauf aufmerksam machen, dass die Arbeit an der nächsten Version von SObjectizer im Rahmen von Zweig 5.5 begonnen hat. Kurz darüber, was für die Implementierung in 5.5.23 in Betracht gezogen wird, wird hier beschrieben . Ausführlicher, aber auf Englisch, hier . Sie können Ihre Meinung zu den für die Implementierung vorgeschlagenen Funktionen abgeben oder etwas anderes anbieten. Das heißt,Es gibt eine echte Chance, die Entwicklung von SObjectizer zu beeinflussen. Darüber hinaus kann es nach der Veröffentlichung von Version 5.5.23 zu einer Unterbrechung der Arbeit am SObjectizer kommen, und die nächste Möglichkeit, etwas Nützliches in den SObjectizer 2018 aufzunehmen, ist möglicherweise nicht möglich.