"Невозможное возможно… по частям." — Не хватает разделения на некие главы и содержания по ним в начале. Это упростило бы восприятие, а не согласованность и смена тем текста стали бы менее заметными)
Да, наверное, стоило бы сменить заголовок и предупреждать людей, что читать много (:
1. В данном случае имя перехода и является триггером. Логика определения "доступности" перехода описывается в OnEnter/OnExit, как раз там определяется следующий переход. 2. Возможно, вы правы и OnEnter/OnExit стоит объединить в одно событие. 3. Вы можете вынести некую проверку в отдельный метод и вызвать его в необходимых OnEnter/OnExit событиях, тем самым избежать дублирования кода. 4. Графический редактор позволяет описать лишь структуру и не содержит какую-либо логику самой работы автомата. Для схемы все переходы равновероятны, так как все зависит от логики, которая будет описана при использовании.
Графический редактор позволяет создавать обратные перехода:
Скриншот примера с обратным переходом
И циклы (переход из состояния в это же состояние):
Скриншот примера с циклом
Для циклов удалось придумать удобное решение (по моему мнению).
Обратные переходы не очень наглядны. Пока что не придумал как сделать это наиболее наглядным, сохранив название перехода внутри узла.
Если у вас есть идеи, как сделать схему в редакторе удобнее — пожалуйста, напишите здесь или создайте issue. Так же вы можете принять участие в проекте, за что я буду вам очень благодарен :)
1. Так как конечный автомат — это "абстрактная модель", её реализация почти одинаковая для большинства задач. В данном случае, суть задачи можно опустить + основная идея задачи заключалась именно в реализации конечного автомата, с целью закрепления теории.
2. Перед реализации мной был проведен анализ и сравнение существующих решений.
Основные выявленные недостатки:
Многие из них платные
Отсутствие "верификации".
Под верификацией я подразумеваю проверку на уникальность имен состояний и переходов. По определению конечного автомата, состояния — это множество, а не мультимножество. Данной проверки у многих редакторов нет.
В ряде случаев таблица переходов понятнее, чем граф. Графических редакторов с возможностью посмотреть таблицу переходов — я не нашел.
Реализованное графическое представление отличается от стандартного представления в виде графа. Наименования переходов находятся внутри узла. Такой подход используется в gamedev, например, в Unity и Unreal engine, где конечные автоматы огромные. Это позволяет "разгрузить" схему и сделать её более читабельной.
Подход с Graphviz используется, например, в библиотеке stateless. И если я правильно понял — то Graphviz по описанному на языке DOT формату отображает статичную картинку.
В таком случае алгоритм работы будет такой:
Меняем код
Делаем экспорт в DOT и смотрим на картинке что получилось
Меняем код
Делаем экспорт в ...
Это не удобно. Мой подход позволяет отредактировать структуру графически.
Поэтому сейчас я предложил использовать в stateless свой редактор(issue).
3. Разве плохо в свободное время изучать новые технологии?
Как обсуждалось ранее, редактор может быть использован с другими библиотеками. Поэтому кроссплатформенность сделает его более универсальным.
Графический редактор работает отдельно от библиотеки, взаимодействие между ними происходит через xml файл.
Если вы хотите использовать графический редактор с другой библиотекой — вы можете сделать это. Все что вам нужно — написать "преобразование" из структуры в формате xml в структуру, которую поддерживает необходимая вам библиотека. Это не займет у вас много времени.
Пример структуры, которая используется в моем решении:
Также вы можете написать и обратное преобразование из ваше структуры — в xml. Тогда вы сможете экспортировать схему из вашей библиотеки в графический редактор.
Таким образом, написав не большое количество кода вы реализуете полноценную работу между редактором и вашей библиотекой. Работа с xml поддерживается на любом языке программирования.
Если ваш предыдущий вопрос был именно про это — прошу прощения, не правильно вас понял.
Здравствуйте, спасибо за комментарий
1. Да, инструмент подходит только для C#
2. Такой инструмент (CC_SMC) не видел, сейчас вот быстренько ознакомился.
Тут немного разные подходы:
1. Судя по скриншотам схема конечного автомата рисуется на консоли. То есть мы получаем статическое изображение, которое не можем редактировать. При большом количестве состояний схема может стать совсем тяжело читаемой.
2. Реализованный мной подход более прост и понятен.
Но это лишь мое мнение:)
Возможно, как я и описывал в статье, кодо-генерация в моем подходе может быть использована для реализации более удобной работы с состояниями их схемы.
3 В библиотеке есть возможность получить список переходов из состояния :
И список переходов в состояние:
Документацию вы можете найти здесь
1. В данном случае имя перехода и является триггером. Логика определения "доступности" перехода описывается в OnEnter/OnExit, как раз там определяется следующий переход.
2. Возможно, вы правы и OnEnter/OnExit стоит объединить в одно событие.
3. Вы можете вынести некую проверку в отдельный метод и вызвать его в необходимых OnEnter/OnExit событиях, тем самым избежать дублирования кода.
4. Графический редактор позволяет описать лишь структуру и не содержит какую-либо логику самой работы автомата. Для схемы все переходы равновероятны, так как все зависит от логики, которая будет описана при использовании.
Графический редактор позволяет создавать обратные перехода:
И циклы (переход из состояния в это же состояние):
Для циклов удалось придумать удобное решение (по моему мнению).
Обратные переходы не очень наглядны. Пока что не придумал как сделать это наиболее наглядным, сохранив название перехода внутри узла.
Если у вас есть идеи, как сделать схему в редакторе удобнее — пожалуйста, напишите здесь или создайте issue. Так же вы можете принять участие в проекте, за что я буду вам очень благодарен :)
5. Отличная идея, спасибо :)
Добрый день, переходы представляются кривыми Безье 3-го порядка. Реализовываются с помощью BezierSegment — встроенного геометрического примитива.
Перерисовка реализована за счет отслеживания позиции узла.
Спасибо за вопрос, постараюсь раскрыть подробнее этот момент в следующей статье
1. Так как конечный автомат — это "абстрактная модель", её реализация почти одинаковая для большинства задач. В данном случае, суть задачи можно опустить + основная идея задачи заключалась именно в реализации конечного автомата, с целью закрепления теории.
2. Перед реализации мной был проведен анализ и сравнение существующих решений.
Основные выявленные недостатки:
Под верификацией я подразумеваю проверку на уникальность имен состояний и переходов. По определению конечного автомата, состояния — это множество, а не мультимножество. Данной проверки у многих редакторов нет.
Реализованное графическое представление отличается от стандартного представления в виде графа. Наименования переходов находятся внутри узла. Такой подход используется в gamedev, например, в Unity и Unreal engine, где конечные автоматы огромные. Это позволяет "разгрузить" схему и сделать её более читабельной.
Подход с Graphviz используется, например, в библиотеке stateless. И если я правильно понял — то Graphviz по описанному на языке DOT формату отображает статичную картинку.
В таком случае алгоритм работы будет такой:
Это не удобно. Мой подход позволяет отредактировать структуру графически.
Поэтому сейчас я предложил использовать в stateless свой редактор(issue).
3. Разве плохо в свободное время изучать новые технологии?
Как обсуждалось ранее, редактор может быть использован с другими библиотеками. Поэтому кроссплатформенность сделает его более универсальным.
Если кодо-генерация, действительно нужна — можно это сделать:)
Необходимые языки: С, С++, C#, Java, Python?)
Создайте issue и опишите свою идею в репозиторий редактора, чтобы другие могли поддержать идею
Графический редактор работает отдельно от библиотеки, взаимодействие между ними происходит через xml файл.
Если вы хотите использовать графический редактор с другой библиотекой — вы можете сделать это. Все что вам нужно — написать "преобразование" из структуры в формате xml в структуру, которую поддерживает необходимая вам библиотека. Это не займет у вас много времени.
Также вы можете написать и обратное преобразование из ваше структуры — в xml. Тогда вы сможете экспортировать схему из вашей библиотеки в графический редактор.
Таким образом, написав не большое количество кода вы реализуете полноценную работу между редактором и вашей библиотекой. Работа с xml поддерживается на любом языке программирования.
Если ваш предыдущий вопрос был именно про это — прошу прощения, не правильно вас понял.
1. Да, инструмент подходит только для C#
2. Такой инструмент (CC_SMC) не видел, сейчас вот быстренько ознакомился.
Тут немного разные подходы:
1. Судя по скриншотам схема конечного автомата рисуется на консоли. То есть мы получаем статическое изображение, которое не можем редактировать. При большом количестве состояний схема может стать совсем тяжело читаемой.
2. Реализованный мной подход более прост и понятен.
Но это лишь мое мнение:)
Возможно, как я и описывал в статье, кодо-генерация в моем подходе может быть использована для реализации более удобной работы с состояниями их схемы.