Apunte de FSM (Ingeniería I)

Las máquinas de estado finito se utilizan para modelar un sistema reactivo, es decir, que reacciona ante distintos eventos pasando por sucesivos estados; a diferencia de un sistema transformacional, que simplemente toma un input y arroja un resultado, sin mayor interacción.

Checklist

Transiciones

• Nombrar todas las transiciones.
• Las condiciones para una transición van entre []. Las acciones, entre {}.
• Para denotar muchos cursos de acción posibles, como por ejemplo, números de una ruleta, se hacen 37 transiciones entre dos estados (se escriben solamente la 1era y la última, con puntos suspensivos en el medio), y a cada uno se le pone como acción {Resultado = 0}... {Resultado = 36}.
• En caso de que pueda haber un estado "final" para una cierta FSM, como por ej, jugadores que pierden, recordar que ese estado final debe tener TODAS las transiciones que sincronicen como autoflechas, si no el sistema no puede ejecutar más acciones comunes a todas las máquinas pues la FSM que quedó en ese estado no tiene la transición.

Variables

• Las variables son globales, y como tales, tienen que tener sufijo "i" si hay una para cada FSM distinta. Pueden usarse arreglos también.
• Pueden usarse para comunicación entre FSMs, al ser globales.
• El dominio de las variables debe ser acotado, aunque sea por un valor arbitrario MAX. Los dominios tipicos son enteros de 1 a N, o booleanos.
• Notar que no existe un tipo fecha para las variables, se puede usar cantidad de dias.

Sincronizacion

• Agregar el sufijo "i" para todas las transiciones que no deban sincronizar.
• Para las transiciones que sincronicen, agregar un ! si es el agente que inica la acción, y ? si es quien la recibe.

Tiempo

• Los tiempos se pueden denotar de forma descriptiva, con una transicion de "pasaron x min".
• Si se usan FSM temporizadas, se declara una variable timer (recordar de declarar una por transición por FSM, agregar sufijo i si corresponde), se inicializa en la transición previa al estado que se quiere controlar usando {t}, y se le pone al estado como condición de permanencia [t < x min].
• Con FSM temporizadas, si se quiere forzar una salida por una transicion en particular cuando se termina el tiempo, se pone como condicion en dicha transicion [t >= x min] y en las demas [t < x min].

Patterns

• Si se quiere modelar un recurso que se debe usar de a uno por vez (region critica), se puede usar una variable global como mutex, tal que la condicion para pasar de estado sea [Usado = False] y la accion {Usado = True}, y al salir del estado y liberar el recurso se ejecute {Usado = False}. Notar que Usado NO debe tener sufijo i, ya que se corresponde al recurso, y no a la maquina i que la esta usando.
  • Para modelarlo sin variables, usando una FSM Recurso, se hacen solamente dos estados (A y B). De A a B se dibujan N transiciones, donde N es la cantidad de usuarios que hay; cada transicion es del estilo Ocupa1, Ocupa2... OcupaN. De B a A, lo mismo pero Libera1,... LiberaN.
  • Para evitar que entre el usuario 1 y salga en 2, la FSM correspondiente a cada usuario debe ser de la forma A -> Ocupa i -> B -> Libera i -> C. De esta forma, una vez que el recurso fue ocupado, el unico que puede ejecutar la transicion de liberar sea el mismo usuario que lo ocupo.
• Puede que haya un manager que de órdenes a los usuarios, lo cual se modela generalmente usando labels que sincronicen. Pero si las ordenes que dan a cada usuario dependen del estado en que se encuentra, o pueden no ser las mismas para todos, no es posible usar transiciones globales.
  • Una posibilidad es quitar esa transicion del manager, y cambiar la descripción del usuario de "Hacer Algo i?" a "Manager me dice que haga algo i".
  • La otra es tener N monitores, uno para cada usuario, que actúan como managers individualizados, y que se adaptan al estado de cada usuario.

Varios

• Al final de un ejercicio que implique la composición de varias FSMs, escribir la composición como FSMEjercicio = FSMManager || FSMParticipante1 || FSMParticipante2 || ... || FSMParticipanteN.