Simulation and Testing of Mobile Computing Systems using Fujaba

Introduction:

Mobile computing is different from Distributed computing. The main

difference is due to mobility and wireless connection. Due to roaming, the devices
may change location, their computational context can change and they have limited
resources.
Wireless connections are less reliable, more prone to errors, smaller bandwidth
and more expensive. In order to support mobility, the architectural approach needs to
be adjusted in different abstract layers of modeling and specification language.

These different platforms and middleware provide different transparency levels of

context awareness to the application, where the application has to be aware of, and be
able to react to, changes in its context given by its current location, quality, cost and
types of available connections, etc. A conceptual model capturing the properties of a
certain class of mobile computing platforms would be very helpful to the application
development and the development of new mobile platforms. It would allow an
understanding of the basic mechanisms and their suitability for a certain task. With
suitable refinement and evolution support, the conceptual model can be mapped into a
concrete platform specific model.

In reality, it is difficult and expensive to test the mobility support of a certain

platform, which requires devices supporting wireless communication and specific
tools to check the coordination logic of involved hardware and software components.
Simulating the mobile platform can provide a simple and cheaper way to test the
mobility aspects of the platform. Through this means, the context aspects of the
platform like locations, network connections can be simulated directly, thus a ynamic
execution environment can be provided for the context-aware applications, which is
also difficult to test in reality.

Here, we introduce our approach for analysis, design and simulation of mobile
systems with the tool support of Fujaba. The approach is developed based on UML-
like meta models and graph transformation techniques to support sound
methodological principals, formal analysis and refinement

Modeling of mobile system:

Conceptual modeling and concrete modeling are the key parts of this approach. The
conceptual modeling of styles of mobile systems is proposed as a way of capturing the
properties of a certain class of mobile computing platforms. The conceptual model
consists of two parts: a static structural model given by UML class diagrams whose
instances represent the valid system configurations, and a dynamic behavioral model
given by transformation rules over these instances, specifying the operations of the
style. Typed graph transformation systems will provide the underlying formal model
and operational semantics. Informally, a typed graph transformation system G =
hTG,C,Ri, where TG is a type defining the architectural elements, C is a set of
constraints restricting their possible compositions, and R is a set of graph
transformation rules
Our structural model consists of meta models at different levels contained in different
packages. This allows us to separate different concerns, like software architecture,
distribution and roaming, while at the same time retaining an integrated representation
where all elements of a concrete model are presented as vertices of the same graph,
i.e., an instance of the overall meta model. Based on this uniform representation, the
different sub-models can be related by associations between elements belonging to
different submodels.

Our three-layered meta model captures these relations in the three packages
Architecture, Connectivity and Roaming to present different viewpoints of the
systems. The basic operations of the style include moveIn, moveOut, register,
deRegister, connect, disconnect and handOver. The concrete model is based on a
specific platform, e.g. Wireless CORBA. Concrete modeling of mobile system uses
the same modeling technologies as conceptual modeling of styles. Given specified
models of the platform, a prototype can be generated directly for the reference of
implementation using code generation functionality provided by graph transformation
tools like Fujaba

The relationship between these two different layer models is refinement, e.g., the
mobility and other aspects modeled in the conceptual model need to be mapped into a
concrete design. Besides this, we focus on the behavior consistency check of the two
levels i.e. the consistency check of the rules applied to the models, but not of the
structural elements.

Simulation:

We use two ways to use the simulation through Fujaba: for validating the model and
as an oracle for test the actual implementation.

Simulation for Validation

In graph transformation systems, many verification problems can be formulated as

reachability (or non-reachability) properties of a given configuration in the system. A
reachability property holds for a given graph transformation system G = hTG,C,Ri
and a start graph G0 if an instance graph that contains a certain target pattern is
reachable by applying available transformation rules. This means that a system can
evolve from the start configuration to the desired target configuration by performing
given operations. In this way we can check, for example, if a required reference
application scenario is realizable on the middleware, thus validating functional
completeness of the model.

we use the Fujaba class diagram editor to specify our meta model at first. Graph
transformation rules (or operations) are defined in the Fujaba story diagram editor
then. After generating and compiling Java code for the complete specification, we can
start Dobs to execute the models. We can create an initial object configuration typed
over the defined class diagrams. The initial object configuration represents a possible
configuration of the system, which is also a start graph G0 as defined before.
Following the defined sequence of operations that describe the application scenario,
we can then execute the sequence of operations against the start graph. For example,
we can test if the terminal-initiated handoff scenario is reachable by starting from the
initial configuration. Through this way, we can test if the pre-defined scenario is
supported by our specification, thus validate the functionality completeness of our
model.

Simulation for Testing

All software testing methods depend on the availability of an oracle, that is, some
methods for checking whether the system under test has behaved correctly on a
particular execution. Executable formal specifications can be used as test oracles to
produce the results expected for a test case. By comparing the result of a call to the
actual implementation with the result of a call to the simulation, the test oracle can be
used to check the correct execution of an operation.

We can extend the specified concrete model to a test oracle. Since the concrete model
is platform independent concerning the independency of specific programming
languages, hardware platforms and concrete implementation methods, it can be reused
as a reference to test the correctness of implementations on different platforms. As a
test driver, a standard reference application shall be required. To facilitate the
interaction between the reference application with our model (resp., the code
generated from it), we need to provide an Application Programming Interface (API)
that is consistent to the API provided by a middleware implementation. Using the
same test application as a test driver for the implementation and for the defined
model, the developers can trace errors in the execution and check the pre- and
post-conditions of operations.

Wrapper for API–Behavior Consistency

The correct refinement of abstract conceptual styles into a concrete style is important,
and the verification process is usually complicated. In order to automatize the
consistency check between the conceptual and concrete models, we develop a
Wrapper to define the refinement relationship between these two models. Both the
conceptual and the concrete model provide application programming interfaces
through the operations defined via the rules, which are named Concrete API and
Conceptual API. As an adapter between Concrete API and Conceptual API, the
wrapper encapsulates and maps the operations implemented in Concrete API to the
operations defined in Conceptual API. Providing type transformation and semantic
match, the Wrapper forwards operation calls to Conceptual API to the operation calls
to Concrete API. In this way, the application can use the more abstract interface while
the concrete operations offered by the platform remain hidden. This abstraction allows
us to port the application to a new concrete platform API by means of a new wrapper,
without changing the application itself. The wrapper can be also used to test, e.g., by
means of a reference application, if the operations provided by Concrete API and
Conceptual API are semantically compatible, therefore verifying the concrete style or
the actual platform against the requirements expressed in the conceptual style.