13.5 Reclassification

I l@ve RuBoard

13.5 Reclassification In the bookstore, the warehouse makes a policy of hiring clerks who can take on several roles, so that the shipping clerk is really just one kind of a more general warehouse clerk. Sometimes a warehouse clerk may be processing shipments, at other times the same clerk may be assigned to restock product, and at still other times the clerk may be off duty. Because a single clerk can take on several roles during a shift, there must be a mechanism to support reclassification, in which an instance of one subclass becomes an instance of a different subclass in the same hierarchy. Executable UML recognizes the need for reclassification in the context of a generalization and specialization hierarchy when an object playing one role starts to play another role. This fact imposes certain additional rules for formalizing lifecycles as state machines. Chief among these is that each of the stages in the life of the object must fall into one and only one of the subclasses. Since a clerk may now be "off duty" without being assigned to stock or to ship, we need to create a third OffDutyClerk subclass to account for those clerks who are neither stocking nor shipping, as shown in Figure 13.13. Figure 13.13. Warehouse Clerk Subclasses, Including OffDutyClerk 13.5.1 Superclass State Machine One approach to modeling reclassification is to formalize the whole lifecycle of the superclass. We can create a single Warehouse Clerk state machine that contains all the states of a Shipping Clerk and all the states of a Stock Clerk. This lifecycle also includes an off-duty state where a clerk is neither shipping nor stocking. Figure 13.14 shows this model. Figure 13.14. Shipping Clerk (on Duty) Lifecycle The state procedures in a superclass lifecycle make use of reclassification actions. For the Warehouse Clerk, these reclassifications take place in states 1, 2, and 9. 13.5.2 Subclass State Machines with Reclassification The single lifecycle shown in Figure 13.14 has many states and incorporates the lifecycles of each of the subclasses. An alternative to building a superclass state machine is to build individual state machines for each of the subclasses. The actions in one subclass's final state cause reclassification. Reclassification state machines each have initial and final states. Reclassification occurs in the final state of each subclass's state machine. An action in the final state sends a signal to the reclassified subclass. Figure 13.15 shows a ShippingClerk statechart diagram with reclassification. When the Shipping Clerk comes into existence (the initial pseudostate), it receives a startShipping event. When the Shipping Clerk is signaled to go off duty, it reclassifies into an Off Duty Clerk and signals goOffDuty. The initial and final states of the Stock Clerk and the Off Duty Clerk manage their reclassification in a similar manner. Figure 13.15. Warehouse Clerk (Superclass) Statechart Diagram Showing Reclassification Now that we have a set of techniques to model classes and relationships between them, we turn our attention to applying these techniques to describe the dynamics of a domain as a whole.

I l@ve RuBoard