Documentation

Your first stop is at the front desk of the hotel.

At the chart level, the default transition to Check_in occurs, making that state active. Then, the default transition to Front_desk occurs, making that state active.

For reference, see Enter a Chart or State.

You leave the front desk after checking in to the hotel.

The check_in event guards the outgoing transition from Front_desk. When the chart receives an event broadcast for check_in, the transition becomes valid.

For reference, see How Stateflow Charts Respond to Events.

Just before you leave the front desk, you pick up your bags to move to your room.

Just before the transition occurs, the exit action of Front_desk sets the move_bags local data to 1. Then, Front_desk becomes inactive.

For reference, see Exit a State.

Use exclusive (OR) decomposition when no two states at a level of the hierarchy can be active at the same time.

This guideline ensures proper chart execution. For example, Check_in and Waiting_area are exclusive (OR) states, because you cannot be inside and outside the hotel at the same time.

Use a default transition to mark the first state to become active among exclusive (OR) states.

This guideline prevents state inconsistency errors during chart execution.

Use events, instead of conditions, to guard transitions that depend on occurrences without inherent numerical value.

Since you cannot easily quantify the numerical value of checking into a hotel, model such an occurrence as an event.

Use an exit action to execute a statement once, just before a state becomes inactive.

Other types of state actions execute differently and do not apply:

You can move to one of three types of rooms.

After the check_in event triggers a transition out of Front_desk, three transition paths are available based on the type of room you select with the Multiport Switch block. Transition testing occurs based on the priority you assign to each path.

For reference, see Order of Execution for a Set of Flow Charts.

If you choose an executive suite, the base fee is 1500.

If the room_type input data equals 1, the top transition is valid. If this condition is true, the condition action executes by setting the fee output data to 1500.

If you choose a family suite, the base fee is 1000.

If room_type equals 2, the middle transition is valid. If this condition is true, the condition action executes by setting fee to 1000.

If you choose a single room, the base fee is 500.

If room_type equals 3, the bottom transition is valid. If this condition is true, the condition action executes by setting fee to 500.

Use conditions, instead of events, to guard transitions that depend on occurrences with numerical value.

Because you can quantify a type of hotel room numerically, express the choice of room type as a condition.

Flow Charts in Stateflow

Use condition actions instead of transition actions whenever possible.

Condition actions execute as soon as the condition evaluates to true. Transition actions do not execute until after the transition path is complete, to a terminating junction or a state.

Unless an execution delay is necessary, use condition actions instead of transition actions.

Transition Action Types

Use explicit ordering to control the testing order of a group of outgoing transitions.

You can specify explicit or implicit ordering of transitions. By default, a chart uses explicit ordering. If you switch to implicit ordering, the transition testing order can change when graphical objects move.

Transition Evaluation Order

After reaching your desired room, you finish moving your bags.

The entry action executes by setting the move_bags local data to 0.

If you order room service, your hotel bill increases by a constant amount.

If the chart receives an event broadcast for room_service, these actions occur:

For reference, see How Stateflow Charts Respond to Events.

Use an entry action to execute a statement once, right after a state becomes active.

Other types of state actions execute differently and do not apply:

Use an On event_name or On message_name action to execute a statement only after receiving an event broadcast or a message.

Use a superstate to enclose multiple substates that share the same state actions.

This guideline enables reuse of state actions that apply to multiple substates. You write the state actions only once, instead of writing them separately in each substate.

Based on your room type and the total number of room service requests, you can track your hotel bill.

expenses is a MATLAB^® function that takes the total number of room service requests as an input and returns the current hotel bill as an output.

If you double-click the function box, you see this script in the function editor:

function y = expenses(x)

if (room_type == 1)
   y = 1500 + (x*50);
else
   if (room_type == 2)
      y = 1000 + (x*25);
   else
      y = 500 + (x*5);
   end
end

Use MATLAB functions for performing numerical computations in a chart.

MATLAB functions are better at handling numerical computations than graphical functions, truth tables, or Simulink^® functions.

Use descriptive names in function signatures.

Descriptive function names enhance readability of chart objects.

When you reach the executive suite, you enter the bedroom first.

When the condition room_type == 1 is true, the condition action fee = 1500 executes. Completion of that transition path triggers these state initialization actions:

For reference, see Enter a Chart or State.

When you order room service, you enter the dining area to eat.

When the room_service event occurs, the transition from Bedroom to Dining_area occurs.

When you want the food removed from the dining area, you order room service again and then return to the bedroom.

When the room_service event occurs, the transition from Dining_area to Bedroom occurs.

If you leave the executive suite because of a fire alarm, you return to your previous room after the all-clear signal.

If a transition out of Executive_suite occurs, the history junction records the last active substate, Bedroom or Dining_area. For details on how this transition can occur, see Phase: Events Guard Transitions Between States.

Use exclusive (OR) decomposition when no two states at that level of the hierarchy can be active at the same time.

This guideline ensures proper chart execution. For example, Bedroom and Dining_area are exclusive (OR) states, because you cannot be in both places at the same time.

If reentry to a state with exclusive (OR) decomposition depends on the previously active substate, use a history junction. This type of junction records the active substate when the chart exits the state.

If you do not record the previously active substate, the default transition occurs and the wrong substate can become active upon state reentry.

For example, if you were eating when a fire alarm sounded, you would return to the bedroom instead of the dining room.

When your family reaches the suite, family members can be in both bedrooms (for example, parents in the master bedroom and children in the second bedroom). A default room choice does not apply.

When the condition room_type == 2 is true, the condition action fee = 1000 executes. Completion of that transition path triggers these state initialization actions:

For reference, see Enter a Chart or State.

You can occupy both rooms at the same time.

Master_bedroom and Second_bedroom remain active at the same time.

Use parallel (AND) decomposition when all states at that level of the hierarchy can be active at the same time.

This guideline ensures proper chart execution. For example, Master_bedroom and Second_bedroom are parallel states, because you can occupy both rooms at the same time.

Use no history junctions in states with parallel (AND) decomposition.

This guideline prevents parsing errors. Since all parallel states at a level of hierarchy are active at the same time, history junctions have no meaning.

Use explicit ordering to control the execution order of parallel (AND) states.

You can specify explicit or implicit ordering of parallel states. By default, a chart uses explicit ordering. If you switch to implicit ordering, the execution order can change when parallel states move.

If a fire alarm sounds, you leave the hotel and move to a waiting area outside.

When the chart receives an event broadcast for fire_alarm, a transition occurs from a substate of Check_in to Waiting_area.

 How does this transition occur?

If an all-clear signal occurs, you can leave the waiting area and return to your previous location inside the hotel.

When the chart receives an event broadcast for all_clear, a transition from Waiting_area to the previously active substate of Check_in occurs.

The history junction at each level of hierarchy in Check_in enables the chart to remember which substate was previously active before the transition to Waiting_area occurred.

 How does this transition occur?

Use events, instead of conditions, to guard transitions that depend on occurrences without numerical value.

Because you cannot easily quantify the numerical value of a fire alarm or an all-clear signal, model such an occurrence as an event.