In questo tutorial abbiamo voluto simulare il processo di realizzazione di una semplice applicazione a partire dai suoi requisiti fino ad arrivare al test delle sue funzionalità.

Il principale vantaggio di questo approccio è, secondo noi, il fatto di poter in qualche modo "vedere" ed eseguire la logica dell'applicazione. Non abbiamo dunque bisogno di un documento che descriva il comportamento della nostra applicazione, in quanto il file sorgente scritto in XAL già fornisce questa descrizione.

D'altro canto esistono due limitazioni: la prima è che questo linguaggio si presta bene a realizzare applicazioni web orientate agli stati. La seconda è la gestione della complessità dell'applicazione. Quest'ultimo, in particolare, è un "difetto" di tutti i linguaggi basati sugli automi. Alcuni linguaggi, come gli Statecharts introdotti da Harel e adottati dallo standard UML, prevedono degli "escamotage" sintattici per minimizzare il numero di stati e transizioni richiesti quando l'applicazione diventa complessa. Per il momento lasciamo che XAL abbia una sintassi semplice e deleghiamo ad eventuali tool di sviluppo la realizzazione di una buona interfaccia che aiuti a gestire la complessità di automi molto articolati, aiutando il programmatore a concentrarsi sull'informazione più utile in ogni momento.

A questo proposito abbiamo iniziato a sviluppare un plugin per Eclipse, ma al momento è solo un prototipo e produce solo un sottoinsieme delle informazioni richieste da un file sorgente XAL. Per chi fosse interessato, i sorgenti del plugin sono scaricabili qui.

Il prossimo "passo" sarà estendere XAL con la possibilità di definire molteplici automi che calcolano concorrentemente. Questo grado di "parallelismo" nelle specifiche consentirà al programmatore di suddividere il proprio compito in sotto-task e poi sarà compito dell'interprete preoccuparsi, eventualmente, di schedulare i sotto-task su unità di calcolo parallelo, se messe a disposizione dall'architettura sottostante.