-
Notifications
You must be signed in to change notification settings - Fork 1
Transition
Transition (sometimes referred to as Regular Transition) is the way to move from one State to another, by this changing stable configuration of State Machine.
Regular Transition consist of:
- Trigger, an Event which causes Transition to happen,
- Source State or Pseudostate,
- Target State or Pseudostate,
- Guard, a predicate logic (that returns boolean value) that is evaluated in order to check if Transition can happen or not,
- Effect, logic that is executed when Transition is happening.
In UML, Transition is represented by an arrow that connects two States or Pseudostates:
stateDiagram-v2
SomeState --> AnotherState : TriggerEvent
If there is any logic within Transition, it is described textually using following special characters:
stateDiagram-v2
SomeState --> AnotherState : TriggerEvent<br/>[Guard]<br/>/Effect
Equivalent Stateflows notation of Transition:
/* fragment of State Machine definition */
.AddState("SomeState", b => b
.AddTransition<TriggerEvent>("AnotherState", b => b
.AddGuard(async c => true /* bool-returning logic here */)
.AddEffect(async c => /* logic here */)
)
)
.AddState("AnotherState")Using lambda style here means that States are referred by string name and each bit of Transition logic is implemented as lambda function passed as parameters to
Add*methods in Transition definition.
public class SomeState : IState
{ }
public class AnotherState : IState
{ }
public class TriggerEvent
{}
public class TriggerEventTransition : ITransitionGuard<TriggerEvent>, ITransitionEffect<TriggerEvent>
{
public Task<bool> GuardAsync(TriggerEvent @event)
{
/* bool-returning logic here */
return true;
}
public Task EffectAsync(TriggerEvent @event)
{
/* logic here */
}
}
/* fragment of State Machine definition */
.AddState<SomeState>(b => b
.AddTransition<TriggerEvent, TriggerEventTransition, AnotherState>()
)
.AddState<AnotherState>()Using typed style here means that States and Transitions are classes that is referenced in typed overloads of
Add*methods in State Machine definition.
Note:
AddTransition<>()method accepts several type parameters. Regardless the overload variant, the order of those parameters is always the same: Trigger > Transition class > Target State / Pseudostate class.
Class can be used as Transition if it implements at least one interface from ITransition*<TEvent> family:
-
ITransition<TEvent>- simply represents Transition, -
ITransitionGuard<TEvent>- represents Transition with Guard logic implemented asGuardAsync()method, -
ITransitionEffect<TEvent>- represents Transition with Effect logic implemented asEffectAsync()method, -
ITransitionDefinition<TEvent>- represents Transition with additionalBuild()method that allows to extend its definition, for example to define Guards and Effects in Transition class.
Transition logic may also be split into several classes like in the example:
public class SomeState : IState
{ }
public class AnotherState : IState
{ }
public class TriggerEvent
{}
public class TriggerEventGuard : ITransitionGuard<TriggerEvent>
{
public Task<bool> GuardAsync(TriggerEvent @event)
{
/* bool-returning logic here */
return true;
}
}
public class TriggerEventEffect : ITransitionEffect<TriggerEvent>
{
public Task EffectAsync(TriggerEvent @event)
{
/* logic here */
}
}
/* fragment of State Machine definition */
.AddState<SomeState>(b => b
.AddTransition<TriggerEvent, AnotherState>(b => b
.AddGuard<TriggerEventGuard>()
.AddEffect<TriggerEventEffect>()
)
)
.AddState<AnotherState>()This technique enables reusing of Transition's logic.
If Transition logic does not rely on Trigger Event data and is suitable to be reused in other Transitions, Transition classes may be created by implementing at least one interface from ITransition* family:
-
ITransitionGuard- represents Transition with Guard logic implemented asGuardAsync()method, -
ITransitionEffect- represents Transition with Effect logic implemented asEffectAsync()method, -
ITransitionDefinition- represents Transition with additionalBuild()method that allows to extend its definition, for example to define Guards and Effects in Transition class.
Such classes are called Generic Transitions and may be used to declare all types of Transitions.
Home page Support Code licensed under an MIT-style License. Documentation licensed under CC BY 4.0. © by Mikołaj Milewski, 2025
Overview
Installation
Behaviors
State Machines
Building blocks
States
State
Composite State
Orthogonal State
Final State
Pseudostates
Choice
Junction
Fork
Join
Transitions
Transition
Default Transition
Internal Transition
Concepts
Evaluation of Transitions
Activities
Building blocks
Nodes
Action Node
Decision Node
Merge Node
Initial Node
Final Node
Input Node
Output Node
Fork Node
Join Node
Accept Event Action Node
Send Event Action Node
Data Store Node
Structured Activity Node
Iterative Activity Node
Parallel Activity Node
Flows
Data Flow
Control Flow
Concepts
Implicit fork and join
Actions