A statechart diagram tracks the different states that the program can be in, and how each state changes from one to the next. States usually change via trigger events, which are labeled next to the arrows between states. Most states exist as some form of "waiting state," where the state of the object is to wait for some trigger event that will bring it into the next state. Passive states are object states that are not currently in transition. The state is represented by the current values attributed to the object. Active states, on the other hand are states that are actively transitioning, and require an event in order to bring them from one active state to another. Some states, "Activity states," are listed with "do-activities," which are special actions that are performed while an object is in that state. When the action is finished, the state will act like a normal "waiting state." Some state transitions happen without a trigger event at all, however, and they will switch from one state to the next on their own. An activity state that doesn't require a trigger to transition will transition after its "do-activity" is finished. Actions and guards are associated with events. Actions are special requirements that need to be done concurrently by the object with the event or because of the event. A gurad is a boolean condition that must be met in order to continue with the transition.'
State diagrams are helpful with avoiding errors because they map out every state the object in question can be in based on the trigger events they
may encounter. This may allow you to plan and block certain events from happening, and stop you from missing an action that may lead to
unexpected consequenses before coding begins.
The Login Example
When logging in to an account, it's important to make sure there are no unexpected errors. This state diagram starts by waiting for the user's input. In this state, input is still being accepted. Then, after the user presses the 'login' button, the login event has been triggered, and the object moves into the next state to see if the username and password match the record. In this state, no changes to the login information is allowed. If the username is wrong, a message will be given to the user. If the password is wrong, the account will instantly be locked. (Not the most friendly solution, but a secure one!) If both are correct, the user will be logged in. The object will also send a message to the email associated with the account.