MOBICHARTS: A Notation to Specify Mobile
Computing Applications
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 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.
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.
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. 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. While most of the literature deals 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
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. 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.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. 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 and exclusive OR decompositions.
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 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 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.
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 low bandwidth 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
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.
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 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 is
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 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 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 Register substate of
LocMgmt registers a mobile user upon arrival in the cell. When a user
leaves a cell, the Updatesubstate is used to delete 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.
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
• The agents collect information about the status of stock
prices from central database of stock market.
• 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
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
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 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.
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 state is meant for monitoring the state
of the device and take action accordingly. 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 computation due to the task.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.
iii) It cannot
represent Object's ambience and inheritance among ambient objects.
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
vi)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.
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 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 as follows:
(a) Migration: Every
task has to migrate from one host to another or from a host to a MSS and
viceversa at some point of time, to perform some action. Steps are:
• The frozen task at
destination is reactivated
• All messages for the task
to be migrated are stored in the corresponding message queue in the previous
host.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 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.
(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 locations are acquired,
Service takes care of
maintaining the buffers, connecting 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 to the data sources and
hoarding the information until disconnection occurs. If the hoarded items are
updated 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.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 So, the owner task removes the task entries from the
<tasklist> and continues. After the owner task receives
acknowledgement from all other tasks in the <tasklist>, then only
it continues its own operation/computing.
(f) Synchronization:
This service could be thought of as an application of read-write sharing.
Whenever, pieces of codes need to be synchronized in two or more tasks, they can
use a global variable and a predicate on that variable. The global variable 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. Mobicharts for the
synchronization service is shown in figure.
5.1 Developing
Mobicharts
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
<shared variable, tasklist>. 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.
e) Enumerate all possible locations that the object/task may go
through. 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
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 Disco
6.
Conclusion
Mobilecomputing environment is a kind of distributed computing
environment but with characteristics like mobility of systems, their limited
resources and
intermittent disconnections
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.
References
[1] Grady Booch,
"Object-Oriented Analysis and Design with Applications", Redwood City,
Benjamin Cummings, 1994
[2] Derek Coleman, Fiona
Hayes and Stephen Bear, "Introducing Objectcharts or How to Use Statecharts in
Object- Oriented Design", IEEE Transaction on Software
Engineering.
[3] Fiona Hayes & Derek
Coleman, "Coherent Models for Object Oriented
[4] Stephen Bear, Phillip
Allen, Derek Coleman & Fiona Hayes, "Graphical Specification of Object
Oriented Systems", Proceedings of ECOOP/OOPSLA'90- 37
[5] David Harel & Amnon
Naamad, "The STATEMATE Semantics of Statecharts", ACM Transaction on Software
Engineering & Methodologies, Vol.5, No.4, October 1996,
[6] Fernam Jahanian &
Aloysius K. Mok, "Modechart: A
Specification Language for
[7] Stuart Kent,
"Constraint Diagrams: Visualizing Invariants in Object Oriented Models",
Proceedings of OOPSLA'97
[8] Arthur Allen &
Dennis de Champeaux, "Extending the Statechart Formalism: Event Scheduling &
Dispositions".
[9] George Samaras,
Evaggelia Pitoura, "Computational Models for Wireless & Mobile
Environments", University of Cyprus
[10] D. Harel,
"Statecharts: A Visual Formalism for Complex Systems", Technical Report,
The Weizmann Institute of Science, Israel, July 1986
[11] Grady Booch, James
Rambaugh, Ivar Jacobson, “The Unified Modeling Language User Guid”, Low
Price Edition, Pearson Education, Inc., 1999
[12] V. Anil Kumar,
Maruthi, “Mobile Charts – A Notation for Developing Mobile Computing
Applications”, M.Tech Thesis, Department of Computer Science, University of
Hyderabad, December 2001
No comments:
Post a Comment