29.6. Classes that Benefit from Statechart Diagrams

In addition to statechart diagrams for use cases or the overall system, they may be created for virtually any type or class.

State-Independent and State-Dependent Objects

If an object always responds the same way to an event, then it is considered state-independent (or modeless) with respect to that event. For example, if an object receives a message, and the responding method always does the same thing—the method will typically have no conditional logic. The object is state-independent with respect to that message. If, for all events of interest, an object always reacts the same way, it is a state-independent object. By contrast, state-dependent objects react differently to events depending on their state.

In general, business information systems have a minority of interesting state-dependent classes. By contrast, process control and telecommunication domains often have many state-dependent objects.

Common State-dependent Classes

Following is a list of common objects which are usually state-dependent, and for which it may be useful to create a statechart diagram:

• Use cases

  • Viewed as a class, the Process Sale use case reacts differently to the endSale event dependent of if a sale is underway or not.

• Stateful sessions— These are server-side software objects representing ongoing sessions or conversations with a client; for example, EJB stateful session objects.

  • Another very common example is server-side handling of web client application and presentation flow logic; for example, a Java technology servlet helper or “controller” that remembers the state of the session with a Web client, and controls the transitions to new web pages, or the modified display of the current web page, based upon the state of the session or conversation.

  • A stateful session can usually be viewed as a software class representing a use case. Recall that one of the GRASP Controller pattern variants is a use case controller, which is a use case stateful session object.

• Systems— This is a class representing the overall application or system.

  • The “POS system.”

• Windows

  • The Edit-Paste action is only valid if there is something in the “clipboard” to paste.

• Controllers— These are GRASP controller objects.

  • The Register class, which handles the enterItem and endSale system events.

• Transactions— These are ways a transaction (a sale, order, payment) reacts to an event is often dependent on its current state within its overall lifecycle.

  • If a Sale received a makeLineItem message after the endSale event, it should either raise an error condition or be ignored.

• Devices

  • TV, microwave oven: they react differently to a particular event depending upon their current state.

• Role Mutators— These are classes that change their role.

  • A Person changing roles from being a civilian to a veteran.