Implementation of the Dynamic Behavior of Object Oriented System

Jauhar Ali and Jiro Tanaka Institute of Information Sciences and Electronics, University of Tsukuba, Japan

ABSTRACT Object oriented methodologies such as Object Modeling Technique (OMT), suggest to create dierent models of a system indicative of its static structure and dynamic behavior. Converting the static structure (usually represented as an ER-style diagram) into implementation code is already much understood. On the contrary, implementing the dynamic behavior is rather less understood and is considered as a dicult job. A method is proposed here to implement the dynamic behavior of a system in an object oriented programming language like Java. To implement the dynamic behavior, we suggest the classication of objects on the basis of three criteria: multi-state/uni-state objects, passive/active objects and permanent/temporary objects. Implementation of intra-object concurrency as well as multiple-thread concurrency has been addressed. We use the inheritance mechanism to implement the supersubstate relationship in statecharts, which represent the behavior of multi-state classes. States become classes and their transitions become operations in the corresponding classes. Orthogonal components in statecharts, which become active simultaneously, are implemented by the concept of object composition. Active objects represented by activity diagrams are implemented as Java threads. The method can serve as a basis for automatic code generation.

erties as well as behavior. There are many OO methodologies (Booch, 1991; Coad, 1991; Jacobson, 1992; Desfray, 1994) that help nd the structural properties and behavior of a system by creating its dierent models. Object Modeling Technique (OMT) (Rumbaugh et al., 1991), which is a popular OO methodology, represents the static aspects of a system by object model and its dynamic behavior by dynamic model. The models are created in analysis phase and rened in design phase. A big problem in the development of a system through OO methodologies is that even after having created good models, it is dicult for a large fraction of programmers to convert the models into executable code. It would be ideal if some CASE tools are available that can automatically generate or help to generate executable code from the models. Some tools (Kim, 1994; Harada, 1996; Rational Rose; Object Domain; MacA&D) are available which generate header les from the object model, which is comparatively easy due to its static nature. To get an executable system, however, a user has to implement the dynamic and other models of the system by himself and combine the implementation code with the header les. We have been working on automatic code generation from the dynamic model, which is represented by a set of statecharts. In this context, we already developed a system (Ali and Tanaka, 1996) that automatically converts the dynamic model represented by a simple statechart into executable Java code (Gosling, 1996). Later, the system was expanded to support concurrent states in the statechart, thus allowing intra-object concurrency (Ali and Tanaka, 1997). Both of our previous systems can generate code from the dynamic model that is represented by a single statechart. However, a real system needs several statecharts to represent its behavior. In the present study, we describe a method to

INTRODUCTION

Object Oriented (OO) software is a collection of interacting objects. Classes of objects have structural prop Contact address: Institute of Information Sciences and Electronics, University of Tsukuba, Tennodai 1-1-1, Tsukuba-shi, Ibaraki 305, Japan. E-mail: jauhar@softlab.is.tsukuba.ac.jp

convert the dynamic model having several statecharts into executable Java code. Active objects and multiple thread concurrency are also treated. While converting the dynamic model into code, we also refer to the object model to generate the initialization code properly.

CLASSIFYING OBJECTS

The dynamic model shows those aspects of a system that change over time. It is represented by statecharts and event trace diagrams. The former shows the complete behavior of objects of a particular class and the later shows the overall interactions between objects of various classes in a particular scenario (Rumbaugh et al., 1991; Rumbaugh, 1993a, 1993b, 1995). Although statecharts can be drawn for any class of objects, our investigation has led us to believe that only few classes of objects really need statecharts to represent their behavior. The behavior of objects has to be implemented dierently based on their types. We suggest three overlapping criteria for classifying objects: multi-state vs. uni-state objects, passive vs. active objects, and permanent vs. temporary objects.

that had sent the message. During the course of execution of one of its methods, a passive object can send messages to other objects. Active objects, on the other hand, keep their own control and execute their methods in a predened sequence. They mostly perform their operations in a continuous loop. During the execution of the methods, they can send messages to execute methods in other objects and cause a temporary transfer of control to those objects. Control is transfered back to the active objects as soon as the execution of the methods in the other objects is nished.

2.3

Permanent Vs. Temporary Objects

2.1

Multi-State Vs. Uni-State Objects

Objects provide a number of services, which are accessed or get executed by sending a message to them. Multi-state objects have dierent states and the availability of services provided by the objects depends upon the state they are currently in. For example, to a Light object, a lightOn message can be sent only if it is in the O state. Likewise, a lightO message can be sent only if it is in the On state. Sending a lightOn message to the Light object in On state is meaningless and should be prohibited by the system. The behavior of a multi-state object is usually represented by a statechart. The methods of uni-state objects, on the contrary, can be executed anytime by other objects. They should be thought as continuously in a single state, rather than stateless. Such objects do not need a statechart. If someone likes to draw statecharts for them, they would contain just one state.

Permanent objects are created in the initialization stage of a system, remain alive while the system is running, and are deleted just before the system stops running. In other words, the life time of permanent objects is almost the same as that of the system itself. The number of this type of objects are usually known to the developer of the system beforehand. On the other hand, temporary objects are created and deleted while the system is running and their life time is shorter than the system. The number of such type of objects are mostly not known to the developer and operator of the system, and usually varies among dierent executions of the same system. Temporary objects are usually held by permanent objects of the system.

2.4

The Controller

This is a special class that keeps the main ow of control of a system (Ali and Tanaka, 1996, 1997; Rumbaugh, 1993a, 1993b). It can be considered an active class, although after initializing the system, it mostly transfers its control to the Graphical User Interface (GUI) component of the system. Typically, there is only one controller in a system, so there is only one object instance of this class. The controller object keeps references to most, but not necessarily all, of the permanent objects of the application.

THE ELEVATOR EXAMPLE

2.2

Passive Vs. Active Objects

Passive objects are those objects that do not usually keep control. A passive object gets control only when some other object sends a message to it causing the execution of one of its methods. After having completed the execution, control is transferred back to the object

We illustrate our approach using an application that simulates a system controlling three elevators and ten oors as a case study. The system has the following constraints. 1. Each elevator has a set of buttons, one for each oor. These illuminate when pressed and cause

the elevator to visit the corresponding oor. The illumination is cancelled when the corresponding oor is visited by the elevator. 2. Each oor has two buttons (the ground and the top oors have only one button each), one to request an up-elevator and one to request a down-elevator. These buttons illuminate when pressed. The illumination is cancelled when an elevator visits the oor and is either moving in the desired direction, or has no outstanding requests. In the latter case, if both oors request buttons are pressed, only one should be cancelled. 3. When an elevator has no requests to service, it should remain at its nal destination with its doors closed and await further requests. 4. All requests for elevators from oors must be serviced eventually, with all oors given equal priority. 5. All requests for oors within elevators must be serviced eventually, with oors being serviced sequentially in the direction of travel.

moves to the required oors in sequential order. When an elevator stops at a oor, it resets the destination button for that oor and gets all the persons o whose destination was that oor. The persons are no more needed, so they are deleted from the system. In a real elevator system, persons should come in randomly at various oors and press the buttons in the desired directions. However, to make the system a bit interactive, we made the user (operator) of the system to press the oor buttons by clicking at them with mouse, meaning that a person has come at the oor and has pressed a button in the desired direction. The Floor object then creates a new Person object and adds it to the list of persons already waiting at the oor. If there is no person waiting at the oor when a new Person object is created, the Floor object also sends out a callElevator message to the Controller in the direction the person wants to go in. The destination oor for a Person object is randomly determined when the object is newly created. Figures 3 and 4 show the behavior of the Floor and Person classes, respectively, in the form of statecharts (Harel, 1987, 1988; Harel and Naamad, 1996). The behavior of the Elevator class is shown in Figure 5 in the form of an activity diagram (Rational Software Corporation, UML). Controller is a uni-state class and does not need a statechart. While the system is running, the Controller keeps waiting for a callElevator message from a Floor object. Just as the Controller receives the message, it assigns the request to the elevator that can service the request most conveniently, and waits for another callElevator message.

DESIGNING THE ELEVATOR SYSTEM

To design the elevator simulation system, we believe that there must be a Controller class that controls all the operations in the system and at least three more classes: Elevator, Floor, and Person. Figure 1 shows the object model and Figure 2 shows the event trace diagram for the system. We used the OMT notation in the diagrams except that in the object diagram the arrow headed lines between classes show possible messages between them. Also, in the event trace diagram, the vertical line representing an object becomes a triple line bar when the object is active (alive), and a single line when the object is deleted. When a button is pressed on a oor, the Floor object sends a request to the Controller for an elevator in the desired direction. The Controller sends a message to each of the Elevator objects asking its convenience for servicing the request. In response, each of the Elevator object gives an integer value representing its convenience for the request. The elevator which returns the highest value is the most convenient, and the Controller assigns the request to it. Each of the elevator runs in parallel and checks whether it has any outstanding requests. If there is a request, the elevator visits the desired oor and sends an arrival message to the Floor object. The oor gets all the persons on (the elevator) that were waiting for an elevator in the desired direction. Each person, while getting on, presses the destination button inside the elevator. The elevator then

IMPLEMENTING THE SYSTEM

Implementing the static structure of the system is straightforward and classes with their attributes and methods are declared as shown in the object model (Figure 1). However, implementing the dynamic behavior of the classes depends on the types of the classes. We show how dierent types of classes are implemented by going through the classes of the elevator example.

5.1

Controller Class

As mentioned in the previous section, the Controller class in the elevator example is a uni-state class. Being a controller, it initializes the system by creating objects that are permanent in the system (10 instances of Floor and 3 instances of Elevator), and it holds references to these objects as well. The initialization code is placed inside the main method of the Controller class, so the initialization code gets executed as soon as the Con-

troller class is executed from the command line. After initialization, control of the system resides in the clickable buttons that represent the up and down buttons at each oor.

5.2

Multi-State Class: Floor

Floor is a passive and multi-state class. To represent the behavior of a multi-state class, we use Harels statecharts (Harel, 1987, 1988; Harel and Naamad, 1996), which can contain nested OR-substates and AND-substates. To implement the statechart, an object-oriented approach is used where each state becomes a class and each transition becomes an operation in that class. Sub-states of a super-state becomes sub-classes of the class that corresponds to the super-state. All the state classes are sub-classed from an abstract class (say State) that serves as a common interface for the state classes (Gamma, 1995). We named the common interface class for the state classes of Floor class as FloorState. This approach is adopted due to the resemblance of the state hierarchy in a statechart and the class hierarchy in an OO program. The sub-states inherit transitions of the super-state just like sub-classes inherit the methods of the parent-class. We observed that if states are represented as classes and their transitions as operations (methods), a statechart can easily be converted into equivalent code. A detailed description of automatic conversion of a single statechart into Java code was presented in our earlier paper (Ali and Tanaka, 1996). All the actions in the statechart become methods in the class that corresponds to the statechart. For example, the callUpElevator and upGetOn actions become methods in Floor class. The Floor class also contains an attribute state of FloorState type. The value of this attribute shows the current state of the Floor object. When an event occurs, on which there is a transition, the corresponding operation in one of the state classes is executed and the state is changed. The structure of the classes that are created for implementing the behavior of the Floor class are shown in Figure 6. Part of the code for the UpWait class is also shown in a separate box in the gure.

of some external event (Rational Software Corporation, UML). Each node in the activity diagram show an activity or possibly a condition, whereas in the statechart it shows a state. As soon as the activity is performed, the transition is triggered and a new activity starts execution. In activity diagram, the object itself determines when to execute a transition. It does not have to wait for other objects to sent it messages, which become events to trigger the transitions. Figure 5 shows the activity diagram for the Elevator. In the proposed approach, an active class is implemented as a Java thread. Therefore, each Elevator object has its own control. The continuous loop, which can be seen in the activity diagram, is placed inside the run method. Each activity becomes a method in the class. If a node represents a condition, e.g., MoveNeeded?, it also becomes a method but returns a boolean value. In the loop, each method is called in the sequence in which it appears in the activity diagram. The method that represents a condition is called from inside an if-statement. Sub-activities, e.g., NotifyArrival and OpenDoor inside the Stop activity, become separate methods as well, and they are called from the method that corresponds to the super-activity (in this case the Stop activity). Figure 7 shows the implementation code derived from the activity diagram of the Elevator.

5.4

Temporary Class: Person

5.3

Active Class: Elevator

Elevator is an active and permanent class. It does not wait for incoming messages from other objects. Instead, it executes a continuous loop and in each iteration it checks whether there is any outstanding request that should be serviced. We represent the behavior of active objects by an activity diagram rather than by a statechart. An activity diagram is like a statechart except that the transitions are not triggered on the occurrence

Person is a temporary class because many of its instances are created and deleted while the system is running. Although its statechart suggests that it is a multi-state class, actually it is not. The Person objects are created by one of the Floor objects, so the Floor object holds references to the Person objects. But when the persons have got into an elevator, the Floor object passes the references to the Elevator object. Since then, the Elevator object keeps references to the Person objects until they get o and, as a result, are deleted from the system. The two states in the statechart of the Person class actually show the two stages in the life of a Person object: 1) when it is held by the Floor object and 2) when it is held by the Elevator object. The states do not have any eect on the behavior of the Person objects.

OTHER DIMENSIONS OF THE ISSUE

In this section, we dicuss some of the issues that are not elucidated in the elevator example.

6.1

Concurrency in Statecharts

Statecharts, which are used to show the behavior of multi-state classes, can have concurrent states (ANDsubstates). AND-substates become active simultaneously whenever their superstate becomes active. Concurrency in a statechart has been described in detail in our earlier paper (Ali and Tanaka, 1997). As already described, in our approach an active state is represented by an object instance. For concurrent states, we need a mechanism that guarantees the creation of as many objects as the number of the concurrent substates whenever their superstate becomes active. That is why, we represent the super-state of AND-substates as a composite class that owns objects of other classes. The composite class has references to the classes corresponding to the AND-substates. When the superstate of AND-substates becomes active, the corresponding composite class gets instantiated. The composite object then instantiates all the classes for which it has references. The instantiation of the composite class thus guarantees the instantiation of the classes that correspond to the AND-substates. This behaves like activating many states simultaneously. Similarly, when the composite object is deleted, all the objects it owns are also deleted. This behaves like leaving all the AND-substates at once when their super-state becomes inactive. As an example, Figure 8 shows part of the statechart for a moving car and the equivalent implementation code. RunningCar is a composite class and holds objects of type Accelerator and Brake. Accelerator and Brake, representing the two concurrent states, are abstract classes and serve as interface classes for their own sub-classes. The OR-substates of the Accelerator and Brake states become concrete sub-classes of the Accelerator and Brake classes, respectively.

to some oor, the Elevator object records the request as an outstanding request. This uni-state behavior of the Elevator class is not shown in the activity diagram (Figure 5). If the Elevator had also been a multi-state class, we would have had to draw a statechart in addition to the activity diagram, and to implement it in a way similar to the Floor class. The Controller, which is a uni-state class in our example, can be a multi-state class. If controller is multistate, it will need a statechart and would be implemented in the same way as Floor class. We have shown examples in our earlier papers (Ali and Tanaka, 1996, 1997), in which controller is a multi-state class. Temporary classes of objects can also be multi-state and/or active, in which case they will need statecharts and/or activity diagrams to represent their behavior and similar treatment to implement them.

6.3

The Final Class Structure

As already explained, to implement statecharts many extra classes are created. In the elevator example, only Floor was a true multi-state class, so only few classes, such as FloorState, which were connected to the Floor class were newly created. In real systems, many classes would be multi-state and much more classes would be created to implement them. The nal class structure of the system would then be similar to that of the object model of the system except that each multi-state class would be connected to a hierarchy of classes that corresponds to the statechart of the multi-state class. Figure 9 shows one possibility of the classes of a system. The nodes in the gure show class types rather than class names.

CONCLUSIONS

6.2

Multi-Aspect Objects

Objects may have more than one aspects which should be implemented separately. An active object, whose behavior is represented by an activity diagram, can also be a multi-state object and, therefore, need a statechart showing its multi-state behavior. The Elevator class in the example is an active but uni-state class. (Here we are using the term multi-state in its strict meaning that suggests state-transitions triggered by external events which are asynchronous, rather than internal signals which merely show the completion of some actions.) Whenever the Controller object sends a message to the Elevator object asking its convenience, the Elevator object returns its convenience as an integer value. Similarly, each time the Controller object assigns an elevator

A new method has been proposed to implement the dynamic behavior of OO system, in which objects are classied into dierent categories. To implement a multistate class of objects, an object-oriented approach has been used where each state becomes a class and each transition becomes an operation. Inheritance mechanism is used to implement OR-substates and the mechanism of object composition is used to represent ANDsubstates. Active objects are implemented as Java threads. The method deals with intra-object concurrency (within a single object) and multiple thread concurrency (among several objects). Many aspects of an object regarding its implementation and the nal class structure of a system implemented by our approach have also been discussed. In future research, we intend to change the newly proposed method into an algorithm

that can automatically convert the dynamic behavior of a system into executable code.

Harel, D., 1988, On Visual Formalisms, Communications of the ACM, Vol. 31, No. 5, pp. 514530. Harel, D. and Gery, E., 1996, Executable Object Modeling with Statecharts, Proc. 18th International Conf. on Software Engineering, IEEE, pp. 246257. Harel, D. and Naamad, A., 1996, The STATEMATE Semantics of Statecharts, ACM Transactions on Software Engineering and Methodology, Vol. 5, No. 4, pp. 293333. Jacobson, I., 1992, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison Wesley, Reading, Massachusetts. Kim, T., 1994, Object Oriented Designer, http://www.qucis.queensu.ca/Software-Engineering/ blurb/OOD.html, ftp.x.org. Object Domain Systems, Object Domain, http://www.object-domain.com/. Problem Set for the Fourth International Workshop on Software Specication and Design, Fourth International Workshop on Software Specication and Design, IEEE Computer Society, pp. ix, April, 1987. Rational Software Corporation, Rational rose, http://www.rational.com/. Rational Software Corporation, Unied modeling language (UML), http://www.rational.com/. Rumbaugh, J., 1993a, Controlling Code, Journal of Object-Oriented Programming, Vol. 6, No. 2, pp. 25 30. Rumbaugh, J., 1993b, Objects in the Twilight Zone, Journal of Object-Oriented Programming, Vol. 6, No. 3, pp. 1823. Rumbaugh, J., 1995, OMT: The Dynamic Model, Journal of Object-Oriented Programming, Vol. 7, No. 9, pp. 612. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W., 1991, Object-Oriented Modeling and Design, Prentice Hall, Eaglewood Clis, New Jersey.

ACKNOWLEDGMENTS This work has been carried out as a part of HITO project, funded by EAGL (Engineering Adventure Group Linkage) Program.

REFERENCES

Ali, J. and Tanaka, J., 1996, Automatic Code Generation from the OMT-based Dynamic Model, Proc. Second World Conf. on Integrated Design and Process Technology, Vol. 1, Austin, Texas, SDPS, pp. 407414. Ali, J. and Tanaka, J., 1997, Generating Executable Code from the Dynamic Model of OMT with Concurrency, Proc. IASTED International Conf. on Software Engineering (SE97), San Francisco, pp. 291297. Booch, G., 1991, Object Oriented Design with Applications, Benjamin/Cummings, Redwood, California. Coad, P. and Yourdon, E., 1991, Object-Oriented Analysis, Prentice Hall, Eaglewood Clis, New Jersey. Desfray, P., 1994, Object Engineering: The Fourth Dimension, Addison Wesley, Reading, Massachusetts. Excel Software, MacA&D, http://www.excelsoftware.com/index.html. Gamma, E., Helm, R., Johnson, R. and Vlissides, J., 1995, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, Reading, Massachusetts. Gosling, J., Joy, B. and Steele, G., 1996, The Java Language Specication, Addison Wesley, Reading, Massachusetts. Harada, M., Sawada, T. and Fujisawa, T., 1996, A Structured Object Modeling Method SOMM and Its Environment SOME, Systems and Computers in Japan, Vol. 27, No. 11, pp. 118, John Wiley & Sons, Inc. Harel, D., 1987, Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming, No. 8, pp. 231274.

Controller assignRequest(Floor,Direction) NoWait 10 Floor upList downList callUpElevator() callDownElevator() addToUpList() addToDownList() upGetOn() downGetOn() upRequest(this) downRequest(this) 10 upArrived(this) downArrived(this) Elevator curFloor direction button[1..10] convenience(Floor,Dir) assignRequest(Floor,Dir) findDirection() moveNext() ..... downArrived/ downGetOn upButton/callUpElevator DownWait downButton/ addToDownList Person toFloor fromFloor direction upArrived/upGetOn 3 3 upArrived/upGetOn downButton/ callDownElevator upButton/callUpElevator UpWait upButton/addToUpList

downButton/ callDownElevator

downArrived/ downGetOn

getOn(Person)

BothWait downButton/addToDownList upButton/addToUpList

Figure 3: Statechart for Floor class.

Figure 1: Object model for the elevator simulation system.

getOn(Elevator) Waiting getOff Travelling

Figure 4: Statechart for Person class.

:Person

:Floor

:Controller

:Elevator

Initialization press button call elevator assign request StopNeeded? [NO] NotifyArrival arrived get on get on open door close door move FindDirection GetOff Running MoveNeeded? [YES] [NO] OpenDoor [YES] Stop

get off MoveNext Stop running CloseDoor GetOn

Figure 2: Event trace diagram for the elevator simulation system.

SleepASecond

Figure 5: Activity diagram for Elevator class.

Floor FloorState state callUpElevator() callDownElevator() addToUpList() addToDownList() upGetOn() downGetOn()

FloorState Floor floor upButton() downButton() upArrived() downArrived() OffA

Running Car

Accelerator depressA OnA releaseA

NoWait upButton() downButton()

UpWait upButton() downButton() upArrived()

DownWait upButton() downButton() downArrived()

BothWait upButton() downButton() upArrived() downArrived() Brake depressB OffB releaseB OnB

\\ Class UpWait public void upButton(){ floor.addToUpList(); } public void downButton(){ floor.callDownElevator(); floor.state = new BothWait(); }

class RunningCar { Accelerator a = new OffA(); Brake b = new OffB(); } class Accelerator { public depressA(){} public releaseA(){} } class OffA extends Accelerator { public depressA(){a = new OnA();} } class OnA extends Accelerator { public releaseA(){a=new OffA();} } class Brake { public depressB(){} public releaseB(){} } class OffB extends Brake { public depressB(){b = new OnB();} } class OnB extends Brake { public releaseB(){b=new OffB();} } (b) Java code for implementing concurrent states.

(a) Statechart with concurrent states.

Figure 6: Class structure of the Floor class and its companion classes.

Figure 8: Concurrency in statechart.

ControllerState

Controller

PassiveUni

class Elevator extends Thread { ........... public void run(){ for (;;){ if (stopNeeded()) stop(); if (moveNeeded()){ findDirection();moveNext();} sleepASecond(); } } public void stop(){ notifyArrival(); openDoor((); getOff(); getOn(); closeDoor(); } ........... }

TempUni

ActiveUni

PassiveMulti

TempMulti

ActiveMulti

PssaiveMultiState

TempMultiState

ActiveMultiState

Figure 7: Java code for the active class Elevator.

Figure 9: The nal class structure.