Realizing Vision 2020: A Proposal

Realizing Vision 2020: A Proposal

Aditya P. MathurProfessor, Associate Head, and DirectorDepartment of Computer Sciences andSoftware Engineering Research CenterPurdue University, West Lafayette, IN, USA

Pundi NarasimhamPresidentSTS Worldwide, Atlanta, USA

Tuesday August 8, 2000

Last updated: July 13, 2000


2

Vision 2020

“The sixth is the challenge of establishing a scientific and progressive society, a society that is innovative and forward-looking, one that is not only a consumer of technology but also a contributor to the scientific and

technological civilization of the future.“:

….His Excellency YAB Dato' Seri Dr Mahathir Mohamad.


3

Scientific and progressive society

Purdue-STS Contribution: Establishment of procedures to transform

current mode of business practices of the Government of Malaysia into digital-mode.

Transformation of key selected governmental procedures into the digital domain.


4

Contributor to the scientific and technological civilization of the future

Purdue-STS Contribution: Development of the most advanced tools for

test and management of Internet Services. Research and Prototype development at Purdue. Productization and commercialization by STS

Malaysia.


5

The Digital Government Project [1]

Long term goal:

Execute all essential tasks in a secure digital domain.

Provide the citizens of Malaysia the opportunity to complete all transactions with the government in a timely manner and in a secure digital domain.


6


Collaborators: Department of Computer Sciences at Purdue

University. STS Offshore Services (M) SDN BHD Malaysia. Selected University in Malaysia.

Senior Personnel: Professor Aditya Mathur, Purdue University Professor Michael Stohl, Dean International

Programs, Purdue University. Pundi Narasimham, President, STS.


7


Project Phases: Phase I: Feasibility study and project planning.

Purdue/STS. January-July 2001. Phase II: Prototyping: Purdue. September-March

2002. Phase III: Digitization I: Purdue/STS. June 2002-

May 2003. Phase IV: Digitization II: STS: Period to be

determined.


8

The Test Tools Project [1]

Phase I: Transfer Internet Services Test technology developed at Purdue to STS.

Phase II: STS productizes the technology in collaboration with faculty from a University in Malaysia.

Phase III: STS commercializes the product as a product from Malaysia.

Purdue continues research in advanced test tools in collaboration with a University in Malaysia.


9


Timeline: Phase I: December 2000. Phase II: January-July 2001. Phase III: August-December 2001.


10


Development of the test tools will continue once the first version has been marketed and has been adopted by customers.


11


What to test and manage? Internet services: e-commerce, web-sites, CORBA

applications, XML applications, Java applications. What will the tool(s) allow a tester to do?

Visual Test capture and replay. Visual Test assessment and enhancement. Dynamic testing (future). Monitoring and control of CORBA, XML, and Jini

applications. Performance testing.


12


Uniqueness of the Purdue technology: Integrated test and management. Support for test assessment via Interface Mutation. Support for heterogeneous environment.

Multiple platforms. Multiple software technologies (e.g. CORBA and XML)

Strength of Purdue: World leader in research in software testing.

Research group at Purdue has published over 100 research papers in world class journals and conference proceedings since 1987. Eight Ph.D. theses have been produced in this area.


13


Details of the testing techniques and the tool follow.


14

Client/Server

Stub/Skeleton

Request/data

Client/Server

Stub/Skeleton

Request/data

Component Component

ORB ORB

Communication .

Structure of an Internet Service

ComponentORB: Object Request Broker


15

Component

Interface

Methods:m1, m2, …,mk

Exceptions:e1, e2, …,ek

100% Method Coverage# methods executed# methods defined

100% Exception Coverage# exceptions raised# exceptions defined

100% iMutation Score

# distinguished mutantstotal # imutants - #equivalent imutants

Interface Testing


16

What is Interface Mutation ?

Test Suite T contains Request-A.

Client ServerInterface

Request-A

Response-A

Mutated Interface

Client ServerRequest-A

Response-B


17

Observations [1]

Interface mutation leads to fewer tests that reveal almost as many errors as revealed by statement and decision coverage.

Interface mutation is a scalable alternative to using code coverage.


18

Observations [2]

Reveals programming errors in components. errors in the use of component

interfaces Reveals certain types of deadlocks

41

25

3

Server callback

Client Server

Client Request


19

Testing for fault tolerance

Problem: Often error recovery code is not executed

by test inputs How do we know if the fault recovery code

adequately meets the requirements? Solution:

Simulate the occurrence of faults by injecting them

Fault injection testing at the interface Increases coverage of fault recovery code Reveals inadequacies in fault recovery code


20

Load Testing

network network

C1

C2

Server

On: Avg. Latency Effect of: Avg. Load

Clients


21

Dynamic Testing

Question: How to test an Internet Service while it

is in use? Answer: Use the dynamic testing

procedure.

What is the dynamic testing procedure?


22

Dynamic Testing

FaultyServer groupFaulty

serverTestClient

Ra2

Ra

Client

1

Client Client

Isolatedserver

3


23

Limitations of Dynamic Testing

Test client might generate undesirable actions: Persistent data modification. Irreversible actions.

Application limited to: Closed and well understood domains. Simulated or isolated service

environments.


24

Organization of the Service Domain

Why organize ? Efficient and scalable management Personalized management Assignment of individual

responsibilities


25

Dimensions of Organization

Geographical regions

Component Types

Client categories


26

Managing XML Applications

XML specification

XML ParserObject stateinformation

Object controlCommands (allow/deny)

WABASH MCModule

WABASH GUI

MC specification

Subscribe

Application

EventsEvents

Publish


27

Architecture of Wabash 3.0


28

Ongoing Research [1]

API development. Non-intrusive procedures for dynamic testing. Generalized event-control model and its

implementation. Implementation of the unified architecture to

assist with the management of JMX, JINI, CORBA objects, and XML applications.

Light-version of Wabash for SmartHome management.


29

Ongoing Research [2]

Automatic generation of test inputs.

Test capture and replay. Dynamic data collection and

analysis.


30

The Wabash Project: History

Progress:August 1998:

Wabash project launched.

August 1999 TDS 1.1 available to SERC affiliates.

August 2000 Wabash 2.0 available to SERC affiliates. Experiments to assess goodness of proposed

interface testing criteria completed.

December 2000 Uniform interface for Jini/JMX/CORBA objects and

XML applications.


31

LLI

MC AR

db

Zonal Manager

LL

CS

LOG

Host 1

C

Architecture of Wabash 2.0 [1]

WabashGUI

Request Client sends a requestto a managed object

LL determines whether request can be passed or not

If the request is allowed, LL forwards it to the CORBA Server after time-stamping it

Response

LL stores information about the request, records it in a log, sends the response back to client

LL gets the responsefrom the CORBA Server

If the request is not allowed,LL throws exception and doesnot forward request to the CORBA Server

GUI requests data fromthe Zonal Manager

Zonal Manager requests datafrom corresponding LL

LL returns datato Zonal Manager

Zonal Manager returnsdata collected from LLto GUI

Documents

Realizing Vision 2020: A Proposal