¿Debería una máquina de estados finitos tener una máquina de estados finitos "anidados"?

Question

Puede leer this question donde pregunto acerca de la mejor arquitectura para una aplicación de máquina para una pequeña historia, aunque no es del todo necesario para ayudarme con esta pregunta.

Mi comprensión (especialmente para la implementación) de Finite State Machine es un poco joven y puede que falte un poco, pero estoy implementando esta aplicación como una, y tengo un lugar donde necesito tener una FSM anidado. Básicamente, la máquina tiene algunos estados de alto nivel (Cold [recién iniciado), Homing In, Setup, Ready to Run, Running, Reporting, Reseting), pero cuando la máquina se está ejecutando, necesita tener su propia pequeña implementación de FSM para (Cargando Lense, ubicando el borde, midiendo la cuña, midiendo redondez y completando [puede haber algo más allí]).

Mi pregunta es esta: ¿Debo desarrollar la capacidad de tener "estados anidados" donde un estado puede tener una lista de estados secundarios y el sistema puede ingresar esos estados secundarios y esos estados secundarios pueden retornar a estados principales? ¿O debería simplemente poner una implementación de FSM dentro del estado En ejecución, y mantenerlos como dos FSM diferentes? ¿O crees que estoy haciendo o pensando algo tonto y debería reconsiderarlo?

Pensamientos, sugerencias, críticas y consejos son bienvenidos.

Answer 1

Las máquinas de estados anidados son una noción estándar en UML, por lo que esto no es necesariamente tonto. More details here.

Answer 2

En sentido contrario. Tener la posibilidad de anidar FSM es algo bueno.

No se deben anidar FSM solo para anidar, pero a veces los FSM son bastante grandes. Tener un dibujo tan grande socava el propósito de un modelo FSM ya que no le da una buena vista del funcionamiento interno. Se convierte en un gran diagrama con muchos detalles.

Creo que puedes compararlo con las clases. Si insertas todo en una sola clase (y, lo que es peor, haces que todo estético) desaparecerán el propósito y las ventajas de tener una clase.

Lo mismo ocurre con los FSM.

Para darte un ejemplo, un collegeau mío tiene un modelo bastante "realista" del comportamiento de un perro usando FSM. Él tiene un gran modelo y al tener FSM anidados, pude entender el modelo en solo unos minutos.

Por lo tanto, definitivamente es algo bueno, si se usa correctamente.

Answer 3

Solo quiero agregar que los estados anidados (en UML FSM) no son lo mismo que "poner" un FSM separado dentro de un estado en ejecución.

En FSM jerárquicos reales, los eventos se publican primero en el estado anidado actual. Si ese estado no los maneja, se publicarán en el estado principal, y así sucesivamente. Esto le permite a uno "refactorizar" las transiciones de estados comunes desde estados anidados a un estado padre.

Answer 4

Resuelvo esto teniendo una enumeración que representa los estados del estado. Por ejemplo, Bunny tiene un estado de Procreación.

ProcreationState tiene una enumeración

enum State 
{ 
    SettinNewSearchPosition, 
    SearchingForFriend, 
    MovingTowardsFriend, 
    EstablishingFriendship, 
    Mating 
} 

En los estados actualizar método acabo de comprobar en qué estado está su adentro y actuar con disconformidad. Supongo que esto limita la capacidad general de este sistema. No soy tan experimentado así que estoy probando esto.Cualquier comentario sobre este enfoque es apreciado.