Mobichart for Modeling Mobile Computing Tasks

Hrushikesha Mohanty1
hmcs@uohyd.ernet.in

Satyajit Acharya1
s.acharya@ieee.org

1
Dept. of Comp. & Info. Sciences
University of Hyderabad, Hyderabad

Faculty of TCS
TIFR, Mumbai

Abstract
We discuss the specialty and the limitations found in
mobile computing environment to motivate the readers on
the necessity of having methods for developing mobile
computing application in the object oriented paradigm. It
is shown that existing specification model like
Objectchart do not model the effects due to location
awareness and other typical phenomena like hands-off
and hands-on. We have shown Mobichart can address the
drawbacks of Objectchart and can be used to model
mobile computing applications.
Keywords: Notational Specification, Objectcharts,
Mobicharts, Mobile Computing, Container, Migration,
Disconnected Operation.
1.

R.K. Shyamasundar2
shyam@tcs.tifr.res.in

INTRODUCTION
Advances in wireless communication and computing
technologies have engendered a new paradigm of
computing, called Mobile Computing, which allows
mobility of user (and his/her portable computing devices)
thereby providing anytime anywhere computing. Backed
with technological advances, this distributed computing
paradigm promises several applications. But this
paradigm is plagued with several limitations [1] found in
mobile computing environment. Moreover, in order to
take the benefit of the paradigm, a computation has to be
location aware as well as sensitive to its ambients. A task
may migrate from one mobile host to another or it can
move from one place to another along with the host that is
the ambient of the task.
Although, it is natural for designers to abstractly
visualize tasks and their ambients as objects, still
Objectcharts [2] [11] formalism that models object based
systems fails to model essential features of mobile
computing environment. In this work, through Mobichart
[3], we provide mechanisms to model applications based
on event-action architecture and to specify application
behavior in response to typical features like location
awareness, migration, cloning, disconnected operations,
hoarding. We extend the specification of an object with a

R.K. Ghosh3
rkg@cse.iitk.ernet.in
3

Dept. of CSE
IIT, Kanpur

handler called container to specify the object location

(geographical as well as physical), and also to model
inheritance of container properties by the object. We
enrich Mobichart with features for modeling the above
features, especially disconnected operations.
2.

MOBILE COMPUTING ENVIRONMENT

A mobile computing environment includes Mobile
Support Stations (MSS) and Mobile Hosts (Mhs). Each
MSS is responsible for managing a number of
authenticated mobile hosts in a geographic location called
cell. An MSS provides different services to all Mhs
residing in its cell, viz., routing information, message
forwarding to/from other MSSs, and message services for
disconnected Mhs.
A host communicates to its MSS using wireless
communication whereas MSSs are connected by static
network. A host communicates to another host of
different cell using both wireless and static networks.
Host can change their cells while remaining connected.
This environment can be used for distributed computing.
But hosts with limited resources like less battery power,
less memory, weak wireless connection and less I/O space
pose serious challenges for designers to model
applications for this environment.
3.

MOTIVATION
In spite of the above limitations, the mobile
computing environment is useful for location aware
computing/ubiquitous computing [4]. In literature it is
shown that a distributed computation needs to be
restructured [5] into lightweight (to run on hosts) and
heavyweight (to run on MSSs) computations. Again an
application should have contingency plans to adapt to the
abnormal environmental situations.
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 also change locations. We refer to this type of
computations as mobile computing tasks. Keeping
lightweight computation in view we propose to model a

task as an object that can run on a host, can migrate to

another host or can be cloned at a MSS. In order to make
an object run in mobile computing environment the object
should support the following services: (a) task/host
migration, (b) sharing of global data between different
distributed objects of different hosts, (c) synchronization
among different objects/devices, (d) support for
disconnected operations, (e) location based resource
inheritance for devices/ tasks, (f) cloning of objects, and
(g) hoarding of data/objects (to support disconnected
operation). We model object behaviors as a collection of
actions corresponding to events (like send/ receive of
events, change of location etc.). The event-action
paradigm [6] is a generic computing model [7] and object
oriented design approaches like UML [8], Statecharts [12]
[13] and Objectcharts [2] [11] can be used to model
applications in this paradigm. As these approaches do not
have mechanism to specify locations and location specific
computation issues we are motivated to extend
Objectchart to make it suitable for mobile computation.
4.

MOBICHARTS
In this section we introduce Mobichart after showing
inadequacy of Objectchart in modeling a mobile task.
A task is modeled into an object and we follow
Objectchart to show task activities. An object engaged in
computation at a host might have been originated at or
migrated to the host. At higher level, object may assume
Active/Passive/Join/Leave/ Terminated states as shown in
Task<name>
Wakeup signal
From MSS
Active/
Wakeup
Passive
State

user.kill/Finish
Active State
Monitor

Terminated

Compute

Doze/move
Migrate
Leave

Collect
information

Join

Figure 1 Objectchart of a Task inside host

figure 1. As shown in the figure, upon joining a host

device, the task assumes Join state. A task can join a
host, when the later is in Active state only. If a host is in
Passive state, it comes to Active state on receiving wakeup signal from the MSS and then receives the task that
wishes to migrate to the host. In Monitor substate a task
receives events and invokes corresponding actions. In
response to Move/Doze events tasks go to Passive state
whereas application specific actions are performed in
Active state. A task at a host may come to Terminate state
or after completing host specific task, may migrate to
some other host (located at the same cell or different cell).

A task before migration assumes Passive state after

saving the computation status. Though the Objectchart in
some extent is capable of modeling a mobile task, it has
the following limitations:
It does not model the host that contains a task
It does not model location in application i.e. location
aware computation can not be modeled with objects.
It does not model task activities (like hoarding) while
a host is in disconnected state (not possible as
location is not known).
It does not model a task on transit (while being
routed in network)
It cannot represent some of the typical services used
in mobile computing applications like cloning,
hoarding, synchronization, sharing.
4.1 MODELING A TASK USING MOBICHART
The following additional features are added to enrich
Objectcharts to overcome the inadequacies highlighted
earlier:
Dynamic inheritance of container properties of a host.
Transit State showing the movement of a task in
network or disappearance of a task from the environment
( state shown in dotted line).
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 and device) ambients of an object. Containers in
Mobicharts enable us to model the physical location of the
object by the variable Loc and the device containing the
task by Device id. Other user-defined data items that are to
be changed every time the location changes can also be
handled using the container handle variables.
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 that
contains the host.
The concept of container handle was inspired by the
ambient calculus [9]. The hierarchical view of the
containers in the system is similar to the concept of
ambients [10]. Ambients serve as containers for data,
functionality, and other ambients. But, while ambient is a
formal abstraction used to reason about mobile
computation, containers are actual entities (implementable
as a variable/handle in an object) used for representing
the location of objects.
Figure 4 (at the end) shows refinement of the active
state of an object presented using the Mobichart
notations. The specification clearly shows that the listed
inadequacies are overcome using the new features like
container in Mobichart notation. We model the location
of the task in the handler <Loc, Device id> by initializing
them to <currloc, ID>.

5.

MOBICHARTS SERVICES
All mobile objects/tasks have certain essential
functionality/services that are required for objects to
adapt to typical environment situations. The services that
can be used on demand are: Migration, Inheritance,
Hoarding, Cloning, Sharing and Synchronization. Some
of these aspects are discussed below. Details about other
services are given in [3].
(a) Migration: Every task has to migrate from one host to
another or from a host to a MSS and vice-versa at some

action Join (Newloc) takes place. In case of no

disconnection, the transition Leave and Join (Newloc)
merge into a single one. Introduction of disconnected
state helps us to model unpredictable behavior of the task.
(b) Cloning: A task may require creating a new task with
the same or a scaled down functionality. The rules
followed are:
i. The task should be in active state before cloning,
ii. The cloned task becomes a new task by joining
CurrentTask

inherit
variables;

Loc: <currloc>
Device id: <ID>

Active

Figure 2 (a) Task/Object Migration Scenario

Task<name>

inherit variables;

NewTask

inherit
variables;

Clone

Loc: <currloc>
Device id: <ID>

Frozen

Clone
Join
New
Task

Loc: <currloc>
Device id: <ID>

Frozen

Leave

Loc: <NewLoc>
Device id: <NewID>

Loc: <nil / MSS>

Active

Device id: <nil>

Transit

Figure 3 Mobichart for Cloning

Loc: <newloc>

the host and then continuing execution. Figure 3

shows the cloning service.

Device id: <NewID>

Frozen

(Newloc)

Join (Newloc);

Figure 2 (b) Mobichart for Task Migration

point of time, to perform some action as in figure 2 (a).

Steps involved are:
Task to be migrated is first 'Frozen' and then
transmitted to the destination. On transit the handlers Loc
and Device id are changed according to the situation at
hand:
i. Task in network (static/wireless), neither is at a
MSS nor at a host - Loc: <nil>, Device id: <nil>
ii. Task is at MSS and needs to migrate to a
disconnected host: Loc: <MSS>, Device id: <nil>.
The handler provides the location of the object at
hand.
iii. Task is in a disconnected host while the host is
not registered in any cell - Loc: <nil>, Device id:
<ID>.
After the end of migration a frozen task can be
reactivated at its new location/device. Mobicharts
notation for task migration service is shown in figure 2
(b). Loc is the handler for the task in frozen and Transit
state.
In case of disconnection by the source host device, a
migrating task goes to Transit state and waits for the
event reconnected. Upon reconnection, the transition
from Transit to Loc: <Newloc>-Frozen state by the

6.

MOBILE TASK EVELOPMENT PROCESS

The steps to be followed for a systematic development
of Mobicharts specification of applications are:
a) Identify objects participating in an application.
b) Analyze the granularity of objects and identify
lightweight objects for running on mobile hosts.
c) For all such tasks/objects classes, enumerate their
possible states and state transitions.
d) Specify relations that exists among objects,
locations and devices to specify location-aware
computation and resource inheritance. Each
location should have unique name to eliminate
ambiguity.
e) Find the itinerary of mobile objects
f) Specify services giving contingency plans for each
object to adapt to environmental challenges.
7.

CONCLUSION
The classical design approaches are not suitable to
model typical characteristics of mobile computing
environment viz. location awareness, migration, cloning,
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
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.
8.

REFERENCES

[1] B.R. Badrinath et al., Impact of Mobility on Distributed

Computations, ACM SIGOS Operating System Review, Vol.
27, No. 2, 1993, pp. 15 20
[2] Derek Coleman, Fiona Hayes and Stephen Bear,
"Introducing Objectcharts or How to Use Statecharts in ObjectOriented Design", IEEE Transaction on Software Engineering,
Vol.18, No 1, January 1992, pp 9-18
[3] Satyajit Acharya, Hrushikesha Mohanty, R.K.
Shyamasundar, MOBICHARTS: A Notation to Specify Mobile
Computing Applications, Proceedings of the 36th Hawaii
International Conference on System Sciences (HICSS03)
[4] Robert M. Janowiak, Computers and Communications: A
Symbiotic relationship, IEEE Computer, Vol.36, No.1, January
2003, pp. 76 79
[5] Ratan K. Ghosh, Hrushikesha Mohanty, On Restructuring
Distributed Algorithms for Mobile Computing, LNCS
Vol.2571, IWDC 2002, pp. 224 - 233

[6] S. Menon, P. Dasgupta, and R.J. LeBlanc, Asynchronous

event handling in distributed object-based systems. In Proc. the
13th Conference on Distributed Computing Systems, pp. 383-390, Pittsburgh, Pennsylvania, May 1993
[7] Jean Bacon, Ken Moody et al., Generic Support for
Distributed Applications, IEEE Computer, March 2000, pp. 68
76
[8] Grady Booch, James Rambaugh, Ivar Jacobson, The
Unified Modeling Language User Guide, Low Price Edition,
Pearson Education, Inc., 1999
[9] Luca Cardelli, Andrew D. Gordon, Mobile Ambients,
FoSSaCS98, Maurice Nivat (Editor), LNCS 1378, Springer,
1998, pp. 140 155
[10]
Luca Cardelli, Abstractions for Mobile Computation,
Secure Internet Programming: Security Issues for Distributed &
Mobile Objects, J. Vitek & C.D. Jensen (Editors), LNCS 1603,
Springer-Verlag, 1999, pp. 51 99
[11] Stephen Bear, Phillip Allen, Derek Coleman & Fiona
Hayes, "Graphical Specification of Object Oriented Systems",
Proceedings of ECOOP/OOPSLA'90, pp 28 - 37
[12] D. Harel, "Statecharts: A Visual Formalism for Complex
Systems", Technical Report, The Weizmann Institute of
Science, Israel, July 1986
[13] David Harel & Amnon Naamad, "The STATEMATE
Semantics of Statecharts", ACM Transaction on Software
Engineering & Methodologies, Vol.5, No.4, October 1996,
pp.293-333

Container Handle

Loc: <currloc>

Join Host

Device id: <Host ID>

ComputeTask_in_ActiveState

inherit: resources, properties, variables

Disconnect
Host

Disconnected
DisconnectedExecute

Connected
ExecuteTask

Use Hoarded Data

Check

Check

Not Empty
cannot
continue,
hoarded
data not
enough

CheckMsgQ

WaitForReconnection

Not Empty

CheckMsgQ
Empty, goto
passive

Reconnect
Host
Hoard
HoardData

Hoarding
Complete

receive events

Monitor Activities/Events

create actions

Figure 4 Mobichart of a Task in active state in a Mobile Host