1 A Macho Hello World A Macho Hello World The context class The - PDF document

A Macho Hello World The TOPSTATE has the same role as the top context class operational C++ Mach ine O bjects (MACHO) idle stop disabled H* tick[timer_exp] minute close programmed cooking start minute open Macho A Macho Hello World The BOX struct The Machine Objects class library allows the top wraps local variables creation of state machines based on the "State" and local (utility) functions design pattern in C++. operational idle It extends the pattern with the option to create stop hierarchical state machines , entry and exit disabled H* tick[timer_exp] minute actions, state histories and state variables. close programmed cooking Freely available at start minute http://ehiti.de/machine_objects/ open A Macho Hello World A Macho Hello World All state classes top top (including context) must use this macro to be identified as a state. operational operational idle idle stop stop disabled disabled H* H* tick[timer_exp] tick[timer_exp] minute minute close close programmed programmed cooking cooking ready start start minute minute open open 1

A Macho Hello World A Macho Hello World The context class The class methods declares all events top define the actions top handlers and the state transitions (here to a history state) operational operational idle idle stop stop disabled disabled H* H* tick[timer_exp] tick[timer_exp] minute minute close close programmed programmed cooking cooking start start minute minute open open A Macho Hello World A Macho Hello World Init action defining The class methods top top the initial actions. define the actions (including init, entry, It is optional !?! exit) and the state transitions (here to a operational operational regular state) idle idle stop stop disabled disabled H* H* tick[timer_exp] tick[timer_exp] minute minute close close programmed programmed cooking cooking start start minute minute open open A Macho Hello World What is needed Each state is a The class library as such does not need to be installed. Just top substate of the include the header file Macho.hpp and add the file Macho.cpp context (TOP) or to your make file or project definition. some other state Prerequisite is a C++ compiler with support for templates. operational idle stop disabled H* tick[timer_exp] minute close programmed cooking start minute open 2

Representing states Representing hierarchy • The starting point is the "State" design pattern. • The solution is to use explicit methods for state entry and • The essence of the pattern is to represent states by exit, being called in the correct sequence on state transitions. classes. State transitions are performed by instantiating – The framework takes care of calling them in the right order objects of these classes. • State variables are kept in separate state specific data • In contrast to the pattern discussed in the previous structures which have a life cycle consistent with the lesson, where all state classes are instantiatied statically hierarchy of states. as part of the context class. p • From this perspective the constructors and destructors of state classes can take the role of entry and exit actions. • Object attributes represent state variables. • Events are dispatched by calling methods on state objects which implement the guards, actions and transitions of states. Representing hierarchy State Definition • Macho machines are embedded within a single Top • Substates must be able to take over the event handling state logic of superstates, redefining it where necessary. There • The top state's interface defines the machine's event exists a mechanism in C++ allowing redefinition of protocol: only the public virtual methods of the top state behaviour on the level of methods: polymorphism through can be event handlers. class inheritance. • The top state is defined by the macro TOPSTATE • The top state has a typedef alias TOP that is available to all states of the machine. • All states are in reality substates (of top state or some other states)! Representing hierarchy State Definition • Regular states and superstates are defined using the • However, modeling the substate/superstate relation with SUBSTATE macro class inheritance is problematic: – the use of constructors and destructors as entry and exit actions is not possible anymore, – neither is keeping state variables in objects. • The macro parameters are the substate's name and the The macro parameters are the substate s name and the • • The reason is that base classes are constituent parts of The reason is that base classes are constituent parts of name of its superstate. deriving classes, meaning object construction or destruction • A typedef alias SUPER will point to the superstate within will trigger all involved class constructors or destructors and initialize or destroy all data members. the substate class. • This may be against the semantics of entry/exit actions and state variables, where a transition between sibling substates should not trigger superstate entry/exit actions nor destroy superstate state variables. 3

Machine creation State Variables • A state machine is created by Instantiating a machine • State variables store information maintained in the scope of the object associated state and accessible to any of its substates. • Top state variables are accessible to all states of a machine. • Machine is a template class in the MACHO namespace. Its template parameter is the top state of the machine. p p p • The top state is immediately entered and initialized upon machine creation • State variables are contained in a data type named Box (the name Box is mandatory ) nested into the state class. • The box definition must be before the use of the STATE macro. • The box type must be default constructable (has a default constructor). – Apart from this the box type can be any C++ type. (even a typedef) State Definition States with persistent data • The macro STATE(state_name) must be invoked in • A box is created before its state is entered (before the call to entry) and by default destroyed after the state is left (after the every state body: call to exit). By marking a state class with the PERSISTENT macro, you can override this default behaviour and have boxes survive state transitions: • Persistent boxes are created once at first entry of their state and exist for as long as the state machine instance itself exists. • The macro parameter is the state name. The purpose of the macro is to automatically generate a few definitions (a constructor for instance). • Every state class must be instantiable (including the top state). This means states must not have pure virtual methods! Macro internals Accessing the state data • Macros TOPSTATE, SUBSTATE, STATE • A state's box is accessed by calling the method box, which returns a reference to the state's box object: • Superstate boxes are available by qualifying the box method with the superstate's name: 4

Entry, exit, init Entry, exit, init: use Sequence of calls: entry:en1 entry ex4(); exit: ex1 exit: ex3(); init init: in1 ex2(); in3() { entry entry: en2 ex1(); … exit: ex2 exit (*) setState<S24>(); init init en1(); en1(); } } en2(); entry: en3 entry: en3(); exit exit: ex3 in3(); init: in3 init entry: en4 entry: en4(); exit: ex4 exit in4(); init: in4 init Init is only called at the end of the chain, for the destination … setState<S23>(); state … But init can also initiate a state transition to a substate (entry and exit cannot!), triggering another entry and another init. Entry, exit, init Transitions (event handlers) Sequence of calls: All of them are entry entry:en1 ex4(); With a handled by exit: ex1 exit: ex3(); setState<>() programming an init init: in1 ex2(); event handler in3() { entry entry: en2 ex1(); … exit: ex2 exit (*) setState<S24>(); init init en1(); en1(); } en2(); entry: en3 entry: Simple event en3(); exit exit: ex3 Without a handler in3(); init: in3 init setState entry: entry: en4 en4(); on event: action exit exit: ex4 in4(); init: in4 init (*) Macho transitions don’t have actions! … Handlers refer setState<S23>(); Not easy to while: action You must program guards and actions by hand to individual … program Warning, there is practically no means of having the events! action between exit and entry Entry, exit, init: calling order Internal and external transition Sequence of calls: ex4(); ex3(); entry entry:en1 exit: ex1 exit: ex2(); S1 S1 init init: in1 ex1(); (*) entry entry: en2 en1(); exit exit: ex2 en2(); init init en3(); 3() in3(); void onEvent() entry: en3 entry: void onEvent() exit en4(); { exit: ex3 { init: in3 init in4(); … entry: en4 entry: … action(); exit exit: ex4 action(); … The methods entry and exit of a state are called upon transitioning into or out of it. init: in4 init setState<S1>(); } … • First the exit action of the current state is called and then those of its superstates (in bottom up order), } • Then entry actions of superstates of the new state are called, top down from the first superstate that is not also a superstate of the previous state. 5