Переход можно определить, используя eUML как:

source + event [guard] / action == target

или как

target == source + event [guard] / action

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

Простая таблица переходов, написанная с помощью интерфейса functor , теперь может быть написана следующим образом:

BOOST_MSM_EUML_TRANSITION_TABLE(( 
Stopped + play [some_guard] / (some_action , start_playback)  == Playing ,
Stopped + open_close/ open_drawer                             == Open    ,
Stopped + stop                                                == Stopped ,
Open    + open_close / close_drawer                           == Empty   ,
Empty   + open_close / open_drawer                            == Open    ,
Empty   + cd_detected [good_disk_format] / store_cd_info      == Stopped
),transition_table)                       

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

BOOST_MSM_EUML_TRANSITION_TABLE(( 
Playing  == Stopped + play [some_guard] / (some_action , start_playback) ,
Open     == Stopped + open_close/ open_drawer                            ,
Stopped  == Stopped + stop                                               ,
Empty    == Open    + open_close / close_drawer                          ,
Open     == Empty   + open_close / open_drawer                           ,
Stopped  == Empty   + cd_detected [good_disk_format] / store_cd_info
),transition_table)           

Переходная таблица теперь выглядит как список правил с небольшим шумом.

UML определяет защитные механизмы между “[ ]” и действиями после a“/”, поэтому выбранный синтаксис уже более удобочитаем для дизайнеров UML. UML также позволяет дизайнерам определять несколько действий последовательно (наша предыдущая ActionSequence_), разделенных запятой. Первый переход делает именно это: два действия, разделенные запятой и заключенные в скобки, чтобы уважать приоритет оператора C++.

Если вам кажется, что это будет стоить вам производительности во время выполнения, не волнуйтесь, eUML основан на типе (или деклапте), который оценивает параметры только для BOOST_MSM_EUML_TRANSITION_TABLE, и не происходит затрат времени выполнения. Фактически, eUML представляет собой только слой метапрограммирования поверх «стандартного» метапрограммирования MSM, и этот первый слой генерирует ранее введенный functor front-end.

UML также позволяет дизайнерам определять более сложные защитные элементы, такие как [good_disk_format && (some_condition | | some_other_condition)]. Это было возможно с нашими ранее определенными функторами, но с использованием сложного синтаксиса шаблона. Этот синтаксис теперь возможен точно так же, как и записанный, что означает отсутствие синтаксического шума вообще.

В качестве введения в eUML мы перепишем таблицу перехода нашего учебника с использованием eUML. Для этого потребуется два-три изменения в зависимости от компилятора:

Теперь мы можем написать таблицу перехода, как только что показано, используя BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE Вместо BOOST_MSM_EUML_TRANSITION_TABLE. Реализация довольно проста. Единственным необходимым дополнением является необходимость объявить переменную для каждого состояния или добавить в таблицу переходов паренсы (звонок разработчика по умолчанию).

Реализация композит также является естественной:

// front-end like always
struct sub_front_end : public boost::msm::front::state_machine_def<sub_front_end>
{
...
};
// back-end like always
typedef boost::msm::back::state_machine<sub_front_end> sub_back_end;
sub_back_end const sub; // sub can be used in a transition table.

К сожалению, есть ошибка с VC, которая время от времени появляется и вызывает переполнение стека. Если вы получите предупреждение о том, что программа рекурсивна на всех путях, вернитесь к стандартному eUML или другому интерфейсу, поскольку Microsoft, похоже, не намерена его исправлять.

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

Вы можете повторно использовать метод определения состояния машины из стандартного интерфейса и просто заменить таблицу перехода на эту новую. Вы также можете использовать eUML для определения машины состояния «на лету» (если, например, вам нужно предоставить on_entry/on_exit для этой машины состояния в качестве функтора). Для этого существует также макрос BOOST_MSM_EUML_DECLARE_STATE_MACHINE, который имеет 2 аргумента, выражение, описывающее машину состояния и название машины состояния. Выражение имеет до 8 аргументов:

Например, машина минимального состояния может быть определена как:

BOOST_MSM_EUML_TRANSITION_TABLE(( 
),transition_table)                       

BOOST_MSM_EUML_DECLARE_STATE_MACHINE((transition_table,init_ << Empty ),
                                     player_)

Пожалуйста, взгляните на учебник игрока, написанный с использованием первого синтаксиса eUML и второго синтаксиса . Макро BOOST_MSM_EUML_DECLARE_ATTRIBUTE, к которому мы вскоре вернемся, объявляет атрибуты, данные типу eUML (состояние или событие), используя синтаксис атрибутов .

Определение подмашины (см. tutorial) с другими передними концами просто означает использование состояния, которое является машиной состояния в таблице перехода другой машины состояния. То же самое касается eUML. Нужно только определить вторую машину состояния и сослаться на нее в таблице перехода содержащей машины состояния.

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

BOOST_MSM_EUML_DECLARE_STATE_MACHINE(...,Playing_)
typedef msm::back::state_machine<Playing_> Playing_type;
Playing_type const Playing;

Теперь мы можем использовать этот экземпляр внутри таблицы перехода содержащейся машины состояний:

Paused == Playing + pause / pause_playback

Теперь мы хотим сделать нашу грамматику более полезной. Очень часто требуются только очень простые методы действия, например ++Counter или Counter > 5, где Counter обычно определяется как некоторый атрибут класса, содержащего машину состояния. Кажется пустой тратой писать функтор для такого простого действия. Кроме того, состояния внутри МСМ также являются классами, поэтому они могут иметь атрибуты, и мы также хотели бы предоставить им атрибуты.

Если вы посмотрите на наши примеры, используя синтаксисы first и second, вы найдете BOOST_MSM_EUML_DECLARE_ATTRIBUTE и макрос BOOST_MSM_EUML_ATTRIBUTES. Первый из них определяет возможные атрибуты:

BOOST_MSM_EUML_DECLARE_ATTRIBUTE(std::string,cd_name)
BOOST_MSM_EUML_DECLARE_ATTRIBUTE(DiskTypeEnum,cd_type)

Объявляют два атрибута: cd_name типа std::string и cd_type типа DiskTypeEnum. Эти атрибуты не являются частью какого-либо события или состояния в частности, мы просто объявили имя и тип. Теперь мы можем добавить атрибуты к нашему cd_обнаруженному событию, используя второй:

BOOST_MSM_EUML_ATTRIBUTES((attributes_ << cd_name << cd_type ), 
                          cd_detected_attributes)

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

BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES(cd_detected,cd_detected_attributes)

Для состояний мы используем макрос BOOST_MSM_EUML_STATE, который имеет форму выражения, где можно предоставить атрибуты. Например:

BOOST_MSM_EUML_STATE((no_action /*entry*/,no_action/*exit*/,
                      attributes_ << cd_detected_attributes),
                     some_state)

Хорошо, отлично, теперь у нас есть способ добавить атрибуты к классу, что мы могли бы сделать легче, так в чем смысл? Дело в том, что теперь мы можем ссылаться на эти атрибуты непосредственно, во время компиляции, в таблице перехода. Например, в примере вы найдете этот переход:

Stopped==Empty+cd_detected[good_disk_format&&(event_(cd_type)==Int_<DISK_CD>())] 

Прочитайте event_(cd_type) как event_->cd_type с event_типом, общим для событий, каким бы ни было конкретное событие (в данном конкретном случае оно оказывается cd_обнаруженным, как показывает переход).

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

МСМ предоставляет более общие объекты для типов государственных машин:

Эти помощники могут использоваться двумя различными способами:

Вторая форма полезна, если вы хотите предоставить своим штатам свои собственные методы, которые вы также хотите использовать внутри таблицы перехода. В руководстве выше мы предоставляем Empty метод активации_empty. Мы хотели бы создать функтор eUML и назвать его изнутри таблицы переходов. Это делается с помощью макросов MSM_EUML_METHOD/MSM_EUML_FUNCTION. Первый создает функтор к методу, второй к свободной функции. В учебнике мы пишем:

MSM_EUML_METHOD(ActivateEmpty_,activate_empty,activate_empty_,void,void)

Первым параметром является название функтора, для использования с фронтендом функтора. Второе — название метода вызова. Третье - это название функции для использования с eUML, четвертое - тип возврата функции, если используется в контексте действия перехода, пятое - тип результата, если используется в контексте действия входа / выхода состояния (обычно четвертое и пятое - одно и то же). Теперь у нас есть новая функция eUML, называемая методом «что-то», и это «что-то» является одним из пяти ранее показанных общих помощников. Теперь мы можем использовать это в переходном периоде, например:

Empty == Open + open_close / (close_drawer,activate_empty_(target_))

Действие теперь определяется как последовательность из двух действий: close_drawer и activate_empty, которая вызывается на саму цель. Цель, являющаяся Пустой (состояние, определенное слева), на самом деле будет называться Пустой::activate_empty(). Этот метод также может иметь (или несколько) аргументов (аргументов), например событие, которое мы можем назвать активированным_пустым_(target_, event_).

Больше примеров можно найти в стресс-тесте компилятора terrible, примере timer или в iPodSearch с eUML (для String_ и более).

Определение ортогональных регионов действительно означает предоставление большего количества исходных состояний. Чтобы добавить больше начальных состояний, “ Shift left” некоторые, например, если бы у нас было другое начальное состояние под названием AllOk :

BOOST_MSM_EUML_DECLARE_STATE_MACHINE((transition_table,
                                     init_ << Empty << AllOk ),
                                    player_)

Вы помните из подписей BOOST_MSM_EUML_STATE и BOOST_MSM_EUML_DECLARE_STATE_MACHINE, что сразу после атрибутов мы можем определить флаги, как в базовом интерфейсе MSM. Для этого у нас есть еще одна грамматика «сдвиг-лево», например:

BOOST_MSM_EUML_STATE((no_action,no_action, attributes_ <<no_attributes_, 
                      /* flags */ configure_<< PlayingPaused << CDLoaded), 
                    Paused)

Теперь мы определили, что Paused получит два флага, PlayingPaused и CDLoaded, с другим макросом:

BOOST_MSM_EUML_FLAG(CDLoaded)

Это соответствует следующему базовому определению интерфейса Paused:

struct Paused : public msm::front::state<>
{ 
   typedef mpl::vector2<PlayingPaused,CDLoaded> flag_list; 
};

Под капотом вы получаете mpl::vector2.

Примечание : При использовании версии выражения BOOST_MSM_EUML_STATE с 4 аргументами мы должны сообщить eUML, что нам не нужны атрибуты. Аналогично cout << endl, нам нужен синтаксис attributes_ << no_attributes_.

Флаг можно использовать с помощью метода is_flag_active государственной машины. Вы также можете использовать предоставленную функцию помощника is_flag_ (возврат кипения) для состояний и переходов. Например, в i Реализация под с eUML, вы найдете следующий переход:

ForwardPressed == NoForward + EastPressed[!is_flag_(NoFastFwd)]

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

eUML также поддерживает определение отложенных событий в определении состояния (государственной машины). Для этого можно использовать грамматику флага. Например:

BOOST_MSM_EUML_STATE((Empty_Entry,Empty_Exit, attributes_ << no_attributes_,
                      /* deferred */ configure_<< play ),Empty) 

Сдвиг влево также отвечает за отсрочку событий. Сдвиг внутри конфигурируемого флага и государство получит флаг, сдвинет событие и получит отложенное событие. Это заменяет основное определение интерфейса:

typedef mpl::vector<play> deferred_events;

В этом руководстве игрок определяет вторую ортогональную область с AllOk в качестве начального состояния. Состояния Empty и Open также откладывают событие play. Open, Stopped и Pause также поддерживают флаг CDLoaded Используя тот же левый сдвиг в configure_.

В передней части функтора у нас также была возможность отложить событие внутри перехода, что делает возможным условное отсрочку. Это также возможно с помощью eUML посредством использования порядка defer_, как показано в этом руководстве . Вы найдете следующий переход:

Open + play / defer_

Это внутренний переход. Игнорируйте это на данный момент. Интересно, что когда событие play будет запущено и Open будет активным, событие будет отложено. Теперь добавьте стражу и вы можете условно отложить мероприятие, например:

Open + play [ some_condition ] / defer_

Это похоже на то, что мы сделали с фронт-эндом. Это означает, что у нас одинаковые ограничения. Используя defer_ вместо государственной декларации, мы должны сообщить МСМ, что мы отложили события в этой государственной машине. Мы делаем это (опять же) с помощью заявления configure_ в определении машины состояния, в котором мы смещаем флаг конфигурации deferred_events:

BOOST_MSM_EUML_DECLARE_STATE_MACHINE((transition_table,
                                      init_ << Empty << AllOk,
                                      Entry_Action, 
                                      Exit_Action, 
                                      attributes_ << no_attributes_,
                                      configure_<< deferred_events ),
                                    player_)

tutorial иллюстрирует эту возможность.

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

Деактивация первых двух функций, а не активация третьей, если в этом нет необходимости, значительно повышает скорость передачи событий. Наш пример тестирования скорости с eUML делает это для лучшей производительности.

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

Анонимные переходы (См. UML учебник ) представляют собой переходы без именованного события, которые, следовательно, запускаются сразу же, когда состояние источника становится активным, при условии, что это позволяет защита. Поскольку нет события, чтобы определить такой переход, просто опустить “ +” часть перехода (событие), например:

State3 == State4 [always_true] / State3ToState4
State4 [always_true] / State3ToState4 == State3

Пожалуйста, посмотрите на этот пример , который реализует , ранее определенный .

Как и оба других интерфейса, eUML поддерживает два способа определения внутренних переходов:

Что касается фронт-энда функтора, то eUML поддерживает концепцию события любой , но бустер::любой не является приемлемым терминалом eUML. Если вам нужно событие any, используйте msm::front::euml::kleene, которое наследует импульс::any. Такой же переход, как и с повышением: любой будет:

State1 + kleene == State2

Мы увидели функцию build_state, которая создает простое состояние. Кроме того, eUML предоставляет другие макросы государственного строительства для других типов государств:

Для использования этих состояний в таблице перехода eUML предлагает функции explicit_, exit_pt_ и entry_pt_. Например, прямой вход в субгосударственное подгосударство2 из SubFsm2 может быть:

explicit_(SubFsm2,SubState2) == State1 + event2

Вилки, являющиеся списком прямых записей, eUML поддерживает логический синтаксис (state1, state2, ...), например:

(explicit_(SubFsm2,SubState2), 
 explicit_(SubFsm2,SubState2b),
 explicit_(SubFsm2,SubState2c)) == State1 + event3 

Точка входа вводится с использованием того же синтаксиса, что и явные записи:

entry_pt_(SubFsm2,PseudoEntry1) == State1 + event4

Для точек выхода снова используется тот же синтаксис, за исключением того, что точки выхода используются в качестве источника перехода:

State2 == exit_pt_(SubFsm2,PseudoExit1) + event6 

Учебник Entry также доступен с eUML.

Мы видели несколько помощников, но их было больше, поэтому давайте дадим более полное описание:

Это может быть довольно весело. Например,

/( if_then_else_(--fsm_(m_SongIndex) > Int_<0>(),/*if clause*/
                 show_playing_song, /*then clause*/
                 (fsm_(m_SongIndex)=Int_<1>(),process_(EndPlay))/*else clause*/
                 ) 
  )

(fsm.SongIndex > 0, call show_playing_song else) SongIndex=1; процесс EndPlay на fsm;}

Несколько примеров используют эти функции:

К сожалению, есть небольшой улов. Определение функтора с помощью MSM_EUML_METHOD или MSM_EUML_FUNCTION создает правильный функтор. Ваши собственные функторы eUML, написанные в начале этого раздела, также будут работать хорошо, , за исключением , на данный момент, с функциями while_, if_then_, if_then_else_.

eUML поддерживает большинство операторов C++ (кроме адреса). Например, можно написать event_(some_attribute)++ или [source_(some_bool) && fsm_(some_other_bool)]. Но программисту нужно больше, чем операторам в его ежедневном программировании. Очевидно, что STL должен иметь. Поэтому eUML поставляется с большим количеством функторов, чтобы еще больше уменьшить потребность в собственных функторах для таблицы перехода. Практически для каждого алгоритма или метода контейнера STL определяется соответствующая функция eUML. Как и Boost.Phoenix, “.” And “->” объектов вызова заменяются парадигмой функционального программирования, например:

В двух словах, почти каждый метод или алгоритм STL соответствует соответствующему функтору, который затем может быть использован в таблице переходов или действиях состояния. В ссылке перечислены все функции eUML и лежащий в их основе функтор (так что эта возможность зарезервирована не только для eUML, но и для интерфейса на основе функтора). Файловая структура этой библиотеки, похожей на Феникс, соответствует структуре Boost. Феникс. Все функторы для алгоритмов STL можно найти в:

#include <msm/front/euml/algorithm.hpp>

Алгоритмы также разделены на подзаголовки, соответствующие структуре Феникса для простоты:

#include < msm/front/euml/iteration.hpp> 
#include < msm/front/euml/transformation.hpp>
#include < msm/front/euml/querying.hpp> 

Методы контейнеров можно найти в:

#include < msm/front/euml/container.hpp>

Или можно просто включить всю поддержку STL (вам также нужно будет включить euml.hpp):

#include < msm/front/euml/stl.hpp>

Несколько примеров (чтобы найти в это руководство):

Также можно писать действия, охранники, действия входа и выхода государства с помощью уменьшенного набора Boost. Возможности Феникса. Эта функция все еще находится в стадии разработки, поэтому вы можете получить здесь и там некоторый сюрприз. Однако простые случаи должны работать хорошо. Что не сработает, так это смешение функторов eUML и Phoenix. Написание охранников на одном языке и действий на другом - это нормально.

Phoenix также поддерживает больший синтаксис, чем когда-либо будет возможно с eUML, поэтому вы можете использовать только уменьшенный набор грамматики Феникса. Это связано с характером EUML. Определение таблицы переходов времени выполнения переводится на тип с использованием Boost. Типа того. В результате получается «нормальная» переходная таблица МСМ, выполненная из функторов. Поскольку C++ не позволяет смешивать конструкцию времени выполнения и времени компиляции, будет некоторый предел (попытка инстанцировать класс шаблонов MyTemplateClass где i - int даст вам идею). Это означает, что следующие действующие конструкции Феникса не будут работать:

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

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

Поддержка Phoenix по умолчанию не активируется. Чтобы активировать его, добавьте перед любым заголовком MSM: #define BOOST_MSM_EUML_PHOENIX_SUPPORT.

Простой пример показывает некоторые основные возможности.