Сравнение Boost StateCharts с «Квантовыми диаграммами состояний» Самека - PullRequest
7 голосов
/ 26 августа 2010

У меня было сильное знакомство с «Квантовой иерархической машиной состояний» Миро Самека, но я хотел бы знать, как она сравнивается с Boost StateCharts - как сказал кто-то, кто работал с обоими. Любой берущий?

Ответы [ 3 ]

6 голосов
/ 29 сентября 2010

Я знаю их обоих, хотя и на разных уровнях детализации. Но мы можем начать с различий, с которыми я столкнулся, может быть, есть и другие :-).

Область

Во-первых, Quantum Platform предоставляет полную среду исполнения для конечных автоматов UML, тогда как boost :: statechart только помогает реализациям конечных автоматов. Таким образом, boost :: statechart предоставляет тот же механизм, что и процессор событий Quantum Platform (QEP).

Соответствие UML

Оба подхода разработаны для соответствия UML. Тем не менее, Quantum Platform выполняет переходные действия перед тем, как завершит действия соответствующего состояния. Это противоречит UML, но на практике это редко является проблемой (если разработчик знает об этом).

Boost :: statechart разработан в соответствии с UML 1.4, но, насколько мне известно, семантика исполнения не изменилась в UML 2.0 несовместимым образом (пожалуйста, исправьте меня, если я ошибаюсь), так что это тоже не должно быть проблемой.

Поддерживаемые функции UML

Обе реализации не поддерживают полный набор функций конечного автомата UML. Например, параллельные состояния (или состояния AND) не поддерживаются напрямую в QP. Они должны быть реализованы вручную пользователем. Boost :: statechart не поддерживает внутренние переходы, потому что они были введены в UML 2.0.

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

Фактически оба поддерживают самые важные функции диаграммы состояний.

Другие отличия

Другое отличие состоит в том, что QP подходит для встроенных приложений, тогда как boost :: statechart может быть, а может и нет. В разделе часто задаваемых вопросов написано «это зависит» (см. http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/faq.html#EmbeddedApplications),, но для меня это уже большой предупреждающий знак.

Кроме того, вы должны выполнить специальные измерения, чтобы получить поддержку boost :: statechart в режиме реального времени (см. FAQ).

Так много различий, которые я знаю, скажите мне, если вы найдете больше, мне было бы интересно!

4 голосов
/ 13 декабря 2012

Я также работал с обоими, позвольте мне подробно остановиться на замечательном ответе Dmi:

Возможность трассировки: QP также реализует мощную возможность трассировки, называемую QSpy, которая обеспечивает очень тонкие трассировки гранулярности с возможностями фильтрации.С бустом вам нужно накатывать свои собственные, и вы никогда не выходите за пределы определенной детализации.

Современная проверка ошибок стиля и времени компиляции C ++: в то время как Boost MSM и Statecharts выдают ужасные и очень длинные сообщения об ошибках, если вы ошибаетесь (какделает весь код, написанный шаблонными гениями, которым я завидую), это намного лучше, чем обнаружение ошибок во время выполнения.QP использует Q_ASSERT () и подобные макросы для некоторой проверки ошибок, но в целом вы должны следить за собой с QP, а код менее долговечен.Я также считаю, что широкое использование препроцессора в QP требует некоторого привыкания.Может быть гарантировано использование препроцессора, а не шаблонов, виртуальных функций и т. Д. Из-за использования QP во встроенных системах, где компиляторы C ++ часто хуже, а оборудование менее дружественно к виртуальным функциям, но иногда мне бы хотелось, чтобы г-н Самек сделал C,C ++ и Modern C ++ версия;) По слухам, я не единственный, кто ненавидит препроцессор.

Масштабируемость: Boost MSM не подходит ни для чего выше 20 состояний, у диаграмм состояний практически нет ограничений на состояния, но количество переходов, которые может иметь состояние, ограничено ограничениями mpl :: vector / list.QP масштабируется до безумной степени, возможны практически неограниченные состояния и переходы.Следует также отметить, что конечные автоматы QP могут быть распределены по множеству файлов с небольшими зависимостями.

Разработка на основе моделей: благодаря своей исключительной масштабируемости и гибкости QP гораздо лучше подходит для разработки на основе моделей, см. Эту статьюдля длительного сравнения: http://security.hsr.ch/mse/projects/2011_Code_Generator_for_UML_State_Machines.pdf

Встраиваемые проекты: QP - единственное решение для любого вида встроенного дизайна, на мой взгляд.Он документирован вплоть до самых простых, поэтому его легко переносить, порты существуют для многих многих распространенных процессоров, и он приносит много вещей за пределы функциональности конечного автомата.Мне особенно нравятся необработанные очереди с защитой потоков и управление памятью.Я никогда не видел встроенного ядра, которое мне нравилось, пока я не попробовал ядро ​​RTC в QP (хотя следует отметить, что я еще не использовал его в рабочем коде).

0 голосов
/ 26 августа 2010

Я незнаком с Boost StateCharts, но мне кажется, что Самек ошибается в том, что он связывает переходные действия с контекстом состояния.Действия перехода должны происходить между состояниями.

Чтобы понять, почему мне не нравится этот стиль, требуется пример:

Что если в состоянии есть два разных перехода?Тогда события будут другими, но исходное состояние будет одинаковым.

В формализме Самека переходные действия связаны с контекстом состояния, поэтому вы должны выполнять одно и то же действие на обоих переходах.Таким образом, Samek не позволяет вам выражать чисто модель Мили.

Хотя я не приводил сравнение с Boost StateCharts, я предоставил вам некоторые подробности о том, как критиковать реализации StateCharts: анализируя связьсреди различных компонентов, составляющих реализацию.

...