Up to this point, we have modeled use cases, input events and output
events. We have assumed the simplest control logic exits in which there is one input event
leading to one output event in a system. The question is "What are the if..then rules
for input and output events?" For each input event what are the if..then rules to
determine what is the output event. A primary way to model complex behavior with if..then
rules is with states and transitions. This is depicted in the figure below.
Figure Stimulus response behavior defines states
and transitions.
In the soda machine example, the system has stimulus response behavior
that can be modeled with states and transitions. The states of a soda vending machine
might be "off state", "ready to dispense soda state", and the "no
soda state". The "soda selection made input event" has a different output
event based upon the state of the system. The output event for the "soda selection
made input event" in the "no soda state" is a "user notified of no
sodas output event". The output event to this input event in the "ready to
dispense soda state" is the "soda dispensed output event".
Many systems and objects of classes have very simple control in which
each input event always results in the same output event. There are no states or modes of
control. A motor with an "on button" and an "off button" is an example
of a single mode system without states. The "on button pressed input event"
always result in the "motor turned on output event". The "off button
pressed input event" always results in the "motor turned off output event".
However, systems and objects may have states which are modes of control.
An input event may result in different output events depending upon the current state of
the system or object. An input event may result in a transition to a new state. A system
or object with states and transitions is called a Finite State Machine. A simple
example of a finite state machine is a motor with a toggle switch. The "toggle input
event" has different output events depending whether theToggleSwitch is in the
OnState or in the OffState. In the OnState the output event to the "toggle input
event" is "motor turned off". In the OffState the output input event to the
"toggle input event" is "motor turned on".
Frequently objects of classes that can be modeled as finite state
machines are called controller objects. A controller object has the control logic to
select the proper action for each input event depending upon its current state. A
controller object in the motor with a toggle switch has the control logic to select the
proper action to turn on the motor or to turn off the motor.
Figure System with States and Transitions
In modeling stimulus response behavior with states and transitions, we
will progress as shown below:
Step 1 - At the system level, model the state based stimulus response
behavior in terms of system use cases, input events, and output events.
Step 2 - At the system level, model states and transitions for the
system as a whole in the System Dynamic Model.
Step 3 - At the class level, model states and transitions for each class
that has state based behavior in the Dynamic Model.
In this section we will construct the following documentation products
to describe the stimulus response behavior of a system as shown below. In this section we
will progress from the System Dynamic Model to the Dynamic Model.
System Dynamic Model Dynamic Model
Figure Documentation Products to Model Stimulus Response Behavior
Before we model state based stimulus response behavior, it is important
to model the system stimulus response behavior in terms of use cases, input events, and
output events. It is useful to review the various documentation in the System Object Model
and System Dynamic Model, especially the system requirements statement, system use case
diagram, system use case descriptions, system diagram (OMT Notation), and system
interaction diagram. We must understand the system boundary, the system use cases, and the
system events. From the drawing below, we see the use case "use car" with the
input events start, operate, and stop. For this drawing, we ask the question "For
these input and output events, what are the states (modes of behavior) of the system as a
whole"?
Figure Car Simulation System with System States
The system diagram (OMT Notation) shows the system operations that are
invoked by an input event. The system interaction diagram shows the input and output
events. In reviewing this information we ask the question again "For these input and
output events, what are the states (modes of behavior) of the system as a whole"? The
system diagram (OMT Notation) and the system interaction diagram for the Car Simulation
System are shown below.
System Diagram (OMT Notation) System Interaction Diagram
Figure System Diagram and System Interaction Diagram for Car Simulation System
The state diagram shows complex stimulus response behavior for a system or objects of a class. It is a directed graph whose nodes are states and whose directed arcs are transitions. The directed arc shows the event that triggers the transition with the applicable condition and actions. The purpose of the state diagram (state transition diagram) is to specify stimulus response logic for a system or class of objects. It specifies the pattern of states, events, conditions, and actions. The state transition table shows states, events, conditions, and actions in a table form.
The various elements of the state diagram are described below.
State Diagram State Transition Table
Figure State Diagram and State Transition Table
- An event is an occurrence at a point in time that is a stimulus
for a system or an object. The events for a car object are "start event",
"operate event", and "stop event". An event may be represented as an
event object, such as "theStartEvent" or as a message signifying that the event
has occurred such as "start ()". As an object identity the attributes of the
event object. As a message identify any parameters that are passed in the event
message. An event may be a system event that is passed to the system being modeled, such
as "start". Alternatively an event may be an internal event that is sent from an
object in the system, such as "Abnormal Status".
- A condition is a logical value (true or false) that is valid
over a period of time that affects transitions from one state to another. A condition
is a guard or Boolean expression signifying OK or NOTOK that are used in IF Condition =
True THEN DoSomeAction. Examples of conditions in a Temperature Class might be
"temperature high" and "temperature OK". The conditions for a car
object are "GasOK" and "NoGas".
- An action is an operation such as startMotor () in response to
an event. Actions include updating an attribute, sending a message, creating or destroying
an object, or similar action. The actions for a car object are "theMotor.start
()", "theMotor.operate ()", and "theMotor.stop()". An action may
be instantaneous such as "theMotor.stop()" or may be continuous activity, such
as "monitor car status". A continuous activity is indicated on a state diagram
with "do:", such as "do:monitorCarStatus". An action may lead to a
system output event that is passed from the system, such as "car started".
Alternatively an action may be an internal response to an internal event, such as
"Correct abnormal status" response to the internal event "Status
abnormal".
- A state represents a mode of control that has a unique
combination of events, conditions, actions, and next state. A state is static, i.e.
waiting for an event to occur. While in a state, a defined set of rules, laws, and
policies apply. A state is like a manager or coordinator that knows how to respond to each
event according to his rules, laws, and procedures. There is an initial state that
is entered when the object is created. There is a termination state that is entered
prior to the object being destroyed. The states for a car object are "OffState"
and "OperatingState". States may be shown in a generalization specialization
hierarchy in which generalization states (superclasses) define the most general, common
behavior and specialization states (subclasses) define specialized behavior for an object
in the specialization state.
- A transition is a unique pattern of a current state, event, conditions, actions, and a destination state. For each state identify applicable events. Then for each event identify the applicable conditions, actions, and the destination state.
The basic steps to create the state diagram are:
Step 1 - Identify a system or a class, e.g. Car Simulation System or Car
Class that has states, e.g. modes of behavior.
Step 2 - Identify the states, e.g. OffState or OperatingState. A state
represents a mode of behavior that has a unique combination of an event, conditions,
actions, and next state. A state is static, i.e. waiting for an event to arrive. While in
a state, a defined set of rules, laws, and policies apply. A state is like a manager or
coordinator that knows how to respond to each event according to his rules, laws, and
procedures. Identify the initial state that is entered upon creation. Identify the
termination (final) state that is entered immediately prior to exit.
Step 3 - Identity any activities (operations) that commence when the
state is entered. Activities include sequential operations that terminate after a period
of time, after completion of a calculation or upon receipt of an event. Activities include
continuous operations that terminate when the state is exited.
Step 4 - Identify the events, any stimuli to an object of a class e.g.
start () that results in some action and that may result in a transition to a new state.
An event may be modeled as an event object or as an event message. Identify any parameters
that are passed in the events.
Step 5 - Identify the actions, e.g. startMotor () in response to an
event. Actions include updating an attribute, sending a message, or similar action.
Step 6 - Identify the conditions that affect the stimulus response
logic. A condition is a guard or Boolean expression signifying OK or NOTOK that are used
in IF Condition = True THEN DoSomeAction. Examples of conditions in a Temperature Class
might be "temperature high" and "temperature OK".
Step 7 - Identify the transitions. A transition is a unique pattern of
an event, conditions, actions, and a destination state. For each state identify applicable
events. Then for each event identify the applicable conditions, actions, and the
destination state.
Step 8 - Walk-through the state diagram by sending each event to ensure
the correct transitions.
Step 9 - Prototype, test, and iterate.
The Car Simulation System could also be modeled as a finite state machine. The system has various states (modes of behavior). The input event operate invokes different actions depending whether the system is in the OffState or the OperatingState. In the OffState, the system shows a status and remains in the OffState. In the OperatingState, the system shows a status and either stays in the OperatingState or transitions to the OffState depending upon the value of the condition gasQuantity. The system state diagram for the Car Simulation System is shown below in the figure below.
Figure State Diagram for the Car Simulation
System.
The state diagram may be created with a CASE tool or Windows drawing
tool. The steps to create the state diagram using a CASE tool or Windows drawing tool are
listed below.
>> Create a directory, e.g. c:\md car
>> Run the CASE tool from Windows
>> Select "File - SaveAs" c:\car\carstate.omt
>> Select the State Icon (rounded rectangle)
>> Enter the State Name, e.g. OffState
>> Double Click OK
>> Select the State Icon (rounded rectangle)
>> Enter the State Name, e.g. OperatingState
>> Double Click OK
>> Select the Transition Icon (arrow)
>> Enter the Event, e.g. start ()
>> Enter the Action, e.g. start ()
>> Double Click OK
>> Connect two states together with the transition
>> Select "File - Save" to save the diagram
The state transition table shows the stimulus response behavior for a
system or objects of a class in a table form. It shows the following: states, events,
conditions, actions, and next state. The state transition table complements the state
diagram. When the state diagram has many states and transitions it becomes very cluttered
and difficult to read. At this point, it is useful to create the state transition table
that can describe highly complex systems with a large number of states and transitions.
The state transition table may be created with a CASE tool or text
editor. The steps to create the state diagram using a CASE tool are listed below.
>> Create a directory, e.g. c:\md car
>> Run the CASE tool from Windows
>> Select "File - Open" c:\car\carstate.omt to open the state diagram
>> Ensure that the state diagram is correct
>> Select "Generate Generate State Code/Report" and select the state transition script, e.g. TABSTATE.SCT
>> Select "File Edit File" to examine the generated state transition table
>> In the Windows word processor import the state transition table
into a table to format and sort.
The system state transition table for the Car Simulation System is shown
below.
State Transition Table
| State Name | Event Name | Transition Condition | Transition Action | Transition Next State |
| OffState | start() | gasQuantity > 0 | showStatus ("Car started") | OperatingState |
| OperatingState | operate() | gasQuantity > 0 | showStatus ("Car operating") | OperatingState |
| OperatingState | operate() | gasQuantity == 0 | showStatus ("Car not operating") | OffState |
| OperatingState | stop() | showStatus ("Car stopped") | TerminationState |
The script (TABSTATE.SCT) to generate this table is shown below.
Script to Generate the State Transition Table
SCRIPT_NOREPEAT_HEADER_BEGIN
State Name,Event Name,Transition Condition,Transition Action,Transition Next State SCRIPT_NOREPEAT_HEADER_END
[TRANSITION_CURRENT_STATE,TRANSITION_EVENT_WITH_PARAMETERS,TRANSITION_CONDITION,
TRANSITION_ACTION,TRANSITION_NEXT_STATE]
You may create the state transition table by running a CASE tool script.
To manually create this table, follow these steps:
Step 1. Create the state diagram first to identify events, conditions,
actions, and states.
Step 2. Create the blank state transition table with headings and blank
cells.
Step 3. Fill in the table by entering each valid transition including
the state name, event name, transition condition, transition action, and transition next
state name.
Step 4. Walk-through the table by checking that each event [condition]
pair has the proper action and destination state.
Step 5. Check the consistency with diagrams to ensure consistent class names, operation names, state names, event names, etc.
In creating the state diagram, you must fill-in the several
specification input forms to fully describe the state diagram, states and transitions.
There are three specification forms used: state diagram information, state information,
and transition information. The steps to input specification information and create
reports using a CASE tool are listed below.
>> Run the CASE tool from Windows
>> Open the state diagram, e.g. c:\car\carsysta.omt
>> Double click on each state and transition and fill-in the information
>> Select "File - Save" to save the diagram and specification information
>> Select "Generate - State Code/Report" to create a state report. e.g. RPTSTATE.SCT and TABSTATE.SCT
The state diagram specification form is used to enter information for
the entire state diagram. This form is used to enter information such as the initial
state, termination state, and fault state. Below is the sample state diagram specification
form for the Car Simulation System state diagram.
Figure Sample state diagram specification form.
The following information about the entire state diagram is collected in this specification input form.
- Initial State: name of the initial state.
- Terminal State: name of the terminal state
- Fault State: name of the fault state
- State Class: name of the class that defines the states.
- User Field 1, 2, 3: may hold any user information, e.g. state
entry or exit action or description
The state information specification form is used to enter information for each state. This form is used to describe the state, such as state description and state entry code. As discussed by Rumbaugh, a state can have internal actions, e.g. a continuous do activity, an entry action, an exit action [Rumbaugh-91]. A state can be a super state or substate. Also a state can be concurrent with another state. This information can be documented in the state information specification form. Below is the sample state information specification form for OffState from the Car Simulation System state diagram.
Figure Sample state specification form.
The following information is collected in this specification input form.
- State Name: name of the state, e.g. ReadyState
- State Entry Code: source code to be executed upon entry into the state, e.g. a do: Activity
- Description: general state information.
- Initial State: name of the initial state.
- Terminal State: name of the terminal state
- State Class: name of the class that defines the states.
- User Field 1: may hold any user information, e.g. state entry or exit action
- User Field 2: may hold any user information, e.g. state entry
or exit action.
The following is additional information that may be collected:
- State Superstate: name of the superstate.
- State Do Activity: continuous do activity that is performed in this state.
- State Exit Action: action performed upon exit from this state
The transition information specification form is used to describe each transition on the state diagram. This form is used to enter information such as the event name, condition, and action. Below is the sample transition information form for the start transition from the Car Simulation System state diagram.
Figure Sample transition specification form.
The following information is collected in this specification input form.
- Event: an occurrence at a point in time that is a stimulus for an object, e.g. turnOn, turnOff
- Condition(s): an expression that evaluates to a logical value of true or false, e.g. gasQuantity > 0
- Action(s): an expression or statement that invokes an operation, sets an attribute value, or similar work, e.g. turnMotorOn ().
- Sequence: a number that indicates the sequence of the transition, e.g. 1, 2, ...
- Parameters: event parameters, e.g. int aNumber.
- Description: details about the transition, e.g. This transition occurs when a user presses the On Button.
To access the state and transition specification information, you need
to know the script variable for each piece of information in the state and transition
specification input form. The following are sample script variables from the state and
transition in a CASE tool. A brief description states what occurs when the script variable
appears in a script. Global state diagram variables access information from the state
information specification.
STATE_ALL_INITIAL_STATE Prints the initial state name, e.g. Initial_State
STATE_ALL_TERMINAL_STATE Prints the terminal state name, e.g. Terminal_State
STATE_ALL_FAULT_STATE Prints the fault state name, e.g. Fault_State
STATE_ALL_USER1 Prints the user1 field, e.g. Comment number 1
STATE_ALL_USER2 Prints the user2 field, e.g. Comment number 2
STATE_ALL_USER3 Prints the user3 field, e.g. Comment number 3
State variables access state information from state diagrams and state
specifications.
STATE_NAME Prints the state name, e.g. ReadyState
STATE_CLASS_NAME Prints the class name holding the state, e.g. Controller
STATE_ENTRY_CODE Prints entry code, e.g. do Activity:
STATE_INITIAL_NAME Prints the name of the initial state, e.g. OnState
STATE_TERMINAL_NAME Prints the name of the terminal state, e.g. EndState
STATE_DESCRIPTION Prints the description of the state
STATE_USER1 Prints user information
STATE_USER2 Prints user information
Transition variables access transition information from state diagrams
and transition specifications. Since a state may have many transitions, place the
transition variables inside the repeat operator []. For example, the following script
statement prints all the transition event names for each state [TRANSITION_EVENT,
].
TRANSITION_EVENT Prints the transition event, e.g. turnOn
TRANSITION_EVENT_WITH_PARAMETERS Prints the transition event name and parameters,
e.g. turnOn (int aNumber)
TRANSITION_CONDITION Prints the condition expression that evaluates to true
or false, e.g. gasQuantity > 0
TRANSITION_ACTION Prints the action, e.g. turnMotorOn()
TRANSITION_CURRENT_STATE Prints the name of the current state, e.g. ReadyState
TRANSITION_NEXT_STATE Prints the name of the next state, e.g. OperatingState
TRANSITION_SEQUENCE_NUMBER Prints the transition sequence number, e.g. 1, 2, ....
TRANSITION_DESCRIPTION Prints the description
EVENT_LIST_NAME Prints the event names, e.g. [EVENT_LIST_NAME,]
EVENT_LIST_NAME_WITH_PARAMETERS Prints the event names with parameters,
e.g. [EVENT_LIST_NAME_WITH_PARAMETERS]
STATE_LIST_NAME Prints the state names, e.g. [STATE_LIST_NAME,]
After the various specification forms have been filled-in, you may
create output reports listing the state information. The following is a sample State and
Transition Report for the Car Simulation System.
State and Transition Specification Report
States : OffState , OperatingState , TerminationState
Events: operate , stop , start
Events with Parameters: operate(), stop(), start(),
Initial State: OffState
Terminal State: Termination State
Fault State: N/A
User1 Field: This state diagram shows the system state behavior.
User2 Field: N/A
User3 Field:N/A
------------------------------------------------------------------------
State Name: OffState
State Class Name: N/A
State Entry Code: N/A
Initial State : OffState
State User1 Field: N/A
State User2 Field: N/A
State Description: OffState is the
initial state for the Car Simulation System
Transition Current State: OffState
Transition Event: start
Transition Event Parameters: start()
Transition Condition: gasQuantity > 0
Transition Action: showStatus ("Car started")
Transition Sequence Number: 1
Transition Next State: OperatingState
Transition Description: start is a
system input event.
Figure Sample State and Transition Report
The script (RPTSTATE.SCT) to generate this report from a state diagram
is shown below.
Script to Generate the State and Transition Report
SCRIPT_NOREPEAT_HEADER_BEGIN
States : [ NO_RETURN STATE_LIST_NAME ,DELETE_LAST_SYMBOL]
Events: [ NO_RETURN EVENT_LIST_NAME ,DELETE_LAST_SYMBOL]
Events with Parameters: [ NO_RETURN EVENT_LIST_NAME_WITH_PARAMETERS,DELETE_LAST_SYMBOL ]
Initial State: STATE_ALL_INITIAL_STATE
Terminal State: STATE_ALL_TERMINAL_STATE
Fault State: STATE_ALL_FAULT_STATE
User1 Field: STATE_ALL_USER1
User2 Field: STATE_ALL_USER2
User3 Field: STATE_ALL_USER3
SCRIPT_NOREPEAT_HEADER_END
---------------------------------------------------------------
State Name: STATE_NAME
State Class Name: STATE_CLASS_NAME
State Entry Code: STATE_ENTRY_CODE
Initial State : STATE_INITIAL_NAME
Terminal State : STATE_TERMINAL_NAME
State User1 Field: STATE_USER1
State User2 Field: STATE_USER2
State Description: STATE_DESCRIPTION
[
Transition Current State: TRANSITION_CURRENT_STATE
Transition Event: TRANSITION_EVENT
Transition Event Parameters: TRANSITION_EVENT_WITH_PARAMETERS
Transition Condition: TRANSITION_CONDITION
Transition Action: TRANSITION_ACTION
Transition Sequence Number: TRANSITION_SEQUENCE_NUMBER
Transition Next State: TRANSITION_NEXT_STATE
Transition Description: TRANSITION_DESCRIPTION ]
Once we have modeled the system stimulus response behavior in a state
diagram and identified classes within the system, we can model object state based behavior
with state diagrams in the dynamic model. A system that has state based behavior at the
system level, will have one or more state diagrams to describe object state based
behavior. In other words, certain classes within the system will have objects with state
based behavior. For example, if an object has state (mode of behavior) and responds
differently to an event based upon its current state, then we can create a state diagram
for the class of the object. The important point from the diagram below is that some
classes in a system have objects with states.
Figure States in a System
We can use state diagrams to describe the state based behavior of objects in a system. The key questions are:
- For each use case, is there zero, one, or many state diagrams?
- For each use case, is there a class that may contain the state
transition logic, e.g. Controller Class?
The basic steps to create the state diagram for objects are:
Step 1 - Complete the system object model, system dynamic model, and
object model to identity the use cases, system state behavior, and classes in the system.
Examine the system requirements statement, system use case diagram, system use case
descriptions, system diagram (OMT Notation), system state diagram, and class diagram.
Step 2 - Identity a use case, sub-use case, or system input event the
requires a state diagram to document the states, conditions, events, and actions by
objects in the system.
Step 3 - Create the state diagram by identifying the states, events,
conditions, and actions for a use case, sub-use case, or system input event.
Step 4 - Identify the class and object to hold the state based logic,
e.g. Controller Class.
Step 5 - Identify the classes and objects that receive messages
(actions).
Step 6 - Walk-through the state diagram by sending each event to ensure
the correct transitions.
Step 7 - Verify consistency with the other diagrams to ensure consistent
class names, operation names, and parameter names.
Step 8 - Prototype, test, and iterate.
In the Car Simulation System there is the use case "Use Car".
There is the system state diagram showing the input events and output events for this use
case. Now we want to look inside the system to examine how to implement the state based
logic for this use case. As shown in the object model class diagram below, there is the
Car and Motor classes. From the dynamic model object interaction diagram, there are car1
and motor1 objects.
Class Diagram Object Interaction Diagram
Figure Class Diagram and Object Interaction
Diagram
To implement the state based behavior for the "Use Car" use
case, we created the state diagram shown below. We identified the Car Class to hold the
state based behavior. Objects of the Car class have state based behavior because the event
operate has different actions based up the state (mode of behavior). If the car object is
in the OffState and receives the event operate then there is no action. If the car object
is in the OperatingState and receives the event operate then there is the action
"currentMotor.operate (aSpeed)".
Figure State Diagram
The following is the state transition table for the state diagram
implementing the "Use Car" use case.
State Transition Table
| State Name | Event Name | Transition Condition | Transition Action | Transition Next State |
| OffState | start() | gasQuantity > 0 | currentMotor.start(); | OperatingState |
| OffState | operate(int aSpeed) | 1 | OffState | |
| OperatingState | operate(int aSpeed) | gasQuantity > 0 | currentMotor.operate(aSpeed); | OperatingState |
| OperatingState | operate() | gasQuantity == 0 | currentMotor.stop(); | OffState |
| OperatingState | stop() | 1 | currentMotor.stop(); | TerminationState |
The data dictionary based upon the state diagram listing state names is shown below.
Data Dictionary from Dynamic Model (States)
| Entity Name | Type of Entity | Enclosing Class | Description |
| OffState | State | Car | Initial State |
| OperatingState | State | Car | -- |
| TerminationState | State | Car | Terminal State |
The script (DDSTATE.SCT) to generate this table based upon the state diagram is shown
below.
Script to Generate the Data Dictionary from the Dynamic Model (States)
SCRIPT_NOREPEAT_HEADER_BEGIN
Entity Name,Type of Entity,Enclosing Class,Description
SCRIPT_NOREPEAT_HEADER_END
STATE_NAME,State,STATE_CLASS_NAME,STATE_DESCRIPTION
There are many, many ways to code the state based logic in C++: single
event process function with case switch statements, single event process function with
if..else statements, event process function for each event, and polymorphic event process
functions in state base and derived classes. Each of these approaches is discussed in the
chapter "Creating C++ Scripts to Generate Finite State Machine Code". In this
section, we will present the event process function for each event. The class diagram for
the Car and Motor class and the object interaction diagram for the car1 and motor1 objects
is shown above. The C++ code to implement state based logic in the Car class is listed
below. The car.h and car.cpp files were generated from a CASE tool.
Listing Sample C++ Code for Finite State
// Class: Car
#ifndef __CAR_H //Required for current class
#define __Car_H
#include <cstring.h>
#include "motor.h"
enum States { OffState, OperatingState, TerminationState };
class Car
{
States currentState;
string condition;
int gasQuantity;
Motor currentMotor;
public:
Car () : currentState ( OffState ), condition ("true"),
gasQuantity (1) { }
void start(); // throw (string)
void operate(int aSpeed); // throw (string)
void stop(); // throw (string)
};
#endif
/////////////////////////////////////car.cpp file///////////////////////////
// Class: Car
#include "Car.h"
#include <iostream.h>
void Car::start() //throw (string)
{if ( ( currentState == OffState ) && (gasQuantity > 0) )
{ currentMotor.start(); currentState = OperatingState; cout << "Car started"; return;
}
else { string eventError ("Event Error"); throw eventError; }
}
void Car::operate(int aSpeed) //throw (string)
{if ( ( currentState == OffState ) && (1) )
{ currentState = OffState; cout << "Car not operating"; return;
}
if ( ( currentState == OperatingState ) && (gasQuantity > 0) )
{ currentMotor.operate(aSpeed); currentState = OperatingState; cout << "Car operating"; return;
}
if ( ( currentState == OperatingState ) && (gasQuantity == 0) )
{ currentMotor.stop(); currentState = OffState; cout << "Car stopped"; return;
}
else { string eventError ("Event Error"); throw eventError; }
}
void Car::stop() //throw (string)
{if ( ( currentState == OperatingState ) && (1) )
{ currentMotor.stop(); currentState = TerminationState; cout << "Car stopped"; return;
}
else { string eventError ("Event Error"); throw eventError; }
}
///////////////////////////////Class: Motor
motor.h///////////////////////////////
#ifndef __MOTOR_H //Required for current class
#define __Motor_H
#include <cstring.h>
class Motor
{
public:
void start(); // throw (string)
void operate(int aSpeed); // throw (string)
void stop(); // throw (string)
};
#endif
/////////////////////////////////////motor.cpp file///////////////////////////
// Class: Motor
#include "Motor.h"
#include <iostream.h>
void Motor::start() //throw (string) { }
void Motor::operate(int aSpeed) //throw (string) { }
void Motor::stop() //throw (string) { }
////////////////////////////////main.cpp//////////////////////////////////////
#include "Car.h"
int main ()
{ Car car1;
car1.start();
car1.operate (55);
car1.stop ();
return 0;
}
///////////////////////////Sample Output////////////////////////////////////
//Car started Car operating Car stopped
In this chapter we presented how to model a system or an object in the system with states and transitions. Whenever we have a system or object with complex stimulus response behavior it is useful to identify states and transitions. A state diagram and/or a state table displays the sequence and logic of events and conditions triggering actions and possibly triggering the transition to a different state.