Wanneer en Waarom

FSM’s staan er om bekent om robuust te zijn, dit wil zeggen dat het programma nooit iets zal doen wat niet in een state staat. Als tweede is een FSM heel overzichtelijk. Omdat je maar een eindig aantal states hebt, kan je precies zien wat het programma doet en wat voor input je moet geven om naar een andere state te gaan. Voor FSM’s zijn heel overzichtelijke schema’s beschikbaar waar we straks naar gaan kijken. Ook zijn FSM’s makkelijk aan te passen. Een nieuwe state kan makkelijk toegevoegd te worden. Omdat er maar een eindig aantal states zijn, kan er makkelijk gevonden worden in welk gedeelte iets fout gaat. Stel een robot crasht tijdens het lopen, dan weet je dat dit tijdens de loop state is gebeurd. Ook zijn er nadelen, Vaak heeft een FSM veel code, dit was vroeger vaak onhandig omdat er niet veel geheugen was, wat nu geen probleem meer is. Maar omdat er veel code is, is het systeem niet altijd optimaal. Het is logisch dat 5 regels code sneller uit te voeren is dan 10 regels code. Omdat er niet meer dan twee states tegelijkertijd uitgevoerd kunnen worden, is een FSM niet altijd mogelijk. Wel zou je een state kunnen maken die deze twee states beiden uitvoert. Dus hieruit kunnen we concluderen dat FSM ideaal zijn voor snelle prototypes. Er kan namelijk snel getest worden op fouten en waar deze fouten zich bevinden. Wel moet duidelijk zijn wat de input kan zijn en moeten alle routes naar de state goed gedefinieerd zijn. Ook zou een FSM ideaal zijn als een groot probleem opgedeeld kan worden in kleinere delen, zoals een robot.