The below diagram helps explain how StateSmith turns a diagram file into state machine code.

First, a diagram file (draw.io, yEd, PlantUML) is parsed into simple diagram objects. This intermediate step makes it relatively easy to add new diagram parsers to StateSmith.

public class DiagramNode
{
    public string id, label;
    public DiagramNode? parent;
    public List<DiagramNode> children;
}

public class DiagramEdge
{
    public string id, label;
    public DiagramNode source;
    public DiagramNode target;
}

The diagram objects are converted into SmGraph vertices which may be one of the following types (as of StateSmith 0.7.11):

public abstract class Vertex
{
    public string DiagramId;
    public Vertex? Parent;
    public List<Vertex> Children;
    public List<Behavior> Behaviors;
    public List<Behavior> IncomingTransitions;
}

The root vertices are then searched for the StateMachine Vertex to use (diagrams can define more than one).

The StateMachine Vertex then goes through a transformation pipeline (SmTransformer) to support various features and get ready for code generation.

The transformation pipeline can easily be modified by user scripts. This allows you to add custom features, validations, whatever you might need. This example project shows how to easily add custom logging to specific states.

1. RemoveNotesVertices
2. SupportRenderConfigVerticesAndRemove
3. SupportParentAlias
4. SupportEntryExit
5. SupportPrefixingModder
6. SupportHistory
7. SupportOrderAndElse
8. Validation1
9. DefaultUnspecifiedEventsAsDoEvent
10. AddUsedEventsToSm
11. FinalValidation

Once the StateMachine (and its child vertices) is finished being transformed, it is passed to the code generation stage which plops out ready to run code.

The core of StateSmith has been modified to use Dependency Injection so that users can swap in their own code generation classes, or customize almost any aspect of how StateSmith works.

More documentation will be coming for this. If you are keen now, hit us up on discord.