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

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

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

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

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


c# c#-3.0 finite-automata
person Max Schmeling    schedule 24.08.2009    source источник
comment
вложенные состояния хороши, ИМО. Вы уверены, что имеете в виду самонаведение, а не хонинг?   -  person Beth    schedule 25.08.2009
comment
Да, самонаведение. Как найти исходную позицию.   -  person Max Schmeling    schedule 25.08.2009

Ответы (4)


arrow_upward
9
arrow_downward

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

person Daniel Earwicker    schedule 24.08.2009

arrow_upward
4
arrow_downward

В отличие. Возможность вкладывать конечные автоматы - это хорошо.

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

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

То же самое и с автоматами.

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

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

person Henri    schedule 24.08.2009

arrow_upward
3
arrow_downward

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

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

person Daniel Gehriger    schedule 20.01.2011

arrow_upward
0
arrow_downward

Я решаю эту проблему, имея перечисление, представляющее состояния состояния. Например, у Банни состояние продолжения рода.

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

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

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

person Daarwin    schedule 20.04.2017