Here is again the LTS model of the door. It shows the behavior of the door, and this is also a model of the behavior of the user of the door (since we have rendezvous interactions).
Here is the definition of the same state machine using the notation of the LTSA tool:
UNLOCKED = (open -> OPEN | lock -> LOCKED),
OPEN = (close -> UNLOCKED),
LOCKED = (unlock -> UNLOCKED).
How would you model this system using the FSM formalism (with input and output messages) ?
In an FSM model, interactions are either inputs or outputs. If we assume that the user is the initiator of the interactions, then one may say that the interactions shown in the LTS diagram are all output interaction of the user and input interactions for the Door. We may then use the same state machine model and interpret it as an FSM.
However, this model presents a problem: Since the transmission of the output from the user to the Door takes some time, the user will not know when the door is open after the user sent the open command. If he sends the sequence of outputs <open, close, lock, unlock, open> very fast, the door may not be able to execute these state changes as fast as the inputs arrive and the user and the door would be out of step.
To avoid this problem, one may introduce acknowledgement messages that confirm that the last command was executed. In the following model of the Door, the interactions that represent commands (outputs from the user - inputs to the Door) have the ending "-req" (which stands for "request"). And the other interactions are input to the user (acknowledgement meesages) that confirm that the Door has executed the transition requested.
Now, this model cannot represent the behavior of the user (as in the case of the LTS model), because for the user the inputs and outputs are inverted; and an FSM transition always starts with an input. Now, the user does not get any input that tells him that he wants to open the door. To model such situations, one uses so-called spontaneous transitions, that is, transitions that are taken spontaneously by the machine without any trigger received from the environment. In a sense, a machine with spontaneous transitions is an "actor", an "active" component. The diagram below on the left side represents a model of the user with several spontaneous transitions (the input "spont" means that the transition is spontaneous). To model the user, it was necessary to introduce some intermediate states in which the user waits for the acknowledgement message of the door. The transition performed on the reception of an acknowledgement message has no output.
We note that one may rewrite the model of the Door above in a different form by including intermediate states between inputs received and corresponding outputs generated (see diagram below on the right side). This diagram has the same transition structure as the user model (on the left side). The transitions with input "imm" are also spontaneous transitions; here "imm" means "immediate", I have chosen this label because these transitions should be executed as fast as possible when the model has entered the starting state of such a transition. This is different for the spontaneous transitions labelled "spont" in the model of the user (on the left side); the user may wait long time before doing a spontaneous transition. In fact, the user may decide to STOP, that is, not do any spontaneous transition any more.
In many situations, the FSM model with its input and output messages becomes quite complex. In particular, the behaviors at the two sides of an interface have less similarity then in the case of LTS models because the nature of input and output is interchanged. The LTS model is in general more abstract and leads to more simple model descriptions.
The LTS model should be used if it can capture the aspects of the system that are to be modelled. If the aspect of which component initiates the interactions in the system should be modelled, then the FSM model is more appropriate.