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

Question

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

Мое понимание (особенно для реализации) конечного автомата немного молодое и, возможно, ему немного не хватает, но я реализую это приложение как единое целое, и у меня есть место, где мне как бы нужно иметь вложенный FSM. В основном машина имеет несколько состояний высокого уровня (Холодный (он же только что запущен), Самонаведение, Настройка, Готовность к запуску, Запуск, создание отчетов, Сброс), но когда машина работает, она должна иметь свою собственную небольшую реализацию FSM для (Загрузка Lense, Определение края, Измерение клина, Измерение округлости и Завершение [может быть, еще немного там)).

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

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

Answer 1

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

Answer 2

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

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

Answer 3

наоборот. Хорошая вещь - иметь возможность вкладывать автоматы.

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

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

То же самое относится и к автоматам.

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

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

Answer 4

Я решаю это, имея перечисление, представляющее состояния штата. Например Кролик имеет состояние Прокреации.

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

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

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