In this tutorial we have simulated the entire development process of a simple application starting from its specifications to (until) the test of its features.

In our opnion the advantage of this approach is that we can see and test (directly) the application logic. We don't need a document which describes the behavior of our application because this information is already provided by the source file written in XAL.

On the other hand two (main) limitations exist: the first (one) is that this language is suitable for creating (state-based) web applications based on states. The second (one) is the (about) handling of application complexity. This limit is a defect of all languages based on automata. Some languages, like Statecharts introduced by Harrel and adopted by UML, provide syntactical methods to minimize states and transitions number when the application becomes complex (like hierarchical states). In this phase we prefer that XAL has (to have) a simple syntax and we delegate to possible development tools the creation of a good interface which helps the programmer handle complex automaton showing each time only useful information.

To this end we have started developing an Eclipse plugin which, at the moment, makes a subset of the information requested by a XAL source file. If you are interested in this plugin you may download the source code here.

The next step is to extend XAL in order to define automata which work concurrently. This degree of parallelism will allow the programmer to divide the main task into sub-tasks: the Interpreter will take care of scheduling each sub-task on parallel CPUs if they are provided by the below architecture. Besides the performance gain, if any, there is a simplification at the design level: if the task can be divided on smaller sub-tasks, the programmer can concentrate on each of such sub-tasks design, usually ending with an automaton with less states and transitions.