The Boost Statechart Library - Rationale

Boost , ,

The Boost Statechart Library

Rationale

Introduction

Why yet another state machine framework

State-local storage

Dynamic configurability

Error handling

Asynchronous state machines

User actions: Member functions vs. function objects

Limitations

Introduction

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

Подъем. Statechart должен...

1. быть полностью безопасным. По возможности, несоответствия типов должны быть отмечены ошибкой во время компиляции.
2. Не требует использования генератора кода. Многие из существующих FSM-решений вынуждают разработчика проектировать государственную машину либо графически, либо на специализированном языке. Все или часть кода генерируется
3. позволяет легко трансформировать UML-статус (определяется вhttp://www.omg.org/cgi-bin/doc?formal/03-03-01)в рабочую машину. Напротив, существующая реализация на C++ машины состояний должна быть довольно тривиальной для преобразования в UML. В частности, следует поддерживать следующие функции государственных машин:
   • Иерархические (составные, вложенные) состояния
   • Ортогональные (конкурентные) состояния
   • Вступление, выход и переход
   • Охрана
   • Неглубокая/глубокая история
4. произвести настраиваемую реакцию, когда исключение C++ распространяется из кода пользователя
5. поддерживают синхронные и асинхронные машины состояния и оставляют его пользователю, в потоке которого будет работать машина асинхронного состояния. Пользователи также должны иметь возможность использовать библиотеку потоков по своему выбору.
6. поддержка разработки произвольно больших и сложных государственных машин. Несколько разработчиков смогут работать на одной и той же машине одновременно
7. позволяет пользователю настроить все управление ресурсами так, чтобы библиотека могла использоваться для приложений с жесткими требованиями реального времени.
8. как можно больше времени на сборку. В частности, недействительные государственные машины не должны компилироваться.
9. предлагает разумную производительность для широкого спектра приложений

Why yet another state machine framework?

Прежде чем я начал развивать эту библиотеку, я посмотрел на следующие рамки:

• Фреймворк, сопровождающий книгу «Практические государственные диаграммы на C/C++» Миро Самека, CMP Books, ISBN: 1-57820-110-1
  http://www.quantum-leaps.com
  Не удовлетворяет по меньшей мере требованиям 1, 3, 4, 6, 8.
• Фреймворк, сопровождающий «Rhapsody in C++» от ILogix (решение для генератора кода)
  http://www.ilogix.com/sublevel.aspx?id=53
  Это похоже на сравнение яблок с апельсинами. Тем не менее, нет никакой врожденной причины, по которой генератор кода не может производить код, который может быть легко понят и изменен людьми. Не удовлетворяет по крайней мере требованиям 2, 4, 5, 6, 8 (до генерации кода достаточно проверки ошибок).
• Рамки, сопровождающие статью «Государственный машинный дизайн на C++»
  http://www.ddj.com/184401236?pgno=1
  Не удовлетворяет по меньшей мере требованиям 1, 3, 4, 5 (нет прямой поддержки потоков), 6, 8.

Я верю, что Буст. Statechart удовлетворяет всем требованиям.

State-local storage

Эта еще не широко известная особенность государственного аппарата обусловлена тем, что каждое состояние представлено классом. При входе в состояние создается объект класса, и объект позже разрушается, когда государственная машина выходит из состояния. Любые данные, которые полезны только до тех пор, пока машина находится в состоянии, могут (и должны) быть, таким образом, членом государства. Эта функция в сочетании с возможностью распространения государственной машины над несколькими переводными единицами позволяет практически неограниченную масштабируемость.  

В большинстве существующих фреймворков FSM вся государственная машина работает в одной среде (контекст). То есть все ручки ресурсов и переменные, локальные для государственной машины, хранятся в одном месте (как правило, как члены класса, который также происходит от какого-то класса государственной машинной базы). Для больших государственных машин это часто приводит к тому, что класс имеет огромное количество членов данных, большинство из которых необходимы лишь ненадолго в крошечной части машины. Таким образом, государственный машинный класс часто становится горячей точкой изменения, что приводит к частым рекомпиляциям всей государственной машины.

Пункт FAQ «Что так круто в отношении локального хранилища?» далее объясняет это, сравнивая учебник StopWatch с поведенчески эквивалентной версией, которая не использует государственное локальное хранилище.

Dynamic configurability

Two types of state machine frameworks

• Фреймворк машины состояния поддерживает динамическую настраиваемость, если вся компоновка машины состояния может быть определена во время выполнения («выкладка» относится к состояниям и переходам, действия по-прежнему задаются обычным кодом C++). То есть данные, доступные только во время выполнения, могут быть использованы для создания произвольно больших машин. См. "A Multiple Substring Search Algorithm" by Moishe Halibard and Moshe Rubin in June 2002 issue of CUJ for a good example (unfortunately not available online).
• С другой стороны, это структуры государственных машин, которые требуют, чтобы макет был указан во время компиляции.

Государственные машины, построенные в режиме бега, почти всегда убегают с простой государственной моделью (ни иерархических состояний, ни ортогональных состояний, ни действий входа и выхода, ни истории), потому что компоновка очень часто совместима с алгоритмом. С другой стороны, машинные макеты, которые фиксируются во время компиляции, почти всегда разрабатываются людьми, которые часто нуждаются/желают сложной модели состояния, чтобы сохранить сложность на приемлемых уровнях. Таким образом, динамически настраиваемые фреймворки FSM часто оптимизированы для простых плоских машин, в то время как воплощения статического варианта, как правило, предлагают больше возможностей для абстракции.

Тем не менее, полнофункциональные динамические библиотеки FSM существуют. Итак, вопрос:

Why not use a dynamically configurable FSM library for all state machines?

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

• Оптимизации и проверки времени компиляции не могут быть сделаны. Например, Boost. Statechart определяетнаиболее распространенный контекстсостояния перехода и назначения во время компиляции. Кроме того, проверка времени компиляции гарантирует, что машина состояния является действительной (например, что нет переходов между ортогональными состояниями).
• Двойная отправка неизбежно должна осуществляться с помощью какой-то таблицы. Как утверждается вДвойной диспетчерской, это масштабируется плохо.
• Чтобы обеспечить быстрый поиск стола, состояния и события должны быть представлены целым числом. Чтобы таблица была как можно меньше, нумерация должна быть непрерывной, например, если есть десять состояний, лучше всего использовать идентификаторы 0-9. Для обеспечения непрерывности идентификаторов все состояния лучше всего определять в одном и том же файле заголовка. То же самое касается и событий. Опять же, это не масштабируется.
• Поскольку события, несущие параметры, не представлены типом, необходимо использовать некоторое общее событие с картой свойств, и безопасность типа обеспечивается во время выполнения, а не во время компиляции.

Именно по этим причинам, это и есть. Statechart был построен с нуля до не поддержки динамической конфигурации. Однако это не означает, что невозможно динамически формировать машину, реализованную с этой библиотекой. Например, охранники могут быть использованы для осуществления различных переходов в зависимости от входных данных только в рабочее время. Однако такие изменения макета всегда будут ограничиваться тем, что можно предвидеть до компиляции. Несколько связанная библиотека, платформа для бустера::spirit parser, позволяет примерно такую же настройку времени выполнения.

Error handling

Нет ни одного слова об обработке ошибок в спецификациях семантики машины состояния UML. Более того, большинство существующих FSM-решений также, похоже, игнорируют эту проблему.  

Why an FSM library should support error handling

Рассмотрим следующую конфигурацию состояния:

Оба состояния определяют действия ввода (x() и y()). Всякий раз, когда состояние A становится активным, вызов x() будет немедленно сопровождаться вызовом y(). y() может зависеть от побочных эффектов x(). Таким образом, выполнение y() не имеет смысла, если x() терпит неудачу. Это не эзотерический угловой случай, но происходит каждый день в государственных машинах все время. Например, x() может приобрести память, содержимое которой позже изменено y(). Существует иная, но с точки зрения обработки ошибок одинаково критическая ситуация в Тюториальной области под Установить государственную информацию из машины, когда Running::~Running() имеет доступ к внешнему состоянию Active. Если бы действие входа Active потерпело неудачу и Running было введено в любом случае, то Running действия выхода ссылались бы на неопределенное поведение. Ситуация обработки ошибок с внешними и внутренними состояниями напоминает ту, которая имеет базовые и производные классы: Если конструктор базового класса терпит неудачу (заявив исключение), строительство прерывается, производный конструктор класса не называется и объект никогда не приходит к жизни.
В большинстве традиционных фреймворков FSM такая ситуация с ошибками относительно проста в решении , если ошибка может быть распространена на клиента государственной машины. В этом случае неудачное действие просто распространяет исключение C++ в рамки. Рамки обычно не захватывают исключение, чтобы клиент государственной машины мог справиться с ним. Обратите внимание, что после этого клиент больше не может использовать объект государственной машины, потому что он находится либо в неизвестном состоянии, либо каркас уже сбросил состояние из-за исключения (например, с защитником сферы охвата). То есть, по своей природе, государственные машины обычно предлагают только основную безопасность исключения.
Тем не менее, обработка ошибок с традиционными фреймворками FSM становится удивительно громоздкой, как только многие действия могут потерпеть неудачу, а государственная машина сама должна изящно справляться с этими ошибками. Обычно, неудачное действие (например, x()) затем публикует соответствующее событие ошибки и устанавливает глобальную переменную ошибок к истине. Каждое последующее действие (например, y()) сначала должно проверить переменную ошибки, прежде чем делать что-либо. После того, как все действия завершены (не делая ничего!), ранее опубликованное событие ошибки должно быть обработано, что приводит к исполнению действия средства правовой защиты. Пожалуйста, обратите внимание, что недостаточно просто очертить событие ошибки, поскольку другие события все еще могут быть отложены. Вместо этого событие ошибки имеет абсолютный приоритет и должно быть рассмотрено немедленно. Есть несколько менее громоздкие подходы к обработке ошибок FSM, но они обычно требуют изменения схемы государственного устройства и, таким образом, затеняют нормальное поведение. Независимо от того, какой подход используется, программисты обычно вынуждены писать много кода, который имеет дело с ошибками, и большая часть этого кода не посвящена обработке ошибок, но распространению ошибок.

Error handling support in Boost.Statechart

Исключения C++ могут распространяться из любого действия, чтобы сигнализировать о провале. В зависимости от того, как настраивается государственная машина, такое исключение немедленно распространяется на клиента государственной машины или вылавливается и превращается в специальное событие, которое отправляется немедленно. Более подробную информацию см. в главе Исполнение в учебнике.

Two stage exit

Действие выхода может быть реализовано путем добавления деструктора в состояние. Из-за природы деструкторов есть два недостатка в этом подходе:

• Поскольку деструкторы C++ практически никогда не должны бросать, нельзя просто распространять исключение из действия выхода, как это происходит, когда одно из других действий не удается.
• Когда объектstate_machine<>разрушается, то неизбежно разрушаются и все текущие активные состояния. То есть терминация государственной машины связана с уничтожением государственного машинного объекта.

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

• Действия выхода часто не могут потерпеть неудачу. Если они могут, то такая неудача обычно либо
  • не представляет интереса для внешнего мира, т.е. неудача может быть просто проигнорирована.
  • Это настолько серьезно, что заявка должна быть прекращена в любом случае. В такой ситуации раскручивание стопки почти никогда не желательно, и сбой лучше сигнализируется через другие механизмы (например, аборт).
• Для правильной очистки часто действия выходадолжны выполняться при разрушении объекта государственной машины, даже если он разрушается в результате размотки стопки.

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

struct make_choice : sc::event< make_choice > {};
// universal choice point base class template
template< class MostDerived, class Context >
struct choice_point : sc::state< MostDerived, Context >
{
  typedef sc::state< MostDerived, Context > base_type;
  typedef typename base_type::my_context my_context;
  typedef choice_point my_base;
  choice_point( my_context ctx ) : base_type( ctx )
  {
    this->post_event( boost::intrusive_ptr< make_choice >(
      new make_choice() ) );
  }
};
// ...
struct MyChoicePoint;
struct Machine : sc::state_machine< Machine, MyChoicePoint > {};
struct Dest1 : sc::simple_state< Dest1, Machine > {};
struct Dest2 : sc::simple_state< Dest2, Machine > {};
struct Dest3 : sc::simple_state< Dest3, Machine > {};
struct MyChoicePoint : choice_point< MyChoicePoint, Machine >
{
  MyChoicePoint( my_context ctx ) : my_base( ctx ) {}
  sc::result react( const make_choice & )
  {
    if ( /* ... */ )
    {
      return transit< Dest1 >();
    }
    else if ( /* ... */ )
    {
      return transit< Dest2 >();
    }
    else
    {
      return transit< Dest3 >();
    }
  }
};