Specifying a Mobile Computing Infrastructure and Services Satyajit Acharya1,, , Chris George2 , and Hrushikesha Mohanty1 1
Department of CIS, University of Hyderabad, Hyderabad - 500046, India
[email protected],
[email protected] 2 UNU/IIST, P.O. Box. 3058, Macao SAR, China
[email protected]
Abstract. We present a model of a mobile computing application environment and its formal specification using the RAISE specification language. Special care is taken to specify the location based operations that are typical of mobile computing. In the process of specifying the mobile environment, we give precise semantics to different services identified with Mobichart notations, an extension to Objectcharts and Statecharts to make them suitable for graphical specification of mobile computing environment and applications. Thus we show the usability of both graphical and formal specification methods in development of mobile computing applications. We also discuss different techniques applied to detect faults and gain confidence in the correctness of the specification using consistency and confidence conditions, prototyping and testing. Keywords: Mobile Computing, Specification, Mobicharts, Testing, RSL
1
Introduction
Mobile computing (henceforth MC) is a new paradigm characterized by the ability of computers to change location while still able to communicate with one another. Because of movement, frequent disconnections, power limitations, bandwidth restrictions, and limited local resources; MC represents a major point of departure from the traditional distributed computing paradigm and existing methods for distributed computing, including client/server computing, are not suitable to handle the typical issues (or challenges) raised by the MC environment [1, 2]. The challenges raised by the (independent) mobility of devices and applications in MC environment requires a rethinking of the classical distributed systems design techniques and these techniques need to be extended taking into
Part of this work was carried out while the author was a visiting fellow at United Nations University, International Institute for Software Technology (UNU/IIST), Macao SAR, China. The author is supported by the CSIR SRF Fellowship under the grant number 9/414(587)/2k3/EMR-I.
R.K. Ghosh and H. Mohanty (Eds.): ICDCIT 2004, LNCS 3347, pp. 244–254, 2004. c Springer-Verlag Berlin Heidelberg 2004
Specifying a Mobile Computing Infrastructure and Services
245
account these new challenges. Design of an application has to be sensitized so that it copes up to these challenges and generic solutions should be available (with the infrastructure as services) to the developer for developing applications that can have seamless execution and consistent behavior. In [3], we investigated the application of statecharts [4, 5] and objectcharts [6] to MC environments to find the insufficiency of these formalisms to expressively model MC applications. We extended the Objectchart notation to make it suitable for specifying typical features of MC environment and named it as Mobicharts [3, 7]. The Mobichart notation is capable of modelling generic services (called Mobichart services) like specifying object location, migration, hoarding, cloning, and disconnected operations. Its graphical specification style is intuitive for designers to comprehensively view the behavior of MC applications. But the notation, being graphical, does not provide precise semantics. Also, since execution of applications using the Mobichart services depends on the environment and its infrastructure, specifying these services in detail using Mobichart becomes cumbersome. That is why we have resorted to formal methods for expressing these services in detail. Having precise semantics of the Mobichart services is useful to reason about their validity, correctness and other characteristics. Once validated, application designers can make use of these services in building applications. Since specifying the environment is useful to understand its role in the execution of applications, in this paper, we present a model of an MC environment and its formal specification using the RAISE Specification Language (RSL)[8], a formal, modular, and typed specification language suitable for development of large and complex software systems. In order to avoid errors in a later stages of system development, it is important to identify and specify the consistency conditions (henceforth CCs) during the initial stages. We discuss the importance of CCs and how these CCs help in finding logical errors in the specification. To gain confidence on the correctness of specification, we adopted techniques like manual inspection of the confidence conditions generated by an automatic tool provided by RSL [9] and testing the executable specification of a prototype by using test cases. Due to limitation of space, we only give a skeletal structure of the specification and discuss the observations made during testing. Readers may refer to [10] (available at [11]) for the detailed specification and discussions on testing methods. In Section 2, after a brief on the entities involved in an MC environment and the characteristics of applications in this environment, a model of the environment and its RSL specification is given. A brief summary of the Mobichart notation with an example is presented in Section 3. Here, some remarks on the overall RSL specification of the environment and the Mobichart services are also provided. Section 4 describes different techniques we used to gain confidence on the correctness of the specification. The paper concludes with Section 5.
246
2
S. Acharya, C. George, and H. Mohanty
Modelling MC Environment
The class diagram that depicts the structure of an MC environment is given in Fig. 1. The environment includes Mobile Support Stations (MSSs) and Mobile Hosts (MHs). Each MSS is responsible for managing a number of MHs in a geographic location called a cell. A set of MHs may be present in an MSS’s cell. Such an association is given by the link ‘Has residing MHs’. In a system, each MSS acts as the Base MSS for a number of MHs and each MH has one MSS as its Base MSS. This is represented in the diagram as a link ‘Has MHs as Base’. An MSS is responsible for the authentication information for all the MHs for which it acts as the Base MSS.
Fig. 1. Class Diagram for MC Environment Specifications
Class System consists of all the MHs and MSSs in the system. The system is modelled as a record type System given below. The subtype Sys is defined with the auxiliary function consistent to ensure the well-formedness of the system by specifying certain consistency conditions. type System :: msss : M.MSSs ↔ change mss mhs : H.Mhs ↔ change mh task : TS.TASKs ↔ change task res : RS.Resource ↔ change res, Sys = {| s : System • consistent(s) |} Here, msss, mhs and task represent all the MSSs, MHs and tasks present in the system. Some of these tasks may be running in the MSSs and some others in the MHs. Also, some of them may be in the ‘Transit’ state [3, 7] and hence do not belong to any MH nor to any MSS but are present in the network (being routed to its destination during migration). This is represented in Fig. 1 as a link between TASK and System. res represents all resources present in the system, i.e. the collection of every resource located at different devices
Specifying a Mobile Computing Infrastructure and Services
247
(MSSs and MHs) in the system. The Class Mobile Host consists of a number of tasks and resources. The attributes of the class represents different components of an MH, as given below. Here, device represents the device identifier for an MH and baseMSSid represents the MSS that acts as the Base station for the MH. is active represents the state of an MH. When active, an MH is running some tasks. When the MH does not have any task to run, it goes to ‘doze’ mode (‘is active’ is false) to save its battery. The fields tasks and resources represent the set of running tasks and the set of resources present in an MH, respectively. type MHost :: device : Dev id self : MH id baseMSSid : MSS id is active : Bool ↔ changeStatus location : MH loc ↔ changeLoc tasks : TSK.TASKs ↔ changeTasks resources : R.Resource ↔ changeRes The field location gives the current physical (geographic) location of an MH. It is of variant type MH loc i.e. MH loc == nilL | mhloc(l : Location). An MH can either be connected to an MSS or it is disconnected. When connected, an MH belongs to the cell for which the MSS is responsible and its location is determined (or inherited) from the location value of the MSS. When disconnected, the location of an MH can not be determined and hence its location is nilL. Items location and device serve as the values for the container handle variables of the Mobichart notation [3, 7]. Class TASK is the aggregation of classes Hoard, Requirement and Assignment. Class Hoard represents the items to be hoarded by a task and the locations from where these items have to be hoarded. A task may require different kinds of resources to do its computation and this is modelled by the class Requirement. Also, a task may have been assigned a number of resources (possibly from different devices/locations) and this is represented by Assignment. type Task info :: taskReqment : RB.RBag ↔ changeReqments assigned : ASIGN.R assign ↔ changeAssigned hoardList : HL.Hoard ↔ changeHrdList is transit : Bool ↔ changeStatus is active : Bool ↔ changeActive Class Resource represents a resource in the system and is specified below.
248
S. Acharya, C. George, and H. Mohanty
type R info :: kind : R kind ↔ changeKind resVal : R val ↔ changeVal loc : R loc ↔ changeLoc users : T id-set ↔ change users is hoarded : Bool ↔ hoardStatus Here, kind represents the kind of a resource. A resource can be of different kinds viz. R kind == prn | cpu | mem | db | buf | var | file. resVal stores the state information of a resource, e.g. files, variables, databases and buffers may have values which can be updated. loc represents the resource location (an MH or an MSS). Each resource may have some tasks as its users. If the resource is not sharable, then at most one task can use it, else, a set of tasks can share the resource. Since a resource can be shared by a number of tasks and a task can use multiple resources, we have shown in Fig. 1, the many-many link between TASK and Resource.
3
Formal Specification of Mobichart Services
Mobicharts have extended Objectcharts with the following additions [7, 10]: Container (Handle): Each state of a task is associated with its operating environment called its container. It is used to represent the (location and device) ambients of a task. Containers in Mobicharts enable us to model the physical location of a task by the variable Loc and the device containing the task by Device id. Thus, containers in Mobicharts enable us to model the states of a task at a particular location. Transit State: A special state designated as transit (drawn in dotted lines), is inserted between every two states, between which a task can be disconnected. In this state, a task belongs neither to any MH nor any MSS, but it is being routed on the network to its destination during migration. Inheritance: When a task joins a new container, all variables qualified with the keyword inherit in the task are automatically updated with values of corresponding variables in the container. There is a requirement on a system that there is a collection of inheritable variables that must be defined for all devices and only such variables can be qualified by inherit. Apart from these extensions, different services like migration, cloning, hoarding, sharing have been identified as essential services that are required by the tasks to adapt to typical environmental situations [3]. We take the migration service as an example and explain its descriptive semantics. Task migration across different hosts and/or MSSs may take place to perform some action in the environment. This requires that a task must be able to save its state prior to migration, and resurrect as a new task with a predetermined state at a new location. The migration behavior of a mobile task
Specifying a Mobile Computing Infrastructure and Services
249
Fig. 2. Migration Behavior of a Mobile Task
is depicted in Fig. 2. In ‘Active’ state, a task in a device does its computations using local resources from the device and/or remote resources from the network. Before a task migrates, the resources that are used by it are released and the task is ‘Frozen’ by saving its state. Then it is transmitted to the destination by taking the transition ‘Leave’. During migration, a task is in ‘Transit’ state which represents a task in transition from its source device to a destination device. During this transition, it may be necessary to route a task through different MSSs in the network. When a task is being moved from one device to another, the Loc variable in its container handle is . And, when a task is at an intermediate MSS (enroute to its destination) of the fixed network, the Loc variable assumes the identity of this MSS. When a task arrives at its destination, the transition ‘Join(Newloc)’ is taken. Upon joining the new location, a task goes to ‘Frozen’ state and updates the variables in the container by inheriting the corresponding values from the new device. As shown in the figure, the container after migration has been changed to (Loc:, Device id:). Apart from automatic inheritance of the values of container variables, values of other user defined variables qualified with the keyword ‘inherit’ are inherited by their corresponding values from the new device. After the end of migration, a frozen task can be reactivated at its new location and the required resources may be acquired from the new device. Service related activities are modelled in terms of events and actions that can be pictorially shown in a Mobichart. With respect to a service, Mobichart shows events, corresponding states and their transitions. For example, consider the transition ‘Leave’ in Fig. 2. If a task is running in an MSS, this transition causes the task to go from the ‘Frozen’ state to the ‘Transit’ state. In ‘Transit’ state, a task does not hold or use any resources from the host device. So, before a task goes to ‘Transit’ state, all resources assigned to the task from the MSS are released from the task’s assignment and the corresponding resources at the
250
S. Acharya, C. George, and H. Mohanty
MSS are updated by removing the task entries in their users field. These actions (related to the transition ‘Leave’ from an MSS) can be specified by a function (e.g. taskLeaveMSS below). Note that when a task is running in an MH, the actions related to transition ‘Leave’ are different from those mentioned above. This is because, a task may have hoarded some resources when running in an MH but not when running in an MSS. Hence, depending on the current location of a task (an MH or an MSS), the transition ‘Leave’ does its actions accordingly. So, we first find the location of a task in the system (using observer getTaskLoc). If the task is present in an MH, taskLeaveMH is used to specify the corresponding actions and if the task is present in an MSS, taskLeaveMSS is used. When a task (in ‘Transit’ state) arrives at its destination after the migration, it joins the device by using the transition ‘Join(Newloc)’. Here, Newloc determines the destination of the task (either an MH or an MSS). ∼
taskleave : T id × Sys → Sys taskleave(t, sys) ≡ let tskLoc = getTaskLoc(t, sys) in case tskLoc of mh loc(mh) → taskLeaveMH(t, mh, sys), mss loc(ms) → taskLeaveMSS(t, ms, sys) end /∗ CASE ∗/ end /∗ let ∗/ pre t ∈ task(sys) ∧ ∼ TS.is in transit(t, task(sys)), We give few remarks about the overall specification for the MC environment and the Mobichart services. A total of 13 modules were written. These modules contained a total of 210 functions (97 generators, 68 observers and 45 functions representing the CCs). The total size of the specification was approx. 3200 lines (including comments, around 20%). For specifying the Mobichart services, we used 16 functions to represent different states (6 functions) and transitions (10 functions) between these states. The CCs found at various levels of the specification helped us to detect some potential conceptual errors.
4
Ensuring the Correctness of Specification
There are various ways by which one can gain confidence on the correctness of specifications viz. validation, verification and formal proof. It is also possible to use formal methods without formal proof, and such use of formal method is sometimes called “lightweight” [8]. We adopted this approach and used various techniques (like specification inspection, prototyping and testing) to increase the confidence in the specification as explained below. 4.1
Consistency Conditions
Consistency refers to situations where specification of a system contains no internal (logical) contradictions. There is a useful slogan, ”No Loss, No Confusion”,
Specifying a Mobile Computing Infrastructure and Services
251
related to consistency. CCs try to ensure that there is neither any loss of information (No Loss) nor any confusion between various components in a system during its operation No Confusion. The effects of loss of information may not be immediately apparent, but they may have devastating effects on the system in the long run. Also, when such an inconsistency is detected later, it may be difficult to find its cause. No Confusion means that a system does not do any operation that leads to disparity in information at different parts of the system. While designing a system, a designer can view it from two perspectives. First, each operation on a system changes the state of the system (Change Perspective). A designer tries to make sure that such changes comply with the requirements of the system (provided by the use cases). Second, almost every system has a set of properties (called invariants or CCs) that should not change during the system’s lifetime (Invariants Perspective). So, every operation on the system should preserve these invariants. Using these two perspectives together helps a designer to identify and deal with problems during design. An operation may give the results expected from it, but, apart from that, the operation may also have some side effects on the system that violates its invariants. The CCs help a designer to find and avoid such side effects. While specifying the mobile environment, we found 45 different CCs at various levels of the specification. Out of these, 12 CCs were found at the system level. These CCs are to be satisfied (maintained) prior to, during, and subsequent to the actions of Mobichart services. We think of a mobile task as a composition of a set of Mobichart services that conforms to the system level CCs. A task is well behaved if the Mobichart actions taken by the task preserve the consistency of the system. An example of a CC is that every MH in the system must have an MSS in the system as its base, and that MSS must record the MH as belonging to it (which is modelled as the MH’s identifier being in the set mhsAsBASEMSS for that MSS). Readers will find all the CCs specified in the full report [10]. baseCons : System → Bool baseCons(sys) ≡ (∀ h : MH id • h ∈ mhs(sys) ⇒ (∃ m : MSS id • m ∈ msss(sys) ∧ H.HS.baseMSSid(mhs(sys)(h)) = m)) ∧ h ∈ M.MS.mhsAsBASEMSS(msss(sys)(m)), 4.2
Inspecting Confidence Conditions
Confidence conditions are conditions that should generally be true if an RSL module is not to be inconsistent, but that cannot in general be determined as true by a tool. The types of conditions that are generated by the confidence condition generator tool are given in [9]. While writing the specification, confidence conditions helped us to find errors, particularly when a function was applied without considering its preconditions. We inspected the generated (a total of 859) confidence conditions and believe them all to hold. Note that consistency conditions that are expressed as subtype conditions give rise to confidence con-
252
S. Acharya, C. George, and H. Mohanty
ditions on the results of functions generating values in the subtypes, and this helps to identify the functions that need careful inspection. Consistency conditions can (optionally) be translated, so the testing we describe below gave us further assurance that they are in fact satisfied. 4.3
Prototyping and Testing
To generate and run the test cases, we prototyped the system specification by doing a simplified refinement of all the abstract types in it. We then used the RSL to SML translator provided by the RAISE tools [9] to run some test cases. We used the bottom-up testing strategy by first testing each lower level module in the specification and then testing the higher level modules. At least one test case was used to test each function in a module (function coverage). Some examples of test cases used to test the behavior of the function taskleave (page 250) are: test case [ test1 ] init(); consistent(s), /∗Result: true∗/ /∗Testing `taskleave of Mobichart∗/ [ test2 ] init(); consistent(taskleave(t1, s)), /∗Result: true∗/ The test case [test1] is used to ensure that initialization of the prototype of the system does not violate any CCs. After ensuring the consistency of initial state of the system, we use test case [test2] to call taskleave and ensure that the resulting state of the system is consistent. When this function is used, the task t1 (initially present in an MSS m1 in the protoype) is removed from MSS m1 and goes to transit state. Table 1. Faults found during Testing using 309 test cases. ‘New CCs added’ indicates the number of new CCs found necessary during testing. ‘CCs Changed’ gives the number of constraints changed in different CCs. Similarly, ‘Functions Changed’ indicates the number of functions (other than CCs) where we had to add new statements Type of Change Made No. of Changes Typographic 8 New CCs Added 4 CCs Changed 5 Sequence of Function Calls 1 Functions Changed 10 TOTAL = 28
We used a total of 309 test cases on different modules and found 28 errors in the specification. Out of these errors, 8 were typographic (typo) errors and 20 were conceptual/logical errors. A typo is a discrepancy between author’s intention and specification. Other errors (conceptual/logical) represent an inadequate or mistaken understanding of the problem. These are potentially more damaging than typos because they are less likely to be discovered during development. Table 1
Specifying a Mobile Computing Infrastructure and Services
253
summarizes the categories of changes made at different levels of specification to fix the errors during testing. Most of these errors were found because of the CCs. Results of some test cases did not give a consistent system. It implies that, if the CCs had not been taken into account, these conceptual errors would have gone unnoticed. It is also interesting to observe here that out of 20 conceptual errors, almost half of them are related to changes in the CCs. Detecting these types of faults in the specification is more useful, since they generally go unnoticed and the effects of such faults can be catastrophic during later stages of system development.
5
Conclusion
There have been efforts to specify this new computing paradigm in formal methods [12, 13, 14]. In this paper we have presented a model of a MC environment and discussed the behavior of applications in this environment. We also discussed the formal specification of the environment and the Mobichart notation and its services to support execution of applications in this environment. In the process of developing the specification, we thereby provide semantics to the Mobichart services. The importance of finding and specifying CCs in a specification is discussed. Different methods were used to gain confidence on the correctness of the specification, like confidence conditions, and specification-based testing using test cases. Some observations on the faults found during testing and their causes have been reported. This work is a step towards the main objective of developing automated tools to support the process of application development in MC environment using Mobicharts and the semantics of the Mobichart services provided by the specification. We believe that the specification will help in generating such an automated supporting tool for the MC application developers. We also believe that the identified precondition for each operation would help in formulating some exception handlers during the development of such tools.
References 1. B.R.Badrinath et al. Impact of Mobility on Distributed Computation. ACM SIGOS Operating System Review, 27(2):15–20, February 1993. 2. G.H.Formen et al. The Challenges of Mobile Computing. IEEE Computer, 27(4):38–47, 1994. 3. S.Acharya, H.Mohanty, and R.K.Shyamasundar. MOBICHART: A Notation to Specify Mobile Computing Applications. In Proc. of the 30th Hawaii International Conference on System Sciences (HICSS’03). IEEE, January 2003. 4. David Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8:231–274, 1987. 5. David Harel and Amnon Naamad. The STATEMATE Semantics of Statechart. ACM Trans. on Software Engg. & Method., 5(4):293–333, October 1996. 6. D.Coleman et al. Introducing Objectchart or How to Use Statecharts in ObjectOriented Design. IEEE Trans. on Software Engg., 18(1):9–18, January 1992.
254
S. Acharya, C. George, and H. Mohanty
7. H.Mohanty, S.Acharya, R.K.Ghosh, and R.K.Shyamasundar. Mobichart for Modeling Mobile Computing Tasks. In Convergent Technologies for the Asia-Pacific, pages 193–197. IEEE TENCON, Bangalore, India, Oct. 14-17 2003. 8. Chris George. Introduction to RAISE. Technical Report 249, UNU/IIST, P.O. Box 3058, Macau, March 2002. 9. Chris George. RAISE Tools User Guide. Technical Report 227, UNU/IIST, P.O. Box 3058, Macau, February 2001. 10. Satyajit Acharya and Chris George. Specifying a Mobile Computing Application Environment using RSL. Technical Report 300, UNU/IIST, P.O. Box 3058, Macau, May 2004. 11. http://www.iist.unu.edu. UNU/IIST, P.O. Box 3058, Macau SAR, China. 12. L.Cardelli et al. Mobile Ambients. In Foundation of Software Science & Computational Structures, LNCS 1378, pages 140–155. Springer, 1998. 13. G.C.Roman et al. Mobile UNITY: Reasoning and Specification in Mobile Computing. ACM Trans. on Software Engg. & Method., 6(3):250–282, July 1997. 14. Luca Cardelli. Abstractions for Mobile Computation. In Security Issues for Distributed & Mobile Objects, LNCS 1603, pages 51–99. Springer-Verlag, 1999.
