Behaviors

Overview

Core concept of Stateflows framework is Behavior: piece of executable logic which is addressable, has its own persistent state and can be interacted with by Events sent to it and received from it.

Behaviors differ in the way they accept and process incoming Events; they can use different notations and have different structure, which is also executed differently.

Stateflows provides two notations (also called Behavior Types):

1. State Machine (designed to manage processes),
2. Activity (more suited for data processing).

Stateflows notations are based on UML 2.5.1 behavioral diagrams specifications.

Definition of Behavior (f.e. State Machine structure) is called Behavior Class.

For each Behavior Class there can be multiple addressable Behaviors, distinguished by string-based Instance ID.

Lifecycle

Each Behavior has its own lifecycle:

1. Before any interaction with it, it has status NotInitialized.

Actually, before any interaction with Behavior, it exist only virtually. Behavior represents virtual actor in Stateflows framework.

2. By default, first interaction (first Event sent to it) initializes Behavior and enables it to consume next incoming Events.

Initialization can be customized, so developer can decide whether it should happen or not. Refer to Custom initialization for more details.

3. Behavior can also finish its work and be marked as Finalized, which means that no further Events will be consumed by it (with exception of some System Events).

Definition

To define Behavior, you must define State Machine or Activity.

What should I choose?

State Machines are better suited to manage interactive processes and Activities are tailored to process loads of data. Quick comparison:

State Machines	Activities
Models states flow	Models data flow
Is executed sequentially	Is executed in parallel
Should execute quickly	Can execute for long time
Can accept Events as Transition triggers	Can accept Events in AcceptEventActions
-	Can accept Tokens as input
-	Can produce Tokens as output

When to use State Machine?

• You have a business object which should behave differently in different states,
• You want to integrate actions on a business object that are run by different clients,
• You want to build your UI the way that enables only actions that are available for your business object,
• You want to build UI wizard/creator process.

When to use Activity?

• You have a heavy calculations to run,
• You want to integrate data input from dirrent clients into single processing flow,
• You want to add interactivity to your data processing.

Mixing both worlds

Sometimes there is a need to combine both models, f.e. when process managed by State Machine involves heavy processing steps. Stateflows enables that by allowing developer to extend a State Machine with Embedded Activities.

Interacting with Behavior

Behavior can be interacted with by sending Events to it. In order to do that, Behavior handle must be located using IBehaviorLocator:

using Stateflows;

namespace Example
{
    public class DocumentService(IBehaviorLocator locator) // IBehaviorLocator is available via Dependency Injection
    {
        public Task ConfirmAsync(int documentId)
        {
            if (locator.TryLocateBehavior(new BehaviorId(BehaviorType.StateMachine, "Document", documentId.ToString()), out var document))
            {
                await document.SendAsync(new Confirm());
            }
        }
    }
}

Each Behavior Type has its own, specialized types of locator and Behavior handle interfaces:

• IStateMachineLocator and IStateMachineBehavior for State Machines,
• IActivityLocator and IActivityBehavior for Activities.

For more detailed documentation, please refer to State Machines and Activities, respectively.