Realizing Vision 2020: A Proposal

1
Realizing Vision 2020 A Proposal

• Aditya P. Mathur
• Professor, Associate Head, and Director
• Department of Computer Sciences and
• Software Engineering Research Center
• Purdue University, West Lafayette, IN, USA
• Pundi Narasimham
• President
• STS 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
The Digital Government Project 2

• 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
The Digital Government Project 3

• 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
The Test Tools Project 2

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

10
The Test Tools Project 3

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

11
The Test Tools Project 4

• 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
The Test Tools Project 5

• 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
The Test Tools Project 6

• Details of the testing techniques and the tool
  follow.

14
Structure of an Internet Service
Component
Component
Request/data
Request/data
ORB
ORB
Communication .
15
Interface Testing
100 Method Coverage methods executed methods
defined
Methods m1, m2, ,mk
100 Exception Coverage exceptions raised
exceptions defined
Exceptions e1, e2, ,ek
100 iMutation Score distinguished
mutants total imutants - equivalent imutants
Interface
Component
16
What is Interface Mutation ?
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

Server callback
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
Effect of Avg. Load
On Avg. Latency
C1
network
Clients
Server
C2
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
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
Component Types
Geographical regions
Client categories
26
Managing XML Applications
XML specification
WABASH MC Module
Subscribe
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
Architecture of Wabash 2.0 1
GUI requests data from the Zonal Manager
Wabash GUI
Zonal Manager returns data collected from LL to
GUI
Zonal Manager requests data from corresponding LL
LL returns data to Zonal Manager
LL determines whether request can be passed or not
Client sends a request to a managed object
Request
C
If the request is allowed, LL forwards it to the
CORBA Server after time-stamping it
If the request is not allowed, LL throws
exception and does not forward request to the
CORBA Server
LL gets the response from the CORBA Server
LL stores information about the request, records
it in a log, sends the response back to client