Підвищення Statechart проти Meta State Machine

Очевидно, бустер містить дві окремі бібліотеки для державних машин: Statechart і Meta State Machine (MSM). Теги надають дуже схожі описи:

• Boost.Statechart - Довільно складні машини з кінцевим станом можуть бути реалізовані в легко читабельному та підтримуваному коді C ++.
• Meta State Machine - дуже високоефективна бібліотека для виразних машин кінцевого стану UML2.

Чи знаєте ви, які ключові відмінності та які міркування у виборі між ними?

Оскільки, схоже, існує великий інтерес, будь ласка, дозвольте мені дати свою (очевидно необ’єктивну) думку, яку слід сприймати із зерном солі:

• МСМ набагато швидше
• MSM не вимагає RTTI або нічого віртуального
• MSM має більш повну підтримку UML2 (наприклад, внутрішні переходи, ортогональні регіони, відповідні UML)
• MSM пропонує описову мову (насправді кілька). Наприклад, використовуючи eUML-фронт, перехід можна описати як джерело + подія [охорона] / дія == ціль
• MSM змусить ваш компілятор постраждати від великих державних машин, тому вам знадобиться досить недавній компілятор (g ++> = 4.x, VC> = 9)

Ви можете зробити собі кращу думку, шукаючи коментарі, опубліковані під час огляду MSM. Цю тему багато обговорювали у списку розробників.

Як вже згадував Крістоф, однією з ключових відмінностей між двома бібліотеками є продуктивність виконання. Хоча MSM, мабуть, пропонує найкраще, що можна отримати тут, Statechart свідомо торгує циклами пам'яті та процесорами на кращу масштабованість.

За допомогою Boost.Statechart ви можете поширювати макет (тобто стани, переходи) вашої державної машини по декількох одиницях перекладу (файли cpp) способами, якими ви не можете використовувати MSM. Це дозволяє зробити реалізацію великих FSM більш рентабельним і отримати набагато швидший збір, ніж з MSM.

Незалежно від того, чи буде ефективність накладних витрат на Statechart порівняно з MSM, фактично важливою для вашої програми, часто досить просто відповісти, коли ви запитуєте себе, скільки подій вашому додатку доведеться обробити за секунду.

Припускаючи середньо складний FSM, реалізований з Boost.Statechart, ось декілька номерів бальних парків:

• Більшість сучасних апаратних засобів ПК легко впораються з> 100000 подіями в секунду
• Навіть дуже обмежене ресурсом обладнання зможе обробляти кілька сотень подій в секунду.

Що стосується завантаження процесора, якщо кількість подій, що обробляються, значно нижча за ці числа, накладні витрати Boost.Statechart порівняно з MSM майже напевно не помітні. Якщо кількість набагато більша, вам, безумовно, краще з MSM.

Більш детальну інформацію про ефективність та масштабованість можна знайти тут: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

Під час кодування власної реалізації ДПП я використав Statechart з трьох причин: 1) Statechart простіший і має більш чітку документацію; 2) Мені дуже не подобається UML :)

Документи Boost кажуть, що MSM принаймні у 20 разів швидший, але компілюється досить повільно для великих FSM.

Деякий час тому я почав з Statechart і перейшов до MSM, тому що його було легше використовувати спільно з asio з однієї нитки. Мені не вдалося з’єднати Statechart та його багатопотокові можливості при використанні asio - це, мабуть, якесь непорозуміння newchart Statechart з мого боку. Я виявив, що MSM було простіше у використанні, оскільки він не стосувався багатопотокової роботи.

У відповідь на запізнення Тима до дискусії (яка також стосується одного з дуже ранніх коментарів Лева).

Оскільки один з тих, хто стверджував, що вихід є відокремленим від деструкторів у державному діаграмі (аргумент, що базується на справжньому випадку використання, про взаємодію з реальним світом, тобто введення-виведення), зворотній час, коли він був поданий в Boost, я погоджуюсь, що можуть виникнути проблеми із встановленням виходу логіка в деструкторах. Девід Абрахамс також не дивно висловив переконливі аргументи щодо безпеки виключень. З цих причин Statechart не вимагає від вас логіки в деструкторах - але це дозволяє - за допомогою звичайних порад.

Логіка, яка повинна коли-небудь виконуватись як частина переходу зі стану (а не знищення об'єкта діаграми statechart в цілому), може бути (і повинна, якщо є також очищення ресурсів), відокремитись в окрему дію exit ().

Для "тонкого" стану без активного стану (ресурсів), просто виконуючи дії входу / виходу, ви можете виконати ці дії в ctor і d'tor і переконатися, що конструктор і деструктор не кидаються. Для них немає ніякої причини - немає держави, щоб виконувати RAII далі - немає зла в тому, щоб обробка помилок у цих місцях викликала відповідні події. Можливо, вам все ж доведеться розглянути питання про те, чи хочете дії виходу, які змінюють зовнішній стан, на запуск руйнування машинної машини, і ... і ввести їх у дію виходу, якщо ви не хочете, щоб вони відбувалися в цьому випадку ...

Statechart моделює активацію як екземпляр об'єкта, тому якщо у вашого конструктора є справжня робота / активація / інстанція, і якщо він не може вийти з ладу, такий стан не можна вводити. подія. Це обробляється таким чином, що розробляє ієрархію стану, шукаючи зовнішній стан, який обробляє подію винятку, аналогічно тому, як стек мав би розмотуватися для моделі виклику на основі стека викликів.

Це все добре задокументовано - я пропоную прочитати документи та спробувати. Я пропоную використовувати деструктори для очищення "програмних ресурсів" та виходу з дій для виконання "дій з виходу з реального світу".

Варто зазначити, що поширення винятків є проблемою у всіх середовищах, керованих подіями, а не лише у державних закладах. Найкраще обґрунтувати та включити несправності / помилки у свій дизайн діаграми стану, і якщо і лише тоді, коли ви не можете впоратися з ними іншим способом, вдайтеся до відображення виключень. Принаймні, це працює для мене - ymmmv….