You can create state machines to describe classes and systems that have significant behavior. Not all objects require state machines. If an object's behavior is basic, if it simply stores or retrieves data, the behavior of the object might not be important to you and its state machine might be of little interest. State machines can also contain nested states that represent different hierarchical state levels. You can use nested states to examine complex state changes in objects.
You can add diagrams to a state machine to describe different perspectives of the behavior of an object. Each diagram opens as a separate window but the same model elements are displayed in all diagrams. The diagrams within a state machine are synchronized by default. Changes made to a region in the Project Explorer view are reflected in the other diagrams of the same state machine and changes made to a region in a diagram are reflected in the Project Explorer view. You can change the edit settings of a region so that changes made to a region in the Project Explorer view are not reflected in the corresponding state machine diagrams and so that a region can be edited independently of other diagrams in the same state machine by changing the canonical properties value of a region to false.
State machines are useful modeling aids for developing real-time or event-driven systems because they show dynamic behavior. You can develop state machines during all phases of a software project and for business modeling. You can use state machines in the following situations:
You can use state machines to model event-driven behavior. Events such as time, signals, or operations can cause the state of an object to change. An event has no duration and can precede or follow another event. States that model event-driven behavior continue in the same state until the arrival of an event. After the state responds to an event, the process reverts to a stable state that is ready to receive the next event.