The statechart, or state transition, diagram is another way to determine class methods. It is used to examine the different states that an object may have. A statechart diagram is created for a single class. Typically objects are created, go through changes, and are deleted or removed.
Objects exist in these various states, which are the conditions of an object at a specific time. An object’s attribute values define the state that the object is in, and sometimes there is an attribute, such as Order Status (pending, picking, packaged, shipped, received, and so on) that indicates the state. A state has a name with each word capitalized. The name should be unique and meaningful to the users. A state also has entry and exit actions, the things the object must do every time it enters or leaves a given state.
An event is something that happens at a specific time and place. Events cause a change of the object state, and it is said that a transition “fires.” States separate events, such as an order that is waiting to be filled, and events separate states, such as an Order Received event or an Order Complete event.
An event causes the transition, and happens when a guard condition has been met. A guard condition is something that evaluates to either true or false, and may be as simple as “Click to confirm order.” It also may be a condition that occurs in a method, such as an item that is out of stock. Guard conditions are shown in square brackets next to the event label.
There are also deferred events, or events that are held until an object changes to a state that can accept them. A user keying something in when a word processor is performing a timed backup is an example of a deferred event. After the timed backup has completed, the text appears in the document.
Events fall into three different categories:
- Signals or asynchronous messages, which occur when the calling program does not wait for a returning message, such as a feature run from a menu.
- Synchronous messages, which are calls to functions or subroutines. The calling object stops and waits for control to be returned to it, along with an optional message.
- Temporal events, which occur at a predetermined time. These usually do not involve an actor or any external event.
Material objects have persistence; that is, they exist for a long period of time. Airplane flights, concerts, and sporting events have shorter persistence (they may have states that transition in a shorter time). Some objects, called transient objects, do not survive the end of a session. These include main memory,Web URL (or location) data,Web pages, CICS displays, and so on. The only way to save transient objects is to store information about them, such as storing Web data in a cookie.
Each time an object changes state, some of the attributes change their values. Furthermore, each time an object’s attributes change, there must be a method to change the attributes. Each of the methods would need a display or Web form to add or change the attributes. These become the interface objects. The display or Web form would often have more controls (or fields) on them than just the attributes that change. They would usually have primary keys, identifying information (such as a name or address), and other attributes that are needed for a good user interface. The exception is a temporal event, which may use database tables or a queue containing the information.
A State Transition Example
Consider a student enrolling at a university and the various states that he or she would go through. Three of the states are listed below in detail:
State: Potential Student Event: Application Submitted Method: new() Attributes changed: Number Name Address User interface: Student Application Web Form State: Accepted Student Event: Requirements Met Method: acceptStudent() Attributes changed: Admission Date Student Status Return Acceptance Letter User interface: Accept Student Display State: Dorm Assigned Student Event: Dorm Selected Method: assignDorm() Attributes changed: Dorm Name Dorm Room Meal Plan User interface: Assign Student Dorm Display |
The other states are Program Student, Current Student, Continuing Student, and Graduated Student. Each state would have an event, methods, attributes changed, and a user interface associated with it. This series of states can be used to determine the attributes and methods that make up part of the class.
The states and events that trigger the changes may be represented on a statechart diagram (or a state transition diagram). The statechart diagram for Student is illustrated in the figure below.
States are represented by rectangles, and events or activities are the arrows that link the states and cause one state to change to another state. Transition events are named in the past tense, because they have already occurred to create the transition.
Statechart diagrams are not created for all classes. They are created when:
- A class has a complex life cycle.
- An instance of a class may update its attributes in a number of ways through the life cycle.
- A class has an operational life cycle.
- Two classes depend on each other.
- The object’s current behavior depends on what happened previously.
When you examine a statechart diagram, use the opportunity to look for errors and exceptions. Inspect the diagram to see whether events are happening at the wrong time. Also check that all events and states have been represented. Statechart diagrams have only two problems to avoid. Check to see that a state does not have all transitions going into the state or all transitions coming out of the state.
Each state should have at least one transition in and out of it. Some statechart diagrams use the same start and terminator symbols that an activity diagram uses: a filled-in circle to represent the start, and concentric circles with the center filled in to signify the end of the diagram.
