In this section we informally test the application. The test is about "jumping" through a series of states using specific time intervals: in this way we can practically observe that some "decisions" really depend on the time constraints we defined before.

In order to simplify the test phase, the XAL application itself has been included within this page. The XAL application interface consists of two parts which are divided by the horizontal line: the application GUI and some debug information. Debug information will be useful in determining the current automaton state. In particular the "Current State" section shows the current state name, the automaton variables status, static information related to the temporal variables the automaton has been initialized with, static information related to the states and transitions which have been specified during the automaton definition phase. The last part of debug information consists of references to those pieces of code which actually constitute the automaton ActionPool. Each piece of code will be called as metric or action function associated with a specific state.

1. First test: a "normal" activation.

We simulate the line activation process without "breaking" the time constraints specified for a regular activation. Now we perform these steps using the application GUI:

1. Process Beginning/Start -[START]->
2. Order Creation/NewOrder (scegli "ISDN") -[SEND]->
3. {clockA := 0} Order sent to Carrier/OrderLine 
          -[START PROCESSING]-{clockA < 60 secondi}->
4. {clockB := 0} Order is being processed by carrier/PerformLineActivation
          -[CARRIED_OUT]-{clockB < 60 secondi}->
5. Processing carried out by carrier/LineActivationPerformed -[ACTIVATED]->
6. Line properly activated/LineWorking -[COMPLETED]->
7. Line activated/OrderPerformed -[START]->
8. Process Beginning/Start 

Let us explain the test case above and the information appearing on it. Each step specifies the title of the state in which the automaton should be followed by the name of the state itself. For instance, at step 3 we are in a state whose title is "Order sent to Carrier" and whose name is "OrderLine". During the test, the correctness of such information can be checked comparing the (should-be) title and name with, respectively, the title appearing on the screen and the state name appearing in section "Current State:" among the printed Debug information. In square brackets, instead we specify the label of the link or button that should be clicked in order to let the automaton jump to the next state. For example, in order to jump from step 3 to step 4, we expect the user to click the link labeled "START PROCESSING".

When we specify a command {clockA := 0} (clock-reset) and after a while a command {clockB < 60 seconds} (clock-check) we want to specify that between the two actions you can spend at most 60 seconds. Variables such as clockA are pseudo-variables because they are used in the test case only and they aren't necessarily real clock variables appearing in our automaton definition. This choice is justified by the fact that the people performing)the test need specifications which should not depend on the application code. We may also observe that the two commands, clock-reset and clock-check, even if they refer to the same pseudo-variable, may appear in different steps of the test case.

In this test we can check that if the two time constraints (which are the same we have previously defined in the automaton specification) are satisfied, the line will be properly activated and the application will go back to the initial state. We can also observe that when we choose "ISDN" in "Order creation" state we assign the value "isdn" to the (POST) variable "lineChosen". Since this variable has the same name of a variable of our automaton, the runtime language support will update the value of this variable in the "Environment" section of Debug Information.

2. Second test: delay in sending the practice to the Carrier

We simulate the line activation process with delay in sending the practice to the Carrier.

1. Process Beginning/Start -[START]->
2. Order Creation/NewOrder (we choose "ADSL") -[SEND]->
3. {clockA := 0} Order sent to Carrier/OrderLine 
            -[START_PROCESSING]-{clockA > 60sec}->
4. Processing canceled/OrderCanceled -[START]->
5. Process Beginning/Start

In this test we observe that if we wait for a period of time greater than 60 seconds, the automaton jumps into a different state, where we eventually handle the "error" condition. When the automaton is in this state the application notifies that too much time was passed and so the customer isn't under an obbligation to the Carrier any more. is without obligations, with respect to our company.

3. Third test: delay in line activation by the Carrier

We simulate the line activation process with delay in line activation by the Carrier.

1. Process Beginning/Start -[START]->
2. Order Creation/NewOrder (we choose "ADSL") -[SEND]->
3. {clockA := 0} Order sent to Carrier/OrderLine 
            -[START_PROCESSING]-{clockA < 60 sec}->
4. {clockB := 0} Order is being processed by carrier/PerformLineActivation 
            -[SUSPENSION]-{clockB == 10 sec}->
5. Suspension by carrier/SuspendLineActivation 
            -[RESTART_PROCESSING]-{clockB == 70 sec}->
6. Resume line activation process/ResumeLineActivation 
            -[CARRY OUT ORDER]-{clockB > 70 sec}->
7. Processing canceled/OrderCanceled -[START]->
8. Process Beginning/Start

In this test we observe that if the line activation is performed by the Carrier (CARRY OUT ORDER) after the given time limit (in this example 60 seconds) was passed the order will be canceled and the customer won't be under an obligation to the Carrier.

In this example we suspend the line activation process for 50 seconds (in fact the difference between clockB (step 6) and clockB (step 5) is 50 seconds). The line activation process can be suspended and restarted more than once (with different time intervals) but if we choose CARRY OUT ORDER command after a period of time greater than 60 seconds the order will be canceled anyway.

4. Fourth test: a canceled line activation and a performed line activation

We simulate the activation process of two lines: the first line, adsl, will be canceled due to delay in sending the order to the Carrier (as in our second test case); the second line, isdn, will be properly activated (as in our first test case). In order to perform this test we (merely) follow (the) steps of second and first test.

The aim of this last test case is to show that our Interpreter properly resets activation process information when one process finishes and a new one begins.

In particular we observe that the Interpreter loses the information related to the previously unactivated line and clock variables are properly reset when the new activation process begins.