(To appear in OOPSLA'95) Object-Oriented State Machines: Subclassing, Composition, Delegation, and Genericity Aamod Sane ¡ and Roy Campbell University of Illinois at Urbana-Champaign Department of Computer Science 1304 W. Spring®eld Avenue, Urbana, IL 61801 £ email: ¢ sane,roy @cs.uiuc.edu www: http://choices.cs.uiuc.edu/sane/home.html ¤¦¥¨§ © © machines by incrementally modifying and combin- ing other independently designed machines. In ad- Software speci®cation and implementation techniques dition, we present a novel, highly ef®cient technique based on state machines simplify design, coding, and validation. However, large systems require complex for implementing state machines that extends object- state machines. Incremental construction techniques oriented approaches such as the rei®cation technique can control this complexity. In this paper, we present a (RT) [13, 8]. Our technique facilitates incremental construction technique that permits derivation of com- derivation of state machines using subclassing, com- plex state machines from simpler state machines. The position, delegation, and genericity (henceforth called technique uses subclassing, composition, delegation, object-oriented-techniques (OOT)),and improves upon and genericity to incrementally modify and combine simpler machines. the reuse afforded by RT. In addition, we present a novel implementation technique that uses exactly one table-lookup and one We motivate the use of subclassing by consider- addition to dispatch events on derived state machines, ing a simple virtual memory (VM) paging scheme no matter the depth of the derivation. As an example, (Figure 1) that is enhanced to support copy-on-write we describe the derivation of a complicated distributed virtual memory scheme from a simple paging virtual (COW) [1] (Figure 2). In Figure 1, a virtual memory memory scheme. page may be mapped into physical memory so that it is accessible. The page may be unmapped to store it on © © backing store and release physical memory for other use1. The state machine in Figure 2 supports copy- Many designers advocate the use of state machines on-write. COW allows data created by one process to to specify and implement software systems. For ex- be shared with a different process without requiring ample, reactive system designs [10] and object-orien- the data to be copied. Instead, the physical pages on ted analysis and design [26, 2, 5] use state machines. which the data resides are shared between processes However, large systems require complex state ma- until the processes modify them. Data is ªcopiedº chines. In this paper, we introduce object-oriented by mapping the associated physical page into the vir- techniques that permit the design of complex state tual address space of the target process with read-only access. However, upon a write access, the ªcopiedº Supported by CNRI contract CNRI GIGABIT/UILL. data is duplicated by copying the page to a new phys- ical page and changing the read-only access to write access. The two ®gures show several similarities, for example states RMapped, WMapped, are simi- 1For simplicity, the state machine diagrams do not show loops (transitions that do not change state). !F"%$>&(G)H+-,I. 1 3 1 3 0 0 2 2 !#"%$'& (*)'+-,/. JK4L56678 JM9N:<O5667%8 !#"$>&%PQ&R"ST !#"$>&UWVEX+& ,I. 01 23 01 23 4¦5667%8 9;:<=5667%8 YZ"R[\& ];^_!\`#,/. !F"%$>&UWV-X+a& ,/. Yb" [c& ];^R!c`#,I. !#"$>&@?BA%AC&@DED ,/. !F"%$>&(G)H+-,I. 01 23 01 23 de4¦5667%8 d9;:<=5667%8 Figure 1: Page States in a !F"%$>&Pf&R"Sg,I. Simple Virtual Memory System Figure 2: Page States for Copy-On-Write lar to Mapped and methods pageRead(), pageWrite() can be eliminated if necessary. Section 6 summarizes are similar to pageAccess(). The two ®gures have topics such as subtyping and nested states that are not differences corresponding to the additional behavior, discussed in detail due to space restrictions. We con- for example, makeCopy() is added and pageWrite() sider related work in Section 7, and in the conclusion causes transitions from RMapped to WMapped. (Section 8) we indicate possible generalizations of our Using the techniques in this paper, the similari- techniques and other avenues for further research. ties between the two state machines can be captured h i gm by subclassing. VM machine code corresponding to F¥jckl g§R§ similar transitions can be reused in the COW machine, and new COW code need be written only for additional In this section, we consider how to derive the COW behavior. The paper presents other examples showing machine (Figure 2) as a subclass of the Simple VM how complex state machines that support distributed machine (Figure 1). We ®rst show that standard tech- virtual memory (DVM) are also easily derived using niques such as RT [13, 8] block certain kinds of reuse. OOT, while maximizing reuse. Then we observe that this is not an artifact of any particular implementation technique. Reusing code Besides maximizing reuse,our techniques also show while subclassing state machines is dif®cult because that in order to properly de®ne subclassing, compo- the IS-A relationship between states of base and de- sition, etc., for state machines, we have to reconsider rived machines, and the BECOMES-A relationship the usual notion of Self (ªthisº in C++). Section 2 induced by state transitions, interact with each other. considers this issue in greater detail. In the remainder Hence, a general solution requires a rede®nition of the of the paper2, we give examples of composition, del- notion of Self that accounts for both relationships. egation, and genericity in Section 3. The de®nition of §q nsr Self (Section 2) leads to formal de®nitions of OOT in nNog§Rop o'§ © I©% Figure 3 shows an im- terms of embeddings (Section 4). Analysis based on plementation (in OMT-like notation [21]) of the VM embeddings suggests a fast implementation involving state machine (Figure 1) using RT3, where states are a single indexed table lookup (Section 5), regardless rei®ed as objects, and method calls implement state of the height of the subclassing, composition, or del- transitions. egation hierarchy. A space-ef®cient implementation In Figure 3, pages are instances of the class Page. of generics requires one more lookup, but the lookup PageState is the abstract class that declares the 2We use Mealy machines [11], but since actions may be asso- methods for each state of a page, while the classes ciated with either source or destination state objects, our technique 3We build on RT. For comparisons between RT and other also applies to Moore machines [11]. techniques see [8]. R~yR~{ j @@ \ tu@v w x\yRz{ |}~% ¨@' ¨ x\yRz{R { H% ¨@' j fu_ %w@ j uRR%w@ R~yR~{ x\yRz { |} ~C R~yR~{ x\yRz {RR { ¨@ x\yRz{ |}~% x\yRz{ |}~% x\yRz{R { ¨@ x\yRz{R { ¨@ Legend: inheritance, instance variables, method implementation. Figure 3: Reifying States as Objects Mapped and Unmapped represent the concrete sta- ce(). Thus, with RT, the code for Mapped::pageOut() tes of a page. Each page object maintains a current cannot be reused in both methods without modi®ca- state variable state, that points to an instance of tion. Mapped or Unmapped. Methods of class page (e.g., In abstract terms, the problem is that since pa- Page::pageOut()) invoke the corresponding method of geOut() is implemented in the superclass, it cannot the PageState. For instance distinguish between the states WMapped and RMa- Page::pageOut() pped. We observe that when state machines are de- £ ¢ state = state->pageOut(this); ; rived, one transition in the base state machine can The state methods de®ne actual behavior, as in correspond to a number of transitions in the derived Mapped::pageOut(Page * p) states. In general, a transition's source and destina- ¢ p->flushMMU(); p->writeToDisk(); tion state arities may change in unrelated ways during return Unmapped::Instance(); £ ; subclassing. Therefore, we need two different ways to The state objects themselves have no instance vari- map the source and destination states of a transition. ables, so there is only one systemwide instance of each In the following, we present an implementation based concretestate. The method call Unmapped::Instance() on this observation. returns a pointer to the system-wide instance. i gmMi ¨§ ©% g©oe¢q F£g§ Using RT, the COW machine might be imple- #k/g©%¡ Instead of returning a mented directly in a similar manner. However, sup- programmed constant, we return the next state indi- pose that we want to reuse VM machine code for meth- rectly by looking-up the actual state we want to return ods such as Mapped::pageOut(), since the behavior in tables called StateMaps. Derived machines are then is similar to that of WMapped::pageOut() and RMa- constructed by systematic modi®cation of StateMaps, pped::pageOut(). We might derive a class WMapped and base state methods are inherited without change. from the class Mapped, hoping to reuse Mapped::pa- A StateMap is similar to a C++ VTable [7]: C++ geOut(). But now there is a problem: where Map- virtual functions are dispatched using the VTable, so ped::pageOut() returns Unmapped::Instance(), WMa- that derived classes can replace ªvirtual functionsº of pped::pageOut() must return WUnmapped::Instance(). the base class with their own versions. Similarly, a Although behavior in the two states is similar, the StateMap is used to determine the actual next state, state transitions differ for the COW machine. If we so that a derived state class may ªreplaceº it with the attempt to reuse Mapped::pageOut() by rede®ning Un- next state appropriate for the derived machine. Fur- mapped::Instance() to return WUnmapped::Instance(), thermore, just as every C++ class has its own VTables, we ®nd that RMapped::pageOut() cannot reuse Map- every state has its own StateMap.