Durante la progettazione e lo sviluppo di programmi, ci troviamo spesso a dover affrontare la gestione dei comportamenti dei sistemi in base agli stati e agli eventi. Quando il livello di complessità dei sistemi sale minimamente sopra i livelli elementari, oppure quando il numero di stati e di eventi comincia ad aumentare, la progettazione e la realizzazione di questi sistemi diventano ingestibili se le specifiche non vengono documentate in maniera formale. E’ anche probabile che con il passare del tempo si presentino delle esigenze di dover modificare, oppure estendere, il codice e, nell’ eventualità in cui non avessimo eseguito quella formalizzazione, il nostro programma sarà talmente farcito di problemi che diventerà inutilizzabile. E sarà necessaria, prima o poi, la completa riscrittura.

Gli automi sono degli strumenti adatti per questo tipo di progettazione. In linea generale, possiamo definire un automa come un sistema dinamico discreto ed invariante. Il “discreto” si riferisce alla scansione del tempo e alla descrizione del suo stato, mentre “invariante” significa che il sistema si comporterà allo stesso modo indipendentemente dall’istante di tempo in cui si verificano degli eventi (qui li chiamiamo “simboli in ingresso”, durante il corso vedremo le ragioni per certe nomenclature) che possono portare al cambiamento dello stato.

Quello che va fatto è descrivere tutti gli stati che un automa può assumere, determinare lo stato iniziale e quello finale, il sottoinsieme dei simboli in ingresso che l’automa può accettare e quali di questi ci portano alla transizione dello stato. Inoltre dobiamo determinare se l’automa è deterministico (quando per uno stato ed un simbolo in ingresso è possibile una sola transizione) oppure non deterministico (detto anche stocastico).

A parte gli usi indicati sopra, ci sono casi dove, senza le specifiche formali e la meticolosa definizione degli automi, non è proprio possibile lavorare. Pensiamo per esempio alla creazione di un compilatore. Senza automi non siamo in grado di sviluppare un compilatore decente. La stessa cosa vale per esempio per analizzatori di testi, motori per espressioni regolari, definizioni dei protocolli, ecc. Senza automi non deterministici per esempio non esigsterebbe nemmeno la teoria della complessità algoritmica e non saremmo in grado di capire il comportamento del nostro codice in certe condizioni di lavoro. Senza la teoria degli automi non potremmo capire se un progetto che vogliamo fare sia fattibile o meno, e nel caso fosse fattibile determinare se effettivamente, a causa della complessità, fosse ingestibile. In caso di scoperta di una di queste due problematiche sarebbe necessario fare la virata in modo di cambiare approccio o metodologia o addirittura cambiare gli obiettivi. Anche qui, nei contesti menzionati sopra, abbiamo visto troppi progetti fallire poiché chi li portava avanti non si era reso conto che stava facendo qualcosa di ingestibile o addirittura impossibile.

La teoria degli automi è una materia complessa, e può durare un intero semestre del corso di laurea universitario, o anche più di uno. Il nostro corso (di durata indicativa - ed estensibile - di una settimana), di natura prettamente pratica, aiuta alle persone a capire l’essenza della materia per poter prevenire errori grossolani e per ridurre pericoli di bug dovuti agli stati inconsistenti nei quali i loro programmi si potrebbero altrimenti trovare.

Come corsi correlati, possiamo indicare i nostri corsi di algoritmi e strutture dati e anche quello sull’ingegneria del codice.