1

Seminar Report On Testing and Debugging Persistent Computing Systems: A New Challenge in Ubiquitous Computing

Submitted

To MANIPAL UNIVERSITY
By Surbhi Gupta Reg No: 080911031

Under the Guidance of

Mr Balachandra

Department of Information and Communication Technology

MANIPAL INSTITUTE OF TECHNOLOGY

(A constituent Institute of Manipal University)

MANIPAL - 576 104, KARNATAKA, INDIA AUGUST 2011

INDEX
Sr no 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Title ABSTRACT MOTIVATION OBJECTIVES INTRODUCTION AND BACKGROUND METHODOLOGY SSB BASED ARCHITECTURE TESTING AND DEBUGGING PERSISTENT COMPUTING SYSTEMS ISSUES IN ESTING AND DEBUGGING PERSISTENT Page No 3 4 4 5 8 9 12 16 18 19

COMPUTING SYSTEMS CONCLUSION REFERENCES

ABSTRACT

The term ubiquitous means existing or being everywhere at the same time. This paper discusses a complete new challenge, that is, how to test and debug a computing system running continuously and persistently. Promoters of ubiquitous computing hope that embedding computation into the environment and everyday objects would enable people to move around and interact with information and computing more naturally and casually than they currently do. The ultimate goal of ubiquitous computing is to provide users with the way of computing anytime and anywhere. The assumption we have made here is that there are computing systems working anytime and available anywhere throughout the world. This brings us to the requirement that computing systems should run continuously and persistently without stopping. Another assumption made is that the program can be executed repeatedly with various input data. In order to successfully develop, use and maintain a persistent computing system, we have to find a completely new methodology to test and debug a persistent computing system at run time without stopping it.

MOTIVATION
My motivation to present a seminar on this topic is majorly because ubiquitous computing is one of the latest emerging technologies. I came across this topic in my Distributed Systems subject this semester and it really interested me and many people still do not know the mechanisms of ubiquitous computing. As this is one of the upcoming topics and has wide applications, this becomes one of the hot topics in the research and development area.

OBJECTIVES

The objective of the paper is to propose a completely new challenge in ubiquitous computing that is, how to test and debug a persistent computing system at run-time on condition that the system is running continuously and persistently. The paper also discusses some completely new technical issues in testing and debugging of persistent computing systems. This is also the first paper to discuss software engineering issues concerning persistent computing systems.

INTRODUCTION AND BACKGROUND

Ubiquitous computing is the idea that involves technology being everywhere, but becoming virtually invisible in our lives. Instead of having a desk-top or lap-top machine, the technology we use will be embedded in our environment. Ubiquitous computing touches on a wide range of research topics, including distributed computing, mobile computing, sensor networks, human-computer interaction and artificial intelligence. There are various challenges in the age of ubiquitous computing. Mark Weiser coined the phrase "ubiquitous computing" around 1988, during his tenure as Chief Technologist of the Xerox Palo Alto Research Center (PARC). Both alone and with PARC Director and Chief Scientist John Seely Brown, Weiser wrote some of the earliest papers on the subject, largely defining it and sketching out its major concerns The aim of ubiquitous is to provide users with the way of computing anytime and anywhere such that one can use computing systems without even thinking about it. A computing environment cannot be considered ubiquitous if it cannot provide services to its users anytime. Therefore, one of the major requirements for the ubiquitous computing is that the computing system should run continuously and persistently. Ubiquitous computing names the third wave in computing, just now beginning. First were mainframes, each shared by lots of people. Now we are in the personal computing era, person and machine staring uneasily at each other across the desktop. Next comes ubiquitous computing, or the age of calm technology, when technology recedes into the background of our lives. It is also called the "Third Paradigm" computing.

Assumptions made in ubiquitous computing:

a. There are computing systems working anytime and available anywhere throughout the world. b. Any program can be executed repeatedly with various input data only for testing and debugging without regard to stopping the task that program has to perform.

What Ubiquitous Computing Isn't:

Ubiquitous computing is roughly the opposite of virtual reality. Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people. Virtual reality is primarily a horse power problem; ubiquitous computing is a very difficult integration of human factors, computer science, engineering, and social sciences.

Any ubiquitous computing system should be a reactive system. A reactive system is a computing system that maintains an on-going interaction with its environment. The present world is more and more dependent on various reactive systems such as, air traffic control systems, nuclear reactor control systems, computer networks etc. The breakdown of such reactive systems can be disastrous to humans life and hence it is desirable that these reactive systems possess qualities of high reliability and high security. They should run continuously all the time without stopping their service even during maintenance, upgrading and reconfiguration or when they are being attacked. From the viewpoints of dependable computing and ubiquitous computing, the present author has proposed a new type of reactive systems, named persistent computing systems. A persistent computing system is a reactive system that functions continuously anytime without stopping its reactions even when it needs to be maintained, upgraded, or reconfigured, it has some trouble, or it is attacked. In order to develop, use, and maintain persistent computing systems, we have to find a completely new methodology and its related techniques to test and debug a persistent computing system at run-time without stopping it. This is a completely new challenge in ubiquitous computing. The significance of solving the problem is obvious because we cannot guarantee a computing system to be ubiquitous if we have no engineering way to test and debug it in its maintenance, upgrade, and reconfiguration.

METHODOLOGY
Some principles regarding the concurrent systems engineering are stated below: The wholeness principle of concurrent systems: The behavior of a concurrent system is not simply the mechanical putting together of its parts that act concurrently but a whole such that one cannot find some way to resolve it into parts mechanically and then simply compose the sum of its parts as the same as its original behaviour. The uncertainty principle in measuring and monitoring concurrent systems: In measuring and monitoring a concurrent system, the behavior of an observer (a measurer or a monitor) cannot be separate from what is being observed. The self-measurement principle in designing, developing, and maintaining concurrent systems: A large-scale, long-lived, and highly reliable concurrent system should be constructed by some function components and some (maybe only one) permanent self-measurement components that act concurrently with the function components, measure and monitor the system itself according to some requirements, and pass run-time information about the systems behavior to the outside world of the system. On the other hand, we can say the following dependence principle in measuring, monitoring, and controlling: A system cannot control what it cannot monitor, and the system cannot monitor what it cannot measure. Since reactive systems are inherently concurrent systems, the above general principles can also underlie reactive systems engineering. We can thus construct a persistent computing system by a group of control components including self-measuring, self-monitoring, and self-controlling components with general-purpose which are independent of systems, a group of functional components to carry out special tasks of the system, some data-instruction buffers, and some data-instruction buses.

10

SSB BASED ARCHITECTURE

The buses are used for connecting all components and buffers such that all data/instructions are sent to target components or buffers only through the buses and there is no direct interaction which does not invoke the buses between any two components and buffers. SSB stands for soft system bus. It is simply a communication channel with the facilities of data-instruction transmission and preservation to connect components in a component-based system. It may consist of some data-instruction stations, which have the facility of datainstruction preservation, connected sequentially by transmission channels, both of which are implemented in software techniques, such that over the channels data/instructions can flow among data-instruction stations and a component tapping to a data-instruction station can send data/instructions to and receive data/instructions from the data-instruction station. Requirement of SSB: is that an SSB must provide the facility of data-instruction preservation such that when a component in a system cannot work well temporarily all data/instructions sent to the component should be preserved in some data-instruction station(s) until the component works well to get these data/instructions. Therefore, other components in the system should work continuously without interruption, except those components that waiting for receiving new data/instructions sent from the component in question. From the viewpoint of structure, an SSB may be either: linear circular From the viewpoint of information flow direction, data/instruction flows along an SSB may be either one way or bidirectional. Therefore, there may be four basic types of SSBs: linear one-way
linear bidirectional

circular one-way
circular bidirectional

11

The following figures show a linear SSB architecture and a circular SSB architecture of SSBbased systems. The blocks in yellow indicate the control components. These include: Me - Central Measurer R - Central Recorder Mo - Central Monitor C/S - Central Controller/Scheduler All of these control components are permanent components of the system and are independent of any application. These central control components are connected by a SSB such that all data and instructions are sent to or received by components only through the SSB and there is no direct interaction which does not invoke the buses between any two components. The functional components are measured, recorded, monitored, and controlled by the central control components. All measurement data, instructions issued by the central control components, and communicating data between components flow along the SSB.

12

This methodology is just one of the ways to implement persistent computing systems. But at present it is the only one proposed with the explicit purpose to implement persistent computing systems; through maybe some other methodology will be proposed. To be persistent as well as ubiquitous, the maintenance, upgrade, and reconfiguration of a computing system, without regard to the way to implement it, have to be performed during its continuous running without stopping its services. Otherwise, it cannot be regarded to be persistent and/or ubiquitous because it cannot provide services to its users anytime. For a computing system built by SSBs, its maintenance, upgrade, and reconfiguration during its continuous running requires that any control component, data-instruction station, or functional component should be added, replaced, or removed without stopping the running of the whole system and services provided by the system.

13

TESTING AND DEBUGGING PERSISTENT COMPUTING SYSTEMS

Testing involves finding problems in your code; debugging consists of isolating and fixing the problems. Testing and debugging are necessary stages in the development cycle, and they are best incorporated early in the cycle. Thoroughly testing and debugging individual components makes testing and debugging integrated applications much easier. Typically, developers look for different levels of robustness as they are testing and debugging their applications: 1. Running without crashing or generating error messages. 2. Appropriate action in common scenarios. 3. Reasonable action or error messages in a range of scenarios. 4. Graceful recovery from unexpected user interactions.

Principles of Testing:
Testing is a comprehensive organized effort to exercise all aspects of a software system for possible failure. 1. Successful testing is not a proof of correctness (unless you try every input exhaustively), but it can provide useful reassurance. 2. Design test cases. Testing should not be "random."
o o

When the number of possible inputs is small, try them all. Test all "branches" of the code. For example, be sure to include test cases that go through the, if part as well as the else part of a conditional statement. Test boundary cases, like 0, 1, -1, etc. Look for ways to "break" the program, and try those to be sure they don't.

o o

3. Know what the expected results of your tests should be. Otherwise, you might not recognize an incorrect result.
4. Always be aggressive about testing. If you test gingerly, you won't uncover as many

errors. Remember, the objective in testing is to find errors.

14

5. Save your test program (and the expected results) so you can run it again later. Whenever modifying a program to fix one problem, there is a risk that you might have caused a different problem, so it's best to repeat all the tests.

Principles of Debugging:
A program bug relative to a program error is a cause of the error. A bug may cause more than one error, and also, an error may be caused by more than one bug. Traditionally, debugging is defined as the process of locating, analyzing, and ultimately correcting bugs in the target program/system.

It begins with some indication of the existence of an error, repeats the process of developing, verifying, and modifying hypotheses about the bug(s) causing the error until the location of the bug(s) is determined and the nature of the bug(s) is understood, then corrects the bug(s), and ends in a verification of the removal of the error.

Usually, any maintenance, upgrade, and reconfiguration of any computing system must be done with testing and debugging in order to guarantee correct functioning of the new system. The requirement that a persistent computing system has to be maintained, upgraded, and reconfigured during its continuous and persistent running raises a completely new challenging technical issue: how to test and debug a persistent computing system running continuously?
Both testing and debugging intend to deal with the differences between actual and

required conditions/situations of a system and/or program.

Both testing and debugging take programs as their targets to deal with. Any program can be executed repeatedly with various input data only for testing and

debugging without regard to stopping the task that program has to perform.

Essentials requirements for persistent computing systems (SSB based systems)

15

Because any testing and debugging of a program/system must be based on its explicitly defined requirements/specifications, we first list out some essential requirements for persistent computing systems (SSB-based systems) as follows:

R1: Any control component in an SSB-based system must not be stopped. R2: Any control component in an SSB-based system must not be dependent on any special
functional component in the system.

R3: Any functional component in an SSB-based system must be able to be maintained,

upgraded, replaced, added to, or moved from the system without stopping the running of the whole system.

R4: The stop of running of any functional component in an SSB-based system must not lead to
the stop of running of the whole system.

R5: All data/instructions sent to a functional component in an SSB-based system must be

preserved, if the functional component does not work, until the functional component works well and must be resent to it.

R6: The SSBs must not be dependent on any special computing environment including
computers, operating systems, and programming languages.

R7: All data/instructions flowing over SSBs must have the unified form. R8: The SSBs must be able to be implemented in distributed way as well as centralized way. R9: Any control component in an SSB-based system must be invisible and inaccessible to the
outside world of the system.

R10: Any instruction to and any operation on any functional component in an SSB-based
system must be authenticated.

R11: All data/instructions flowing over SSBs must be able to be enciphered in different degree
of security according to different security policies of application systems.

R12: The interaction between an SSB-based system and its outside world must be able to be
stopped when its continuous running will lead to a disaster.

Here R1, R3, R4, and R5 are completely new. Usually the requirement that a computing system should run continuously and persistently is never taken into account explicitly as an essential and/or general requirement by traditional reactive systems and/or traditional software

16

engineering methodologies. But these requirements are necessary for persistent computing system to run continuously and persistently. All the existing (computer-based or human) testing and debugging techniques take programs of a system rather than the running system itself as the objects and/or targets. And also any program can be executed repeatedly with various input data only for testing and debugging without regard to stopping the task that program has to perform. However, this fundamental assumption does not hold for persistent computing systems any longer.

ISSUES IN TESTING AND DEBUGGING PERSISTENT COMPUTING SYSTEMS

17

STOP ERRORS:
The most important requirement for persistent computing systems is the continuous and persistent running without stopping reactions. Hence, it should be specified in the specification of any persistent computing system. Therefore, a completely new class of errors in persistent computing systems should be introduced: stop errors, that is, those system situations stopping the running/reacting of the whole system. This new class of errors should be most serious one to any persistent computing system. We have to find some systematic method to test the stop errors.

TESTABILILTY OF REQUIREMENTS:
A requirement is defined to be testable if it is possible to design a procedure in which the functionality being tested can be executed, the expected output is known, and the output can be programmatically or visually verified. Therefore, the traditional definition for the testability of requirement has to be revised such that the requirement of non-stop running/reacting is taken into account.

VARIOUS INPUT DATA:

As we know one of the assumptions made in reactive systems is that any program can be executed repeatedly with various input data only for testing without regard to stopping the task that program has to perform. Therefore, almost all traditional and/or usual requirements, i.e., design, functional, implementation, interface, performance, and physical requirements, should be reconsidered.

DEPENDANCY RELATIONS:
We know that in a testing process, one component should not disturb the task of any other sound component, in order to satisfy the requirement of non-stop running of the system. But if the testing process concerns even the other components, then to go further with the testing without disturbing the other sound components becomes difficult. Therefore, some dependency analysis method to identify, classify, analyze and represent various dependency relationships among all components of a persistent computing system should be investigated. This is an overhead.

18

DEBUGGING DIFFICULTY:
Debugging a persistent computing system is much more difficult than testing it because debugging must make some modification to remove bugs from the target program/system and then correct it. Any debugging action must not disturb the task of any sound component in order to satisfy the requirement of non-stop running/reacting.

CONCURRENT SYSTEM:
Any persistent computing system is a concurrent system. Its behavior is not reproducible. Adding to it, persistent computing system is also debugged when it is running continuously, and some interaction with its outside environment may have taken place during debugging. This implies that it must be quite difficult to establish a mapping from the programs of the system to its actual behavior at various time points. This means that the reasoning about causal relationships between bugs and the errors may be quite difficult.

SWITCHOVER TECHNIQUE:
In an SSB-based persistent computing system, when a functional component is tested or debugged, it may need a substitute to play temporarily the part for the functional component being tested or debugged. Therefore, some switchover technique is necessary. On the other hand, if the control components or data-instruction stations need to be tested and/or debugged, the task is more difficult than testing and debugging functional components, because some run-time information may be not available in these situations.

CONCLUSION

19

The requirement that a computing system should run continuously and persistently has never been explicitly taken into account as an essential requirement by traditional reactive systems. This becomes an essential requirement to implement a ubiquitous computing system. I have presented one of the ways to a test and debug a persistent computing system at run-time on condition that the system is running continuously and persistently. However it has its own issues to deal with which has also been listed and explained. There are many interesting and challenging research problems in this direction. To solve these difficult problems is necessary to actualizing the ultimate goal of ubiquitous computing.

20

REFERENCES
1. "Some Computer Science Problems in Ubiquitous Computing," Communications of the

ACM, July 1993. - Mark Weiser

2. Ubiquitous Computing - R. Jason Weiss, Development Dimensions International, J.

Philip Craiger, University of NebraskaOmaha

3. Journal of Ubiquitous Computing and Intelligence (JUCI)- Laurence T. Yang, St.

Francis Xavier University, Canada

4. Ubiquitous Computing: An Interesting New Paradigm by Marcia Riley.