Должна ли машина конечного состояния иметь «вложенный» конечный автомат?

Question

Вы можете прочитать this question, где я спрашиваю о лучшей архитектуре для машинного приложения для небольшой истории назад, хотя это не совсем необходимо для того, чтобы помочь мне в этом вопросе.

Мое понимание (особенно для реализации) фирмы Finite State Machine немного молодое и может быть немного, но я реализую это приложение как одно, и у меня есть место, где мне нужно иметь вложенный FSM. В основном машина имеет несколько состояний высокого уровня (Cold [aka just started], Homing In, Setup, Ready to Run, Running, Reporting, Reseting), но когда машина работает, для нее требуется небольшая реализация FSM для (Загрузка линзы, расположение края, измерительный клин, измерение округлости и завершение [может быть еще там]).

Мой вопрос заключается в следующем: должен ли я построить возможность «вложенных состояний», когда состояние может иметь список под-состояний, и система может вводить эти под-состояния, и эти под-состояния могут возвращаться в родительские состояния? Или я должен просто включить реализацию FSM в состояние Running и сохранить их как два разных FSM? Или вы думаете, что я делаю или думаю что-то немое и должен переосмыслить его?

Мысли, предложения, критика и советы приветствуются.

Answer 1

Вложенные государственные машины являются стандартным понятием в UML, так что это не обязательно глупо. More details here.

Answer 2

В противоположность. Наличие возможности гнездовать FSM - это хорошо.

Нельзя устанавливать FSM только для гнездования, но иногда FSM становятся довольно большими. Наличие такого большого рисунка подрывает цель FSM-модели, поскольку оно не дает вам приятного взгляда на внутреннюю работу. Это становится просто огромной диаграммой, способной ко многим деталям.

Я думаю, вы можете сравнить его с классами. Если вы вставляете все в один класс (и, что еще хуже, делаете все статическим), цель и преимущества того, чтобы класс исчез, исчезнут.

То же самое касается FSM.

Чтобы привести пример, у моего колледжа есть модель, вполне «реалистичная» поведение собаки, использующей FSM. У него огромная модель, и благодаря наличию вложенных FSM я смог понять модель всего за несколько минут.

Так что это определенно хорошая вещь, если она используется должным образом.

Answer 3

Я просто хочу добавить, что вложенные состояния (в UML FSM) не совпадают с «помещением» отдельного FSM в рабочее состояние.

В реальных иерархических FSM события сначала отправляются в текущее вложенное состояние. Если это состояние не обрабатывает их, они будут отправлены в родительское состояние и так далее. Это позволяет «реорганизовать» переходы общего состояния из вложенных состояний в родительское состояние.

Answer 4

Я решаю это путем перечисления состояний государства. Например, Bunny имеет состояние Procreation.

ProcreationState имеет перечисление

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

В государствах обновления метод я просто проверить, в каком состоянии его и действовать acordingly. Я предполагаю, что это ограничивает общую способность этой системы. Я не так опытен, поэтому я это пробовал.Любые отзывы об этом подходе оцениваются.