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.
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.
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
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"?
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
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
- 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.
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 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_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.
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.
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.
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.
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.
The script (RPTSTATE.SCT) to generate this report
from a state diagram is shown below.
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.
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
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)".
The following is the state transition table for the
state diagram implementing the "Use Car" use case.
| 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.
| 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_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.