Stateless - StateMachine für Delphi

[Sir Rufo]

Unter GITHUB: A simple library for creating state machines in DELPHI code habe ich einen Delphi-Port von GITHUB: A simple library for creating state machines in C# code veröffentlicht.

Unittests und Beispiele inklusive.

Der Code sollte ab Delphi XE2+ einfach so verwendet werden können.

Hier ein kleines Beispiel

Delphi-Quellcode:

program PhoneCall;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.Diagnostics,
  System.SysUtils,
  Stateless;

{$SCOPEDENUMS ON}

type
  State      = ( OffHook, Ringing, Connected, Active, OnHold, PhoneDestroyed );
  Trigger    = ( CallDialed, HungUp, CallConnected, LeftMessage, PlacedOnHold, TakenOffHold, PhoneHurledAgainstWall );
  TPhoneCall = TStateMachine<State, Trigger>;

procedure ConfigurePhoneCall( PhoneCall: TPhoneCall );
var
  LCallTimer: TStopwatch;
begin
  PhoneCall.Configure( State.OffHook )
  {} .Permit( Trigger.CallDialed, State.Ringing );

  PhoneCall.Configure( State.Ringing )
  {} .Permit( Trigger.HungUp, State.OffHook )
  {} .Permit( Trigger.CallConnected, State.Active );

  PhoneCall.Configure( State.Connected )
  {} .Permit( Trigger.HungUp, State.OffHook )
  {} .OnEntry(
    procedure( t: TPhoneCall.TTransition )
    begin
      LCallTimer := TStopwatch.StartNew;
    end )
  {} .OnExit(
    procedure( t: TPhoneCall.TTransition )
    begin
      LCallTimer.Stop;
      WriteLn( 'Duration: ', LCallTimer.ElapsedMilliseconds, 'ms' );
    end );

  PhoneCall.Configure( State.Active )
  {} .SubstateOf( State.Connected )
  {} .Permit( Trigger.LeftMessage, State.OffHook )
  {} .Permit( Trigger.PlacedOnHold, State.OnHold );

  PhoneCall.Configure( State.OnHold )
  {} .SubstateOf( State.Connected )
  {} .Permit( Trigger.TakenOffHold, State.Active )
  {} .Permit( Trigger.PhoneHurledAgainstWall, State.PhoneDestroyed );
end;

procedure Test;
var
  LCall: TPhoneCall;
begin
  LCall := TPhoneCall.Create( State.OffHook );
  try
    ConfigurePhoneCall( LCall );
    WriteLn( LCall.ToString );

    LCall.Fire( Trigger.CallDialed );
    WriteLn( LCall.ToString );

    LCall.Fire( Trigger.CallConnected );
    WriteLn( LCall.ToString );

    LCall.Fire( Trigger.PlacedOnHold );
    WriteLn( LCall.ToString );

    LCall.Fire( Trigger.TakenOffHold );
    WriteLn( LCall.ToString );

    LCall.Fire( Trigger.PlacedOnHold );
    WriteLn( LCall.ToString );

    LCall.Fire( Trigger.HungUp );
    WriteLn( LCall.ToString );

  finally
    LCall.Free;
  end;
end;

begin
  try
    Test;
  except
    on E: Exception do
      WriteLn( E.ClassName, ': ', E.Message );
  end;
  ReadLn;

end.

Und die Ausgabe:

Code:

StateMachine { State = OffHook, PermittedTriggers = { CallDialed } }
StateMachine { State = Ringing, PermittedTriggers = { HungUp, CallConnected } }
StateMachine { State = Active, PermittedTriggers = { PlacedOnHold, LeftMessage, HungUp } }
StateMachine { State = OnHold, PermittedTriggers = { TakenOffHold, PhoneHurledAgainstWall, HungUp } }
StateMachine { State = Active, PermittedTriggers = { PlacedOnHold, LeftMessage, HungUp } }
StateMachine { State = OnHold, PermittedTriggers = { TakenOffHold, PhoneHurledAgainstWall, HungUp } }
Duration: 0ms
StateMachine { State = OffHook, PermittedTriggers = { CallDialed } }

[Vis]

Super Projekt! Die Beispiele sind echt klasse!

Ich habe bisher schon mal TStateMachine von Malcolm Groves verwendet (https://github.com/malcolmgroves/TStateMachine), das auch von Stateless inspiriert ist. Auf den ersten Blick hat es aber nicht die Funktionalität wie dieses Projekt.

[mkinzler]

Das war ja Grund für Oliver, seine eigene Version für Delphi zu entwickeln

[Vis]

Hallo zusammen, ich muss jetzt mal bei euch nachhaken bezüglich State Machines. So ganz steige ich noch nicht durch. Klassischerweise gibt es doch Aktionen/Actions die bei einem Zustandsübergang ausgeführt werden. Werden diese bei Stateless im Guard ausgeführt? Oder im OnEntry Ereignis? Oder eher als PermitDynamic, wenn ausgewertet werden muss ob die Aktion erfolgreich war? Oder bin ich auf dem falschen weg?

Da ich oft Benutzereingaben verarbeiten muss, habe ich eine kurze Testanwendung erstellt, in der der Text eines Edit-Feldes genutzt wird um Daten aus einer Datenbank zu holen. Ein paar Zustandsdiagramme von mir im Anhang.
Als ersten Ansatz, kann vom Zustand "Idle" nur in den Zustand "DatenErhalten" gewechselt werden, wenn die Daten aus der Datenbank erfolgreich gelesen wurden (dies geschieht im Guard)

Delphi-Quellcode:

TState = (Idle, DatenErhalten, DatenErhaltenError, DatenAbrufen);
TTrigger = (Tabulator, Next, Error);
TSM = TStateMachine<TState, TTrigger>;

Delphi-Quellcode:

 
SM := TSM.Create(TState.Idle);

SM.Configure(TState.Idle)
 .PermitIf(TTrigger.Tabulator, TState.DatenErhalten, GuardGetDataFromDatabase);

Andererseits könnte man stattdessen noch einer Fehlerzustand hinzufügen "DatenErhaltenError" und mit einem PermitDynamic verzweigen:

Delphi-Quellcode:

SM.Configure(TState.Idle)
    .PermitDynamic(TTrigger.Tabulator,
    function: TState
    begin
      if GetDataFromDatabase(edt1.Text)
      then
        Result := TState.DatenErhalten
      else
        Result := TState.DatenErhaltenError;
    end);

Oder ist es vielleicht schlauer noch einen Zwischenstate einzufügen "DatenAbrufen" und in dessen OnEntry überprüfen ob der Datenabruf erfolgreich war:

Delphi-Quellcode:

 
SM.Configure(TState.Idle)
    .Permit(TTrigger.Tabulator, TState.DatenAbrufen);

SM.Configure(TState.DatenAbrufen)
    .OnEntry(
      procedure
      begin
        if GetDataFromDatabase(edt1.Text) then
          //...
        else
          //...
      end);

Über Hilfe oder ein paar Gedankenanstöße wäre ich dankbar.

Grüße

[Sir Rufo]

Hattest du an so etwas gedacht? (Ist jetzt nicht unbedingt state-of-the-art aber funktioniert).

Im Anhang das komplette Projekt (Source + EXE)

Delphi-Quellcode:

unit DataFetcher.DataContainer;

interface

uses
  System.Classes,
  System.SysUtils,
  System.Threading,
  stateless;

type
{$SCOPEDENUMS ON}
  TDataState   = ( Empty, Busy, Fetching, Cancelling, Refetching, Fetched, HasData, HasError );
  TDataTrigger = ( Fetch, Cancel, Data, Error, Clear );
{$SCOPEDENUMS OFF}
  TDataSM = TStateMachine<TDataState, TDataTrigger>;

type
  TDataContainer<TSource, TResult> = class
  private
    FDataAccessor: TFunc<TSource, TResult>;
    FState       : TDataSM;
    FDataTask    : ITask;
    FValue       : TResult;
    FSource      : TSource;
    procedure ConfigureSM;
    function GetValue: TResult;
    function GetHasValue: Boolean;
    procedure SetSource( const Value: TSource );
    function GetIsBusy: Boolean;
  protected
    procedure FetchData;
    procedure CancelFetch;
  public
    constructor Create( DataAccessor: TFunc<TSource, TResult> );
    destructor Destroy; override;

    procedure Clear;

    function ToString: string; override;

    property HasValue: Boolean read GetHasValue;
    property IsBusy: Boolean read GetIsBusy;
    property Source: TSource read FSource write SetSource;
    property Value: TResult read GetValue;
  end;

implementation

{ TDataContainer }

procedure TDataContainer<TSource, TResult>.CancelFetch;
var
  lTask: ITask;
begin
  lTask := FDataTask;
  if Assigned( lTask )
  then
    lTask.Cancel;
end;

procedure TDataContainer<TSource, TResult>.Clear;
begin
  FState.Fire( TDataTrigger.Clear );
  FSource := default ( TSource );
end;

procedure TDataContainer<TSource, TResult>.ConfigureSM;
begin
  FState := TDataSM.Create( TDataState.Empty );

  FState.Configure( TDataState.Empty )
  {} .Ignore( TDataTrigger.Clear )
  {} .Permit( TDataTrigger.Fetch, TDataState.Fetching );

  FState.Configure( TDataState.Fetching )
  {} .SubstateOf( TDataState.Busy )
  {} .OnEntry( FetchData )
  {} .Permit( TDataTrigger.Clear, TDataState.Cancelling )
  {} .Permit( TDataTrigger.Cancel, TDataState.Cancelling )
  {} .Permit( TDataTrigger.Fetch, TDataState.Refetching )
  {} .Permit( TDataTrigger.Data, TDataState.HasData )
  {} .Permit( TDataTrigger.Error, TDataState.HasError );

  FState.Configure( TDataState.Cancelling )
  {} .SubstateOf( TDataState.Busy )
  {} .OnEntry( CancelFetch )
  {} .Ignore( TDataTrigger.Cancel )
  {} .Ignore( TDataTrigger.Clear )
  {} .Permit( TDataTrigger.Fetch, TDataState.Refetching )
  {} .Permit( TDataTrigger.Data, TDataState.Empty )
  {} .Permit( TDataTrigger.Error, TDataState.Empty );

  FState.Configure( TDataState.Refetching )
  {} .SubstateOf( TDataState.Busy )
  {} .OnEntry( CancelFetch )
  {} .Ignore( TDataTrigger.Fetch )
  {} .Permit( TDataTrigger.Cancel, TDataState.Cancelling )
  {} .Permit( TDataTrigger.Clear, TDataState.Cancelling )
  {} .Permit( TDataTrigger.Data, TDataState.Fetching )
  {} .Permit( TDataTrigger.Error, TDataState.Fetching );

  FState.Configure( TDataState.Fetched )
  {} .Permit( TDataTrigger.Fetch, TDataState.Fetching )
  {} .Permit( TDataTrigger.Clear, TDataState.Empty );

  FState.Configure( TDataState.HasData )
  {} .SubstateOf( TDataState.Fetched );

  FState.Configure( TDataState.HasError )
  {} .SubstateOf( TDataState.Fetched );
end;

constructor TDataContainer<TSource, TResult>.Create( DataAccessor: TFunc<TSource, TResult> );
begin
  inherited Create;
  FDataAccessor := DataAccessor;
  ConfigureSM;
end;

destructor TDataContainer<TSource, TResult>.Destroy;
begin
  FState.Free;
  inherited;
end;

procedure TDataContainer<TSource, TResult>.FetchData;
var
  lSource: TSource;
begin
  lSource   := FSource;
  FDataTask := TTask.Run(
    procedure
    var
      lValue: TResult;
      lTrigger: TDataTrigger;
    begin
      try
        lValue := FDataAccessor( lSource );
        FValue := lValue;
        lTrigger := TDataTrigger.Data;
      except
        lTrigger := TDataTrigger.Error;
      end;

      TMonitor.Enter( FState );
      try
        FState.Fire( lTrigger );
        FDataTask := nil;
      finally
        TMonitor.Exit( FState );
      end;
    end );
end;

function TDataContainer<TSource, TResult>.GetHasValue: Boolean;
begin
  Result := FState.IsInState( TDataState.HasData );
end;

function TDataContainer<TSource, TResult>.GetIsBusy: Boolean;
begin
  TMonitor.Enter( FState );
  try
    Result := FState.IsInState( TDataState.Busy );
  finally
    TMonitor.Exit( FState );
  end;
end;

function TDataContainer<TSource, TResult>.GetValue: TResult;
begin
  TMonitor.Enter( FState );
  try
    if not HasValue
    then
      raise EInvalidOperation.Create( 'Fehlermeldung' );
  finally
    TMonitor.Exit( FState );
  end;
  Result := FValue
end;

procedure TDataContainer<TSource, TResult>.SetSource( const Value: TSource );
begin
  FSource := Value;
  TMonitor.Enter( FState );
  try
    FState.Fire( TDataTrigger.Fetch );
  finally
    TMonitor.Exit( FState );
  end;
end;

function TDataContainer<TSource, TResult>.ToString: string;
begin
  TMonitor.Enter( FState );
  try
    Result := FState.ToString;
  finally
    TMonitor.Exit( FState );
  end;
end;

end.

[Vis]

Puh, was man alles machen kann.

Aber im Prinzip entscheidest du im OnEntry von TDataState.Fetching mit Hilfe der Methode "FetchData" welcher Zustand als nächstes kommt. Also TDataTrigger.Data oder TDataTrigger.Error.

Als weiteren Punkt nehme ich mit, dass über den "DataAccessor", welcher der State Machine als anonyme Methode übergeben wird, je nach Anwendungsfall unterschiedliche Datenzugriffe möglich werden. Also je nachdem was als TSource und TResult festgelegt wird.

Ich suche eigentlich nur einen Ablauf, wenn nach einer Eingabe das Edit-Feld verlassen wird. Also das "Refetching" könnte ich mir sparen. Der Aufwand scheint mir trotzdem relativ hoch.

Setzt du diesen DataContainer universell ein? Benutzt du allgemein State Machines um z.B. Daten über Edit-Felder vom Bediener abzufragen und dann weiterzuverarbeiten?

[Sir Rufo]

Zitat von Vis:

Puh, was man alles machen kann.

Ja, ist schon nett ...

Zitat von Vis:

Aber im Prinzip entscheidest du im OnEntry von TDataState.Fetching mit Hilfe der Methode "FetchData" welcher Zustand als nächstes kommt. Also TDataTrigger.Data oder TDataTrigger.Error.

Hmmm, wenn ich in den Status Fetching komme, dann soll der Fetch-Prozess gestartet werden. Dieser kann irgendwann mit dem Trigger Data oder Error enden und der wird dann an die SM übergeben.

Es ist also keine Entscheidung, sondern ein eine Reaktion und der Status folgt dieser.

Zitat von Vis:

Als weiteren Punkt nehme ich mit, dass über den "DataAccessor", welcher der State Machine als anonyme Methode übergeben wird, je nach Anwendungsfall unterschiedliche Datenzugriffe möglich werden. Also je nachdem was als TSource und TResult festgelegt wird.

Jupp, du kannst einen String übergeben und dir damit ein Objekt irgendwo herholen (der String ist evtl. ein Dateiname und zurück kommt ein MemoryStream oder ein Text ...).

Zitat von Vis:

Ich suche eigentlich nur einen Ablauf, wenn nach einer Eingabe das Edit-Feld verlassen wird. Also das "Refetching" könnte ich mir sparen. Der Aufwand scheint mir trotzdem relativ hoch.

Wodurch was ausgelöst wird ist ja egal, man muss nur schauen, was es für Auslöser (Trigger) gibt und welche Statüsse () es gibt.

Zitat von Vis:

Setzt du diesen DataContainer universell ein?

Nö, den habe ich gerade mal zusammengehauen, sonst wär der etwas schöner

Zitat von Vis:

Benutzt du allgemein State Machines um z.B. Daten über Edit-Felder vom Bediener abzufragen und dann weiterzuverarbeiten?

Das kommt darauf an, was ich da wirklich will. Die SM alleine macht ja noch keinen vernünftigen Ablauf. Man kann nur einen Ablauf dort mit abbilden und auch einfach erweitern, umbauen, ergänzen.

Die SM wird man in den seltensten Fällen in freier Wildbahn erleben, sondern meistens (wie hier) eingebettet in einer anderen Klasse. Bei den Beispielen kann man das auch schön sehen.

[Vis]

Danke mal soweit für die Infos. Ich glaub ich muss noch viel lernen

[psycodad]

Hallo zusammen,

Ich plane so etwas wie eine Prozess-Engine zu machen um Geschäftsprozesse abzuwicken, wie z.B: eine Fakturierung. Dabei soll ein Prozess durchlaufen werden, der aus verschiedenen Schritten und ev. Abzweigern besteht. Z.B::

1. Überprüfe Daten
2. Berechne Preise
3. Erstelle Rechnungen
4. Erstelle Reports
5. Verbuche in Buchhaltung

Jeder dieser Schritte hat unter Umständen wieder Unterschritte.

Löst man sowas mit einer StateMachine? Oder gibt es da andere Patterns? Irgendwas wie eine Workflow Engine?

Ich versuche hier gerade ein paar Informationen zu bekommen wohin die Reise gehen soll: https://www.delphipraxis.net/203308-...ml#post1456756

[jobo]

Also die 5 Schritte, die Du aufführst, sind ja ziemlich übersichtlich und Du schriebst nebenan, sie seien seriell(?), also eine feste Kette von Aufrufen, keine Nebenläufigkeit, keine Überraschungen.

Eine Statemachine hat m.E. als Merkmal, dass die verschiedenen Stati in bestimmter, definierte Weise ineinander übergehen. Manche States erreicht man nur über einen Vorzustand, andere aus unterschiedlichen Zuständen, dementsprechend sind manche Endzustände, manche nicht usw.

Vermutlich bringt Dich das nicht weiter. Spannend wäre, was die erwähnten Unterschritte sind und wie veränderlich sie sind.

[Rollo62]

Es gibt von TMS ein WorkflowStudio, mit dem kann man Workflows grafisch modellieren aber auch ausführen lassen kann.
Habe jetzt nicht tiefer reingeschaut, aber das sieht mir im Prinzip stark nach Statemachine aus.

Ob man auf den TMS Komponenten aber eine größere, komplexere Businessanwendung aufbauen würde kann ich nicht sagen, ich hätte da meine Bedenken.
Ich würde aber sagen Statemachine im Prinzip ja.