Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
MOBICHARTS: A Notation to Specify Mobile Computing Applications Satyajit Acharya1 Hrushikesha Mohanty1 R.K. Shyamasundar2
[email protected] [email protected] [email protected] 1 2 Dept. of Computer. & Information Sciences Faculty of Technology and Computer Science University of Hyderabad, HCU PO Tata Institute of Fundamental Research Hyderabad - 500 046 INDIA Homi Bhabha Road, Mumbai – 400 005 INDIA Abstract A standard notation, that unambiguously expresses different aspects of a system, is important to the process of software development. The expressiveness of a standard notation helps analysts and developers to describe a computing scenario or to formulate software architecture and then to communicate these decisions unambiguously to other team members. Much attention is already given to the software development methodologies and architectural descriptions. Specifically, Statecharts and state transition diagrams have been used to show the state space of a system, the events that cause state transitions and the actions that result from a state change. The paradigm shift to object-oriented programming has changed the method of system analysis and design from traditional top-down approach to bottom-up object-oriented approach. This change in approach has motivated the development of Objectcharts that depict the behavior of objects used in a system. This paper extends the notational capabilities of Objectcharts to specify the issues related to the mobile computing. We discuss the specialty and the limitations found in mobile computing to motivate the readers on the necessity of having methods for developing mobile computing applications. We have shown that while making use of all the niceties of Statecharts as well as Objectcharts, the formalism can be extended for developing mobile computing applications. First, we discuss the need for an extension of Objectchart notation by showing the limitations of Objectcharts in specifying mobile computing applications. Second, we propose an extension to Objectcharts, referred to as Mobicharts. The proposed Mobicharts can specify the important characteristics of mobile computing applications. We illustrate typical mobile computing characteristics such as migration, hoarding, cloning, synchronization, sharing and disconnected operations using Mobicharts.
Keywords: Objectcharts, Statecharts, mobile computing, Mobicharts, notational specifications, container, hoarding, migration, cloning, disconnected operations, sharing, synchronization, inheritance.
1. Introduction Having a well-defined and expressive notation is important to the process of software development. Standard notations make it possible for describing a computing scenario or developing software architecture and then unambiguously communicate these decisions to others. An expressive notation makes it possible to eliminate much of tedium of checking the consistencies and correctness of the architectural decisions of the developer by using automated tools. A notation is a vehicle for capturing the reasoning about the behavior and architecture of a system. A number of notations have been reported in literature to specify the behavior of systems, viz. [1], [2], [3], [4], [5], [6], [7], [8]. While most of the literature deal with specification of different aspects of object-oriented paradigm, there is very little work on the use of Statecharts or Objectcharts for modeling mobile computing applications. Characteristics of mobile computing environments differ from traditional ones due to various factors, like wireless communication media, limited resources of mobile devices, mobility of users from one place to another, and so on. Mobile computing applications must be aware of the characteristics of the environment, should have the capabilities to overcome the challenges of the environment, and should be able to take advantage of the mobility. We find that the notations reported in literature, such as Statecharts and Objectcharts, are not sufficient to expressively specify mobile computing applications. In [10], Harel elucidates Statecharts that can represent views of the dynamic behavior of a system in its lifetime. A Statechart is used to show the state space of a given
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
1
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
system, the events that cause a transition from one state to another, and the actions that result from a state change. In [2], Coleman et al. extended the Statechart formalism referred to as Objectcharts, that have the same features of Statecharts and some more features to model the characteristics of object-oriented systems. Objectcharts model the dynamic behavior of an object in its lifetime. In [6], Johanian et al. have used a notation called Modechart to specify real-time systems. The notation uses the Statechart's representation of large state machines, provides a semantics in terms of RTL, which deals with the absolute timing of events in a system. As compared to the traditional real-time applications, mobile computing applications have to deal with the inherent disconnection operations that occur in the environment. In this paper, we introduce a notation, called Mobicharts, for specifying mobile computing applications. Mobile computing environment, albeit a distributed computing environment, is different due to its typical features of disconnections, and limited resources of mobile host. A mobile computing application is elegant when it is designed to adapt to the location it visits. Though objects can be thought of as building blocks to model mobile computing applications, Objectchart formalism does not provide mechanisms to model the typical features of mobile computing applications. Some important mobile computing features are specifying object location, migration, inheritance, hoarding, cloning, sharing and synchronization. Currently, Objectcharts [2], do not have clean mechanisms to specify the above features. In this work, we extend the specification of an object with a handler called container. Container of an object not only specifies the object location, but also models inheritance of container properties of the object. We also enrich Mobichart to be capable of to modeling the above features. We show that using Mobicharts, users can design mobile computing applications by specifying application specific actions during the phenomena that occur in a mobile environment. Based on the proposed Mobicharts, we are developing a programming environment in order to automate the development of mobile computing applications. In addition, we are working on mobile computing application testing strategies using Mobicharts specifications. Rest of the paper is organized as follows: Section 2 gives a brief overview of Statecharts, and Objectcharts. Section 3 describes characteristics of mobile computing application development environments and system model for the same. In section 4, we illustrate some of the inadequacies of Objectcharts through a process of modeling a mobile computing application. Further, we arrive at solutions to overcome these inadequacies. In
section 5, describe in detail Mobicharts and illustrate using Mobicharts different features of mobile computing applications. In section 5.2, the application of mobile host considered earlier is specified using Mobicharts illustrating the expressive power of Mobicharts. The paper concludes with a discussion in section 6.
2. Objectcharts The life cycle behavior of an object class/system may be modeled by a Statechart. The states of a Statechart represent various stages that an object of a class (or a system) may go through. In other words, a Statechart represents a view of the dynamic model of an entire system in its lifetime. The notation proposed by David Harel [10], provides a simple yet highly expressive approach far superior to conventional flat finite state machines. Statecharts are used for the specification of reactive systems. It can also be used to model hierarchy, concurrency, and broadcast communications in a system. Two essential elements of a Statecharts are states and state transitions. A state of an object is a snapshot that depicts the features of an object, its interaction with other objects, action or waiting for other events. In other words, a state represents cumulative results of the behavior of objects. An event is some occurrence that causes the state of a system/object to change, and this change of state is called state transition. There are three types of states in a Statechart, namely: OR-states, ANDstates and basic states. The formalism is supported by the powerful programming environment STATEMATE [5]. Statechart has been successfully used in industry for the development of reactive and real-time systems [6]. Objectchart, which is an extension to Harel's Statechart, describes the state changes in a single class. Objectcharts depict states as rounded boxes, transitions as directed lines between states, and can represent AND (dotted partition of a superstate) and exclusive OR (no division of superstate) decompositions. These decompositions permit representation of both dependent and independent transitions and concurrency, as shown in figure 1. In figure 1 (a), a transition labeled 'a' changes the state of an object from state 'A' to state 'B'. It also shows an exclusive-OR situation -- the object is either in state 'A' or in state 'B'. Transition 'b' is one that can occur in state 'A' and 'B', and as such can be viewed as a transition in superstate 'Task". In figure 1(b), initial states triggered by events are shown by small arrows with no source state and the AND state is shown by a dotted line between states (as between 'E’ and 'D'). Objectcharts extend Statecharts by adding attribute information to states. It supports communication primitives that enable
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
2
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
direct communication to an object rather than the broadcast communications used in Statecharts. Transitions between states are labeled with a service of the class and/or services requested from other classes. Thus, a transition with one input would be defined simply as transition_name (in:INPUT). A configuration diagram shows the instances of Task
State
A
a
Transitio
Task D
E
B
F
b
B
(a) Exclusive-
a
b
trans1 (a:A)
C
trans2 (b, c: B)
G
dynamic in nature. A host, on entering a cell, announces its entry to the MSS of that cell. The MSS registers the mobile host after proper authentication. The MSS also provides different services to all Mhs residing in its cell, viz., routing information, message forwarding to/from other MSSs, and message queuing services in case of disconnection of Mhs. In an environment, support stations are connected by wired network while wireless network is established among a support station and the hosts residing in the cell (Fig.2). We assume that the mobile hosts communicate only with the MSS residing in that cell. Even if one mobile host wants to communicate to another mobile host, the communication will be made through MSSs of their respective cells. Thus, communication network of an environment comprises of both wired and wireless communication network.
(b) AND
Fig 1 “AND” and “Exclusive-OR” Decomposition
objects in a system and their intercommunication, thereby defining overall pattern of communication of objects in a system. It shows the interfaces for each object and defines which object request services from others. Here, objects are represented as boxes containing their instance identifiers, and classes to which they belong, solid lines represent provided services, dashed lines represent required services. A solid line joining a dashed line shows a possible inter-object communication. A total system can be represented by one configuration diagram with a set of object charts (one for each class).
3. Environment and its specifications Convergence of wireless communication and computing technologies has given rise to mobile computing. This new paradigm allows mobility of user (computing devices) thereby providing anywhere, anytime computing facilities. Mobility of user has increased the possibilities of usage in manifold as compared to distributed computing environment with static network. For example, users can get access to the Internet while on move, can get location specific data (like traffic congestion on a highway or nearest available doctor/ hospital in case of emergency or accidents) etc. A mobile computing environment includes Mobile Support Stations (MSS) and Mobile Hosts (Mhs). Each MSS is responsible for managing a number of mobile hosts in a geographic location called cells. As mobile hosts change their location frequently, some hosts enter a cell and at the same time, some other hosts may leave that cell. The number of mobile hosts present in a cell is
MSS
Wireless Cell
MSS
Fixed Network
MSS
Mobile Host
MSS
Wireless Cell
Figure 2 A Mobile Computing Environment
Mobile computing environment is constrained in many ways. Mobile units themselves are resource poor with respect to battery power, processing power, and memory. They are inherently unreliable in the sense that their network connectivity is often achieved through lowbandwidth wireless links. In addition, during movement of user (device) from one cell to another (handoff), the device is disconnected from network for unpredictable amount of time. Moreover, to save resources of the device, the users may disconnect themselves for variant periods. Difficulties raised by these constraints are compounded by mobility that induces variability in availability of both communication and computational resources. These severe restrictions have great impact in the design and implementation of mobile computing applications. This motivates the development of new notational specifications to model behavior of mobile computing applications. Application development for mobile computing environment is affected by special characteristics of the environment itself. Some of the characteristics that are important for our purpose are: • Hand-off during migration of a host from one cell to other may create disconnection and duration of such
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
3
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
disconnection could be unpredictable. Hence, an application must have some contingency plan to deal with such unwanted incidents. • Resource scarcity of mobile device may force users to make planned disconnection, since wireless transmission and reception consumes more energy than other activities. In order to continue computation in disconnected mode, applications may need to hoard some file/information (that are available in databases of fixed network/MSS) in local memory prior to disconnection. Changes made to files during disconnection period have to be consolidated with the databases after reconnection. • Environments of mobile computing applications are heterogeneous, i.e. availability of resources is not the same at all computing devices. Therefore, applications must be able to adapt themselves according to the environment and make optimal use of available resources. • When more than one mobile host want to share information/data present at fixed network, applications must be aware of the need for read/write synchronization with other mobile users. Also, when there is an update to shared data, there has to be some mechanism to inform all potential users about the update. • Task/Process/Object migration across different hosts and/or MSSs may take place in the environment. This requires that applications must be able to save the state of task prior to migration and to create a new task with a predetermined state. • A new task created by an application may have to inherit some of the properties of the host device. Since properties of all mobile hosts are not same, the inherited properties of a task may differ at different devices. When designing an application for mobile computing environment using object-oriented paradigm, we must have mechanisms to specify behavior of tasks/ processes/ objects that constitute the application. These tasks should have capabilities to handle situations that arise due to the above mentioned characteristics of mobile computing environment. They should also have capabilities to take advantage of location. Generation of events in mobile computing applications may be dependent on the location of the user (device) at that instance. This represents a higher level abstraction of the environment in which applications are executed. We next present a state model of mobile environment and present states of all essential components like MSS, MH and cell configuration that constitutes an environment. Specifying environment is useful to understand its role in execution of applications.
3.1. State Model of Environment
In this section, we shall describe the key roles that makes a mobile computing environment. We shall highlight the activities of a mobile host (MH) and a mobile support station (MSS) through typical mobile computing scenarios using Statecharts. Through this, we shall highlight the environment in which applications have to be developed and briefly explain MH, MSS as well as Cell configuration diagrams. Since, MSSs are fixed nodes without having resource scarcity, we assume that they are capable of efficiently handling the issues imposed by the mobile computing environment. For example, a MSS is capable of finding the location of a Mh after the Mh has moved to another cell, and consequently forwards any message intended for that Mh. 3.1.1. States of a Mobile Host: Here, we model the basic activities of a mobile host. One may view a mobile host in one of the following states, namely, Doze, Join, Active, and Leave. A host, on joining a cell, assumes the state Join, indicating that the host establishes communication link with the cell's MSS. After a host MH: Active State
Doze HComp
Join
HTx
HRx
Check
Leave Enter a Cell
Leave a Cell
Figure 3 Statechart of a Mobile Host
registers itself with the cell's MSS, the host can either be in Active state or Doze state based on its work agenda and external stimuli. An MSS registers a mobile host after obtaining the required information about the host, and updating the databases that keep information about all the hosts present in its cell. A host can change its state from Active to Doze and vice-versa. In Doze state, a host does not do any computation, apart from listening to some external events. In this state, the host reduces its CPU speed to conserve its battery. Active state is composed of four concurrent states/substates, namely, HTx, HRx, Hcomp and Check. In HTx and HRx states, a mobile host performs message transmission and reception respectively. Actual execution of application programs (i.e. task execution/ activities) is performed in HComp state. Hcomp state can further be divided into substates to represent computation in either connected or disconnected mode of the device. It must be noted that a
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
4
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
host can continue computation in disconnected mode. The Check state concurrently checks for the wireless connectivity to the MSS. This state helps in identifying abrupt unplanned disconnections. In case of disconnection, the Check state generates an event that changes the substates of HComp state from connected to disconnected mode. We assume that a host, before leaving a cell, assumes Doze state, and then assumes Leave state on being disconnected. The rationality behind this assumption is based upon obvious convenience in managing disconnection. As soon as a host gets disconnected, it should bring all network or cell dependent activities to an end and then reaches Doze state. We are interested in task behavior when such a state transition of host occurs. 3.1.2. States of Mobile Support Station (MSS): Some of the responsibilities of MSS are: (a) to route messages, (b) to handle wired transmission/ reception of messages to/from devices in fixed network, (c) to handle the wireless transmission/ reception of messages to/from mobile hosts in its cell, (d) to manage the buffers (Mailboxes) to store messages for a host, when the host is disconnected, (e) to keep track of the registration MSS : g
LocMgmt
MsgHandling LocateHost
R e g i st e r
3.1.3. Cell Configuration Diagram: A Cell configuration diagram represents a 'Contain-in' relation as shown. Entities shown in a cell are uniquely accessible. Usually, a mailbox is named after its host showing one-to-one correspondence.
Comm C o mmAi r
CommLa nd
MSSTx
MSSTx
MSSRx
finds the location of a host before deciding which type of communication is required. If the location of host is in the cell, then wireless communication would be used. If a host is in another cell, then LocateHost determines the host location and then forwards the message to corresponding MSS. In this case, the MSS would use wired communication. Two types of associated communications viz. wireless and wired, are performed in states CommAir and CommLand respectively. These two states are concurrent substates of the state Comm. Again each of these two substates, CommAir and CommLand, are composed of two concurrent substates MSSTx and MSSRx, to concurrently transmit and receive the messages simultaneously. The MSS: Register substate of MH: Mbox: LocMgmt registers a Task: mobile user upon arrival in the cell. When a user leaves a cell, the Update Fig. 5 Cell Configuration substate is used to delete Diagram the information about that user. If there is a message for a host after it leaves the cell then the message is directed to the host’s new location. It must be noted that MSS, in addition to work as a base station can participate in execution of an application. Particularly, here it is assumed that MSS stores messages for disconnected hosts and delivers message on reconnection of hosts, and provides ambiences to cloned tasks.
Up d a t e
MSSRx
g’
Figure 4 Statechart of a MSS
information of incoming and outgoing hosts in the cell and (f) to forward any message to the host after it has moved. These responsibilities/ tasks can be grouped into two broad categories: location management and message handling. Let these activities be called LocMgmt and MsgHandling. The message handling again consists of locating mobile hosts LocateHost and Comm. The MSS
4. An Example Scenario Here, we present an application that uses mobile agents on a wireless network. We also attempt to model the application using Objectchart to identify its inadequacies. A mobile computing application can be modeled by a set of interoperable objects located in different mobile hosts collaborating by passing messages among themselves. Consider a stock market broker, who has a mobile computing device. The broker has many shareholders as his business clients. The broker's businesses is to send current information about stock prices to shareholders and then get feedback from them regarding their decisions to purchase or sell shares. Some of the shareholders may have mobile devices and some others have PCs connected to a fixed network. We are
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
5
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
interested in those having mobile devices. The stockbroker uses his mobile device to engage software agents for following purposes: • The agents collect information about the status of stock prices from central database of stock market (we assume that the database reside on a MSS). • The agents send the collected information to shareholders and then visit each of them to get their individual decisions regarding purchase/selling of shares. • After collecting this information from shareholders, the agents come back to the broker and the broker uses this information for actual selling/purchase of shares on behalf of his customers. This example presents various aspects of mobility as described below: a) While in search for shareholders on the network, the software agents may find the shareholder's device in disconnected mode. b) While an agent complete its tasks in a shareholder's device, may find the device to be disconnected from the rest of the world c) When an agent visits several shareholder’s devices in sequence, to collect the information from each of them, it may not be possible for the agent to complete the task in stipulated time. This is possible, because, an agent doing its work in a mobile device may find the device to be in disconnected mode. So, the agent cannot move forward to other shareholder until the device is reconnected. d) When an agent, after collecting information from shareholders, wants to return to the broker, it may find the broker's device to be in disconnected mode. The agents may clone themselves at different situations to increase parallelism of work done at different places. For example, in situation (a) above, when the software agent inquires the MSS about all hosts present in the MSS's cell, it may find some devices to be in active state and some others in disconnected state. In this situation, the agent clones itself (i.e. make a replica of itself) on the MSS, delegating the task of information collection from mobile hosts in that cell to the cloned agent/task. Then, the original agent moves forward in quest of finding other potential shareholders at different MSS. In scenario (b), an agent doing its task of information collection may inquire the device of any planned disconnection in the device's schedule. If the agent cannot complete its task before the disconnection, the agent may clone itself and move on to other hosts. The cloned agent would take care of information collection from user, and wait for the host to get reconnected. As soon as the device reconnects, the cloned agent would return to the broker with the collected information.
The scenario (c) can be taken care of again by cloning to increase the parallelism of computation at the MSS level or at the mobile device level. In case (d), when an agents returns to the broker's MSS, and finds that the broker's device is disconnected, the agents have to wait in the MSS until the broker reconnects again. Since, the same replica of the stock prices information is being circulated to all mobile clients, this can be thought of as shared data. The shared data resides on the MSS of the stock market and the MSS keeps a list of all the devices that are going to share the data. The software agent from the broker can provide this information to the MSS. Whenever there is some minor update on shared data, the MSS's responsibility is to propagate the updates to all devices that are sharing the data. Sometimes, shareholders keep history profile information about their past decisions on transactions and these information are stored in the MSS of the shareholders. When a software agent migrate itself to a client’s device, and the client has profile information stored in the MSS, and the device is scheduled for a disconnection, the agent may ask the device to hoard the profile information from the MSS to local memory. This hoarded information would be useful for the shareholder and computation can continue in spite of disconnection. From this application scenario, we can see that, the applications in mobile environment are similar to conventional distributed application in the following aspects: • They all have a set of states • They generate and respond to events The differences of the mobile application from traditional one exist due to the mobility, and this prevents specifying mobile applications using conventional tools like Statecharts or Objectcharts. The differences are: • The responses to events are not predictable • Location based operations i.e. tasks are sensitive to the computing ambience • Disconnection management to make contingency plans for resilient computing during disconnection i.e. to cope with disconnection.
4.1. Modeling the Example by Objectcharts In figure 6, we give the object chart for the task of agent in a mobile host described in previous section. In this figure, we assume that upon joining a host device, the task assumes Join state. A task can join a host, when it is in Active state only. If a host is in Passive state, it comes to Active state on receiving wake-up signal from the MSS and then receives the task that wishes to join/migrate to the host. The Monitor substate of Active
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
6
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
state is meant for monitoring the state of the device and take action accordingly. For example, if a device goes to doze mode, the task should save its state and go to Passive state. In addition, if the task on the client is over, it has to migrate itself to another host. In our application scenario, if the software agent has collected the information required from one shareholder, the agent moves to another host. Before migrating itself, the task will go to Passive state and save the computation. In this state, a task polls messages that are pending for the task on host message queue. If the message queue for the task is empty, the task moves from Passive state to Leave state. The Compute substate of Active state specifies Agent T ask Wakeup signal From MSS Active/ Wakeup P as s ive State
user.kill/Finish
Ac t i v e S t a t e Monitor
T e rminate d
Compute
doze/move Migrate Le ave
Collect information
Join
Figure 6 Objectchart of Agent Task inside host
computation due to the task (i.e. collecting shareholders decisions regarding sale/purchase of shares). The substate Compute can further be refined to specify/model the computational details of the task. The detailed model can show how the agent performs the task, what all variables are changed after the information from one shareholder has been obtained, and so on. The object chart shows the sequence of state transitions required for the agent tasks to interface with the computing environment. Here, we observe that, the state transition from Active state to Passive state is ambiguous. The same transition is followed from Active state with two different events 'doze' / 'move' or 'migrate', with the final state being Passive state. In addition, we observe that the Objectchart is inadequate to represent the following: i) It cannot represent location based state transition e.g. based on location of the agent at a particular place, say near stock exchange, the agent could take specific action. ii) It cannot represent the unpredictable nature of state transitions of a task, e.g. ambiguous state transition from Active state to Passive state as indicated above.
iii) It cannot represent Object's ambience and inheritance among ambient objects, e.g. an object/task, after joining a host may inherit certain properties of the host device like the host's name, buffers available and the like. These inherited informations may be useful for the task for its computing purpose, such as checking out host's name from a list of shareholders to visit to collect information. As soon as the object migrates to another device, these inherited attributes must be disinherited and new attribute values must be inherited at the new location. iv) It may be noted here that the Leave state of the task is not a terminated state i.e. the task has not finished its execution. Rather, this state may be seen as a Frozen state, in which a task can sail through network in dormant mode to resume its active execution elsewhere. This behavior of task is known as Task Migration and during this process, state of the task is preserved. Objectchart specifications do not explicitly specify these characteristics of task. v) Another feature of the scenario application is that, in the Active Compute state, a task can clone itself at the device and then migrate to another device through the network. The cloning decisions may be dependent on various factors e.g. in case of a planned disconnection, an agent may clone itself and then migrate to another host. This form of behavior of a task cannot be easily captured by Objectcharts. vi) Taking the case of sharing data by different hosts, in our scenario application, we can view the stock market price information from central stock market database to be shared among different shareholders. Whenever there is change in prices in central database, the change should be reflected back to all shared copies. During this update, it may so happen that some of the devices are disconnected. Therefore, the update operation should try to access disconnected device until the client reconnects. A task, having the responsibility of updating the shared data by communicating the changes to all sharing devices, cannot predict when the update operation would be over. So, the behavior of such tasks depends on behavior of some other mobile devices on the network. This behavior of task cannot be captured by Objectcharts. vii) In our example scenario, the history profile of a client about his purchase/sale decisions might be stored on the MSS database. This information would be useful for the shareholder to act upon current decisions. So, when an agent, after joining the shareholder's device, foresees a near-future planned disconnection, can instruct the device to hoard the profile in the local memory. After disconnection, the hoarded profile would be useful for the shareholder and may be updated with latest decisions of the shareholder. Upon reconnection, the updated file has
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
7
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
to be reconciled at the MSS database. Objectcharts cannot explicitly depict these types of hoarding activities. In the following, we propose Mobicharts that overcomes some of the above drawbacks of Objectcharts.
5. Mobicharts In this section, we extend Objectcharts to support the design and development of mobile computing applications. We describe a set of services to ease the process of mobile computing application design and development. Further, the following additional features are added to enrich Objectcharts to overcome the inadequacies highlighted earlier: • A disconnected state: A special state designated as 'Disconnected', and drawn in dotted lines, is inserted between every two states, between which the objects/task can be disconnected. This state handles all messages destined for the object during disconnected state, by maintaining a message queue in the 'container' and storing all messages in it until the object again enters the Connected state. • Container (handle): Each state of an object is associated with the operating environment called its container. The container (handle) is used to represent the location of an object. Containers in Mobicharts enable us to model the location of the object. Other user-defined data items that are to be changed every time the location changes can also be handled using the container handle
Figure 7(a) Task/Object Migration Scenario AgentTask Currloc Frozen
NewLoc Frozen
inherit variables; Leave
Currloc Disconnected Join (Newloc);
Figure 7(b) Mobichart Notation for task migration
by incorporating them in the container. In conventional Objectcharts, we can only model states of an object. Here, we are able to model states of an object at a particular
location. It also models the inheritance of container properties by the object. So, a container for task/object could be a mobile host or it could be a MSS or container for mobile host could be the MSS of the cell in which the host resides. All mobile objects/tasks have certain essential functionality/services that are required for implementing other features of the application. The services that can be used on demand are: (a) Figure 8 Inheritance Scenario Migration, (b) Inheritance, (c) Hoarding, (d) Cloning, (e) Sharing and (f) Synchronization. These aspects are discussed below. (a) Migration: Every task has to migrate from one host to another or from a Fig 9(a) Hoarding Scenario host to a MSS and viceversa at some point of time, to perform some action. Steps involved are: • Task to be migrated is first 'Frozen' and then transmitted to the destination. • The frozen task at destination is reactivated there. • All messages for the task to be migrated are stored in the corresponding message queue in the previous host (from which the task has migrated). Mobicharts notation for task migration is shown in figure 7 (b). Currloc is the handler for the task in frozen and disconnected state. The handler provides the location of the object on hand. The state Disconnected with the Currloc shows that the object in migration is not able to migrate due to disconnection of the host. If there is a disconnection by the source host device, then the task goes to the Disconnected state and waits for the event reconnected. Upon reconnection, the transition from Disconnected to Newloc-Frozen state by the action Join (Newloc) takes place. In case there is no disconnection of the device, then the transition Leave and Join (Newloc) merge into a single one. The introduction of disconnected state helps us to model the unpredictable behavior of the task. (b) Inheritance: When an object joins a new container, all variables qualified with the keyword inherit in the object are automatically updated with values of corresponding variables in the container.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
8
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
Figure 10 (a) Cloning Scenario Age nt T ask
inherit variables;
Currloc
NewTask
inherit variable;s
Currloc
Active
Clone
Frozen Clone
Join (Newloc) Newloc
New Task
Active
Figure 10 (b) Mobichart for Cloning
(c) Hoarding: To continue computation, a task in disconnected state, may require some data stored in a place other than the device where the task is executing. Thus, prior to disconnection, the data could be fetched and stored in local buffer for later usage during disconnection. This hoarding of information may require the user to specify the items to be hoarded and the sources from where they have to be fetched (usually the MSS). In addition, the task on hand or the application may specify the items to be hoarded. Once this information regarding hoarding data and their Fig 11(a) Sharing Scenario locations are acquired, the Agent Task
shared variables with variable update
during disconnection, reconciliation of data is performed by this service whenever it is necessary, like upon reconnection or on specific request by the task. (d) Cloning: A task may require creating a new task with the same functionality or a scaled down task. Cloning is used to make an exact replica of an executing task. The rules followed are: (a) the task should be in active state before cloning, (b) The cloned task becomes a new task by joining the host and then continuing execution, and (c) A cloned task could be a downsized task. (e) Sharing: Sharing and synchronization are for cooperating tasks, which execute concurrently. When a task wants to share some variables with other tasks, it declares the variables as shared, and this task is known as the owner task of these variables. Other tasks wishing to use the variable register themselves with owner task and maintain a copy of the variables (to reduce communication overheads). Whenever a shared variable is updated in the owner task, messages are passed by the owner task to all registered tasks accessing the shared data. Tasks are allowed for read-only access of the shared variables present in the owner task. The Mobicharts notation is shown in figure 11 (b). Here, after sending update messages to the , the owner task waits to receive acknowledgements from other tasks. If timeout of message occurs, the message is sent again. This is continued either for a predetermined number of times or for a predetermined amount of time (according to the design criteria of the application). If no AgentTask
Compute
Hoard
hoard variables; host.reconnect
Host disconnects Hoard
Done Reconcile
Send Updates Figure 9(b) Mobichart for Hoarding sent.msgs( )
msg.timeout Wait
recv.ack_all Compute/Continue Figure 11(b) Mobichart for Sharing
service takes care of maintaining the buffers, connecting to the data sources and hoarding the information until disconnection occurs. If the hoarded items are updated
acknowledgement is received from (some of) other tasks, they are assumed to be either disconnected state or are no longer existing (they may have finished their computation by the time the update of shared data occurred). So, the owner task removes the task entries (for those non-responding tasks) from the and continues. After the owner task receives acknowledgement from all other tasks in the , then only it continues its own operation/computing.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
9
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
(f) Synchronization: This service could be thought of as an application of read-write sharing. Whenever, pieces of codes (methods) need to be synchronized in two or more tasks, they can use a global variable and a predicate on that variable. The global variable (that acts like a semaphore) is kept globally on the MSS to reduce communication overhead. This global variable is taken care of by this synchronization service. The predicate on global variable is used as the execution condition for the method that require synchronization. If the predicate on global variable evaluates to true, then the method is executed; other wise, the task continues to apply the predicate on the global variable. Here, the global variable acts like a read-write lock. A task that acquires the lock can execute the method and after the method's execution, the lock is released for other tasks. Mobicharts for the synchronization service is shown in figure 12.
5.1 Developing Mobicharts
5.2. Mobichart Specification of a Task Here we give the detailed mobichart specification of the Compute substate of the Active state (cf. figure 6) of a task in a host. In this state, a task has two more substate, namely, Connected and Disconnected. In Disconnected substate, a task may continue to execute independently using the hoarded information in the state DisconnectedExecute’. In the Connected state, there are two concurrent executions, one for executing the task and the other for hoarding of information. The Mobicharts specification is shown in figure 13.
6. Conclusion Mobile computing environment is a kind of distributed computing environment but with some special AgentTask
Here, we describe the steps to be followed for a systematic development of Mobicharts specification of applications: a) Enumerate the tasks to be performed by application. Identify the tasks/objects that might be using services like migration, hoarding etc. Identify the hoarding information that might be used while application executes. Identify potential methods of tasks/objects that might need synchronization. Also find out potential variables that may be shared by different objects and make list of all tuples . Enumerate inherited variables of the objects or tasks. b) For all major tasks/objects classes, enumerate their possible states and state transitions. Also, find the type of services these tasks offer and the services they may require from other tasks/objects. c) For conventional state transitions, use Objectchart notation to depict the behavior. d) Within a location transition, there is a possibility of disconnection. Between such states of tasks/objects, insert/introduce another state Disconnected. e) Enumerate all possible locations that the object/task may go through (each location should have unique name to eliminate ambiguity). For each state of an object, mention the location with the help of container handler. f) For each object/task in application, associate a message queue at all location they may visit in their lifetime. g) With respect to state transitions that require the services offered by Mobicharts, use Mobicharts notation to describe the state transition services.
sync method based on predicate on global variable
Compute / evaluate Predicate
predicate_true (variable) Acquire lock
fail_acquire release lock
lock_acquired Run (Method)
Figure 12 Mobichart for Synchronization
characteristics like mobility of systems, their limited resources and intermittent disconnections in network due to environmental vagaries. A mobile computing application can be modeled by a set of interoperable objects located in different mobile hosts and collaborate by passing messages among themselves. While objects may move to different hosts, hosts can change locations (cells). A simple mobile computing application can be thought of as a collection of actions corresponding to events (like send/receive of events, change of location etc.). The event-action paradigm [1] is a generic computing model and object oriented design approaches like UML [11] and Objectcharts [2] can be used to model applications in this paradigm. As discussed in section 4, these classical design approaches are not suitable to model typical characteristics viz. location awareness, migration, hoarding, synchronization, cloning, sharing and disconnection management. In the proposed Mobicharts– an extension of Objectchart – has visual specifications to model these characteristics. Hence, an application designer not only can use Mobicharts to
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
10
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
specify state changes of objects participating in this application but also can model system behaviors during the phenomena that are special to this computing environment. Based on the proposed Mobicharts, we are developing a programming environment in order to automate the mobile computing application development process. In addition, we propose to develop a mobile computing application testing strategies using specifications made in Mobicharts. Currloc
[4] Stephen Bear, Phillip Allen, Derek Coleman & Fiona Hayes, "Graphical Specification of Object Oriented Systems", Proceedings of ECOOP/OOPSLA'90, pp 28 - 37 [5] David Harel & Amnon Naamad, "The STATEMATE Semantics of Statecharts", ACM Transaction on Software Engineering & Methodologies, Vol.5, No.4, October 1996, pp.293-333 [6] Fernam Jahanian & Aloysius K. Mok, "Modechart: A Specification Language for Real-time Systems", IEEE Transaction on Software Engineering, Vol. 20, No 12, December 1994, pp. 933 - 947 Join
Container Handle
ComputeTask_in_ActiveState Disconnected
Reconnect Host
DisconnectedExecute
Connected ExecuteTask
Use Hoarded Data Check CheckMsgQ
cannot continue, hoarded data not enough WaitForReconnection
Reconnect
Check
Not Empty
Not Empty
CheckMsgQ Empty, goto passive Disconnect Host
Hoard HoardData Hoarding Complete
Figure 13 The Mobichart Specification of a Task in a Mobile Host [7] Stuart Kent, "Constraint Diagrams: Visualizing Invariants in 7. Acknowledgements Object Oriented Models", Proceedings of OOPSLA'97, pp. 327341 One of the authors (R.K. Shyamasundar) was partially [8] Arthur Allen & Dennis de Champeaux, "Extending the supported by Motorola under the University Partnership Statechart Formalism: Event Scheduling & Dispositions", in Research (UPR) programme. We would like to thank Proceedings of ACM OOPSLA'95, pp. 1 - 16 all reviewers of HICCS for their comments and valuable [9] George Samaras, Evaggelia Pitoura, "Computational suggestions. We would also like to thank Mr. V. Anil Models for Wireless & Mobile Environments", Technical Kumar & Mr. Maruthi for their help in formulating Report TR-1998-4, Dept. of Computer Science, University of Cyprus concept at the early stage of this work [12]. [10] D. Harel, "Statecharts: A Visual Formalism for Complex Systems", Technical Report, The Weizmann Institute of 8. References Science, Israel, July 1986 [11] Grady Booch, James Rambaugh, Ivar Jacobson, “The [1] Grady Booch, "Object-Oriented Analysis and Design with Unified Modeling Language User Guid”, Low Price Edition, Applications", 2nd Ed., Redwood City, Benjamin Cummings, Pearson Education, Inc., 1999 1994 [12] V. Anil Kumar, Maruthi, “Mobile Charts – A Notation for [2] Derek Coleman, Fiona Hayes and Stephen Bear, Developing Mobile Computing Applications”, M.Tech Thesis, "Introducing Objectcharts or How to Use Statecharts in ObjectDepartment of Computer Science, University of Hyderabad, Oriented Design", IEEE Transaction on Software Engineering, December 2001 Vol.18, No 1, January 1992, pp 9-18 [3] Fiona Hayes & Derek Coleman, "Coherent Models for Object Oriented Analysis", Proceedings of ACM, OOPSLA'91, pp.171-183
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
11
