SLICING OF SOA-BASED SOFTWARE AND ITS APPLICATION TO … · SLICING OF SOA-BASED SOFTWARE AND ITS...

SLICING OF SOA-BASED SOFTWARE ANDITS APPLICATION TO TESTING

A Thesis submitted to Gujarat Technological University

For the award of

Doctor of Philosophy

in

Computer Engineering

by

Kaushikkumar Keshavlal RanaEnrollment No. 119997107010

Under supervision of

Prof. Durga Prasad Mohapatra

GUJARAT TECHNOLOGICAL UNIVERSITYAHMEDABAD

DECEMBER-2016

c©Kaushikkumar Keshavlal Rana

DECLARATION

I declare that the thesis entitled “Slicing of SOA-based Software and its Application toTesting” submitted by me for the degree of Doctor of Philosophy is the record of researchwork carried out by me during the period from March 2011 to December 2016 under thesupervision of Prof. Durga Prasad Mohapatra and this has not formed the basis for theaward of any degree, diploma, associateship, fellowship, titles in this or any other Universityor other institution of higher learning.I further declare that the material obtained from other sources has been duly acknowledgedin the thesis. I shall be solely responsible for any plagiarism or other irregularities, if noticedin the thesis.

Signature of the Research Scholar:.............................. Date:..............................

Name of Research Scholar: Kaushik K. Rana

Place: Ahmedabad

CERTIFICATE

I certify that the work incorporated in the thesis “Slicing of SOA-based Software and itsApplication to Testing” submitted by Mr. Kaushikkumar Keshavlal Rana was carried out bythe candidate under my supervision/guidance. To the best of my knowledge: (i) the candidatehas not submitted the same research work to any other institution for any degree/diploma, As-sociateship, Fellowship or other similar titles (ii) the thesis submitted is a record of originalresearch work done by the Research Scholar during the period of study under my supervi-sion, and (iii) the thesis represents independent research work on the part of the ResearchScholar.

Signature of Supervisor:.............................. Date:..............................

Name of Supervisor: Prof. Durga Prasad Mohapatra

Place: Rourkela

Originality Report Certificate

It is certified that Ph.D. Thesis titled “Slicing of SOA-based Software and its Applicationto Testing” submitted by Mr. Kaushikkumar Keshavlal Rana has been examined by me.I undertake the following:

a. Thesis has significant new work / knowledge as compared already published or are underconsideration to be published elsewhere. No sentence, equation, diagram, table, para-graph or section has been copied verbatim from previous work unless it is placed underquotation marks and duly referenced.

b. The work presented is original and own work of the author (i.e. there is no plagiarism).No ideas, processes, results or words of others have been presented as Author own work.

c. There is no fabrication of data or results which have been compiled / analyzed.

d. There is no falsification by manipulating research materials, equipment or processes, orchanging or omitting data or results such that the research is not accurately represented inthe research record.

e. The thesis has been checked using turnitin software (copy of originality report attached)and found within limits as per GTU Plagiarism Policy and instructions issued from timeto time (i.e. permitted similarity index ≤ 25%).

Signature of the Research Scholar:.............................. Date:..............................


Place: Ahmedabad

Signature of Supervisor:.............................. Date:..............................


Place: Rourkela

Ph.D. THESIS Non-Exclusive License to GUJARATTECHNOLOGICAL UNIVERSITY

In consideration of being a Ph.D. Research Scholar at GTU and in the interests of the fa-cilitation of research at GTU and elsewhere, I, Kaushikkumar Keshavlal Rana havingEnrollment No.119997107010 hereby grant a non-exclusive, royalty-free and perpetual li-cense to GTU on the following terms:

a. GTU is permitted to archive, reproduce and distribute my thesis, in whole or in part,and/or my abstract, in whole or in part ( referred to collectively as the Work) anywhere inthe world, for non-commercial purposes, in all forms of media;

b. GTU is permitted to authorize, sub-lease, sub-contract or procure any of the acts men-tioned in paragraph (a);

c. GTU is authorized to submit the Work at any National / International Library, under theauthority of their Thesis Non-Exclusive License;

d. The Universal Copyright Notice () shall appear on all copies made under the authority ofthis license;

e. I undertake to submit my thesis, through my University, to any Library and Archives. Anyabstract submitted with the thesis will be considered to form part of the thesis.

f. I represent that my thesis is my original work, does not infringe any rights of others,including privacy rights, and that I have the right to make the grant conferred by thisnon-exclusive license.

g. If third party copyrighted material was included in my thesis for which, under the terms ofthe Copyright Act, written permission from the copyright owners is required, I have ob-tained such permission from the copyright owners to do the acts mentioned in paragraph(a) above for the full term of copyright protection.

h. I retain copyright ownership and moral rights in my thesis, and may deal with the copy-right in my thesis, in any way consistent with rights granted by me to my University inthis non-exclusive license.

i. I further promise to inform any person to whom I may hereafter assign or license mycopyright in my thesis of the rights granted by me to my University in this non- exclusivelicense.

j. I am aware of and agree to accept the conditions and regulations of Ph.D. including allpolicy matters related to authorship and plagiarism.

Signature of the Research Scholar:...................


Date:..............................Place: Ahmedabad

Signature of Supervisor:..............................


Date:..............................Place: Rourkela

Seal:

Thesis Approval Form

The viva-voce of the Ph.D. Thesis submitted by Shri Kaushikkumar Keshavlal Rana (En-rollment No.119997107010) entitled “Slicing of SOA-based Software and its Applicationto Testing” was conducted on ..................., at Gujarat Technological University.

( Please Tick any one of the following option)

� The performance of the candidate was satisfactory. We recommend that he be awardedthe Ph.D. degree.

� Any further modifications in research work to be submitted within 3 months from the dateof first viva-voce upon request of the Supervisor or request of the Independent ResearchScholar after which viva-voce can be re-conducted by the same panel again.

� The performance of the candidate was unsatisfactory. We recommend that he should notbe awarded the Ph.D. degree.

Prof. Durga Prasad Mohapatra

Department of Computer Science & Engineering,

National Institute of Technology Rourkela,

Odisha, India.

1) (External Examiner 1) Name and Signature:



ABSTRACT

This thesis presents our work concerning slicing of SOA-based software andits application to testing. A technique for static slicing of SOA-based softwarebased on SoaML service interface diagram is devised. In this technique, a modelusing SoaML service interface diagram is designed. Then, an intermediate rep-resentation, called service interface dependency graph (SIDG) is created fromthe model. The SIDG identifies service call dependency and composite depen-dency from SoaML model. Giving slicing criterion as an input, our proposedalgorithm SSSIM traverses the SIDG and identifies the affected service interfacenodes.

Next, our intermediate representation SIDG is extended to be able to computedynamic slices based on SoaML sequence diagram. In our technique, first eachmessage in sequence diagram is mapped with corresponding web service inputand output messages. This mapping is static. After that, an intermediate rep-resentation of SoaML sequence diagram is constructed which we have namedservice-oriented software dependence graph (SOSDG). SOSDG is an intermedi-ate representation that needs to be stored and traversed to get a dynamic slice asand when web service gets executed. The SOSDG identifies data, control, intra-service and inter-service dependencies from SoaML sequence diagram and thecorresponding web service execution. For a given slicing criterion, our proposedalgorithm MBGDS computes global dynamic slice from SOSDG and identifiesthe affected messages from respective service. The novelty of our work lies inthe computation of global dynamic slice based on SOSDG and its dependenciesinduced within and across organizations.

To support testing of SOA-based software at development phase, an extension toWSDL is proposed for carrying out black-box testing. In this context, programslicing artifact, i.e. dependence graph is applied for testing SOA-based software.In this approach, a hierarchical structure is imposed on web service descriptionlanguage (WSDL) document. The extension to WSDL is carried out by intro-ducing web service dependence graph (WSDG) and dependencies, both data andcontrol in XML schema definition (XSD) document. This WSDG identifies bothdata and control dependency from WSDG.

Next, techniques to test SOA-based software using business process modelingnotation (BPMN) diagram and SoaML service interface diagram are presented.To test it using BPMN diagram, first BPMN diagram is converted into its con-

trol flow graph (CFG) using our proposed algorithm. Then depth first search

(DFS) method is used to generate test paths. Finally, test cases are executed onthe generated test paths. Our second technique of testing uses SoaML serviceinterface diagram to model SOA-based software. Next, XML schema and itsinstance are generated using the visual paradigm enterprise tool. At last, testcases are executed based on schema constraints.

Finally, for all the above techniques or approaches, prototype tools are developedto experimentally verify the correctness and preciseness of our proposed algo-rithms or techniques. The computed slices and generated test cases for severalmodels or web services are found to be correct using both, manual procedureand our prototype tools.

Acknowledgements

First and foremost, I thank God for giving me the light and for enabling me tocomplete this research work.

I shall remain indebted to my guide, Prof. Durga Prasad Mohapatra, AssociateProfessor and Head of Department, Department of Computer Science & Engi-neering, NIT, Rourkela for his guidance, inspiration, encouragement and supportthroughout this work. Without his continuous and extensive support, this workwould have never been successful. He not only helped me broaden my vision onthe key issues in testing SOA-based software but also enlightened me with theproper way of transforming preliminary ideas into effective solutions throughindependent thinking.

The completion of this research work would not have been possible without theDoctorate Progress Committee (DPC) members: Prof. Bhushan Trivedi, Deanand Director at Faculty of Computer Technology, GLS University, Ahmedabadalso Dean of Zone-I, MCA Programme, GTU, and Prof. Sanjay Chaudhary,Professor and Associate Dean at Institute of Engineering and Technology (IET),Ahmedabad University. I am really thankful for their rigorous examinations andprecious suggestions during my research.

I am grateful to research scholars Vikash Panthi, Madhusmita Sahu, SangharatnaGodbole, Praveeta, Prachet Bhuyan, and Abhishek Ray working under the guid-ance of Durga sir at CSE Department, NIT Rourkela for their invaluable guid-ance, suggestion, support, and management of mine DPCs. I am also grateful toall the faculty members of the computer engineering department of both Vish-wakarma Government Engineering College and Government Engineering Col-lege Modasa for giving the inspiration to pursue Ph.D. Further, I want to extendmy special thanks to GTU Ph.D. section staff members Mr. Dhaval Gohil, Mr.Himanshu Raval, Ms. Mona Chaurasiya, Ms. Rajni Bhandari and others fortheir assistance and support.

Finally, I express my deepest gratitude and appreciation to my family membersespecially, my parents Shri. Keshavlal P. Rana, my father, and Smt. VaishnavRamilaben Manilal, my mother, Mrs. Leena K. Rana, my wife, and our son“Vishw”.

Mr. Kaushikkumar Keshavlal RanaPh.D. Student & Assistant Professor,Computer Engineering Department,

Vishwakarma Government Engineering College,Chandkheda-382424, Gujarat, India.

Table of Content

1 Introduction 11.1 Types of Program Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Static and Dynamic Slices . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Backward and Forward Slices . . . . . . . . . . . . . . . . . . . . 41.1.3 Executable and Closure Slices . . . . . . . . . . . . . . . . . . . . 61.1.4 Intra-procedural and Inter-procedural Slices . . . . . . . . . . . . . 61.1.5 Unstructured Program Slice . . . . . . . . . . . . . . . . . . . . . 71.1.6 Amorphous Program Slice . . . . . . . . . . . . . . . . . . . . . . 71.1.7 Software Architectural Slice . . . . . . . . . . . . . . . . . . . . . 81.1.8 Real-Time Program Slice . . . . . . . . . . . . . . . . . . . . . . . 81.1.9 Conditioned Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.10 UML Model Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.11 Aspect-Oriented Program Slice . . . . . . . . . . . . . . . . . . . . 9

1.2 Issues in Program Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Overview of Service-Oriented Architecture (SOA) . . . . . . . . . . . . . . 11

1.3.1 What is Service-Oriented Architecture (SOA)? . . . . . . . . . . . 121.3.2 What is Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 Important Service Characteristics . . . . . . . . . . . . . . . . . . . 131.3.4 What is a Business Process? . . . . . . . . . . . . . . . . . . . . . 15

1.4 Advantages of Service-Oriented Architecture (SOA) . . . . . . . . . . . . . 151.5 Research Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . 171.6 Motivation for Our Research Work . . . . . . . . . . . . . . . . . . . . . . 181.7 Goals and Objectives of Our Research Work . . . . . . . . . . . . . . . . . 211.8 Scope of Our Research Work . . . . . . . . . . . . . . . . . . . . . . . . . 241.9 Original Contributions of Our Research Work . . . . . . . . . . . . . . . . 241.10 Evaluation of Our Contributions . . . . . . . . . . . . . . . . . . . . . . . 251.11 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.12 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2 Basic Concepts 302.1 Program Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.1 Preliminary Concepts and Definitions . . . . . . . . . . . . . . . . 31

i

2.1.2 Intermediate Program Representation . . . . . . . . . . . . . . . . 322.1.3 Program Dependence Graph . . . . . . . . . . . . . . . . . . . . . 362.1.4 Basic Concepts in Static Slicing . . . . . . . . . . . . . . . . . . . 382.1.5 Precision and Correctness of Slice . . . . . . . . . . . . . . . . . . 392.1.6 Applications of Program Slicing . . . . . . . . . . . . . . . . . . . 41

2.2 Service-Oriented Architecture (SOA) . . . . . . . . . . . . . . . . . . . . . 462.2.1 Service-Oriented Architecture (SOA) Layers . . . . . . . . . . . . 462.2.2 SOA Architectural Principles . . . . . . . . . . . . . . . . . . . . . 48

2.3 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.3.1 Test, Test Case, and Test suite . . . . . . . . . . . . . . . . . . . . 532.3.2 Execution-based Software Testing . . . . . . . . . . . . . . . . . . 54

2.4 SOA Testing Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4.1 Functional Requirement Testing Challenges . . . . . . . . . . . . . 562.4.2 Non-functional Requirement Testing Challenges . . . . . . . . . . 612.4.3 SOA Specific Testing Challenges . . . . . . . . . . . . . . . . . . . 622.4.4 Testing Environment Challenges . . . . . . . . . . . . . . . . . . . 63

2.5 Testing SOA Functional Requirements . . . . . . . . . . . . . . . . . . . . 642.5.1 SOA Web Service Testing . . . . . . . . . . . . . . . . . . . . . . 642.5.2 Web Service Integration Testing . . . . . . . . . . . . . . . . . . . 662.5.3 SOA Registry/UDDI Testing . . . . . . . . . . . . . . . . . . . . . 672.5.4 ESB Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682.5.5 SOA System Testing . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3 Review of Related Work 703.1 Static Slicing of Object-Oriented Software . . . . . . . . . . . . . . . . . . 703.2 Dynamic Slicing of Object-Oriented Software . . . . . . . . . . . . . . . . 713.3 Black-box Testing of Service-Oriented Software . . . . . . . . . . . . . . . 75

3.3.1 Testing Tools For Web Services . . . . . . . . . . . . . . . . . . . 773.3.2 Model-based Testing of Service-Oriented Software . . . . . . . . . 81

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4 Static Slicing of Service-Oriented Software 894.1 Basic Concepts and Definitions . . . . . . . . . . . . . . . . . . . . . . . . 90

4.1.1 Service Architecture and Web Services . . . . . . . . . . . . . . . . 904.1.2 Some Important Definitions . . . . . . . . . . . . . . . . . . . . . 92

4.2 Service Interface Dependency Graph (SIDG): Our Proposed IntermediateRepresentation of Service Interface Model . . . . . . . . . . . . . . . . . . 924.2.1 Properties of Service Interface Dependency Graph (SIDG) . . . . . 93

4.3 Computing Static Slices of Service-Oriented Software from SIDG . . . . . 93

ii

4.3.1 The SSSIM Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 944.3.2 The SIDG Example . . . . . . . . . . . . . . . . . . . . . . . . . . 954.3.3 Complexity Analysis of SSSIM Algorithm . . . . . . . . . . . . . . 964.3.4 Working of SSSIM Algorithm . . . . . . . . . . . . . . . . . . . . 964.3.5 Correctness of SSSIM Algorithm . . . . . . . . . . . . . . . . . . . 97

4.4 Implementation and Experimental Results . . . . . . . . . . . . . . . . . . 984.4.1 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.5 Comparison with Related Work . . . . . . . . . . . . . . . . . . . . . . . . 1014.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5 Dynamic Slicing of Service-Oriented Software 1025.1 Service-Oriented Software Example: Online Shopping System . . . . . . . 103

5.1.1 Mapping of Service Choreography Message With Web Service . . . 1065.2 Basic Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.3 Service-Oriented Software Dependence Graph (SOSDG): Our Intermediate

Representation of Service-Oriented Software . . . . . . . . . . . . . . . . . 1125.4 Marking Based Global Dynamic Slicing (MBGDS) Algorithm . . . . . . . 114

5.4.1 Overview of the MBGDS Algorithm . . . . . . . . . . . . . . . . . 1145.4.2 Working of MBGDS Algorithm . . . . . . . . . . . . . . . . . . . 1195.4.3 Correctness of MBGDS Algorithm . . . . . . . . . . . . . . . . . . 1215.4.4 Salient Features of MBGDS Algorithm . . . . . . . . . . . . . . . 1215.4.5 Complexity Analysis of MBGDS Algorithm . . . . . . . . . . . . . 122

5.5 Implementation and Experimental Results . . . . . . . . . . . . . . . . . . 1235.5.1 SOSDS: An SOS Dynamic Slicing Tool . . . . . . . . . . . . . . . 1235.5.2 Design of SOSDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.5.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.5.4 Data Sets Used in Our Experiments . . . . . . . . . . . . . . . . . 1255.5.5 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.6 Comparison With Related Work . . . . . . . . . . . . . . . . . . . . . . . 1285.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6 Black-box Testing of Service-Oriented Software 1316.1 Black-box Testing of Web Services Through Program Slicing Artifacts . . . 131

6.1.1 Structure of WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . 1336.1.2 A Web Service Example: Greatest Common Divisor (GCD) . . . . 1366.1.3 Inherent Dependencies of WSDL . . . . . . . . . . . . . . . . . . . 1406.1.4 Black-box Testing of Web Service Using Extended WSDL . . . . . 1416.1.5 Extensible Element Web Service Description Graph <WSDG>: Our

Proposed Extension to WSDL Using XSD . . . . . . . . . . . . . . 1426.1.6 Implementation and Experimental Results . . . . . . . . . . . . . . 145

iii

6.1.7 Comparison With Related Work . . . . . . . . . . . . . . . . . . . 1506.2 Model-based Testing of Service-Oriented Software . . . . . . . . . . . . . 153

6.2.1 Approach 1: Testing of Service-Oriented Software Using BPMN Di-agram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.2.2 Approach 2: Testing of Service-Oriented Software Using SoaMLService Interface Diagram . . . . . . . . . . . . . . . . . . . . . . 166

6.2.3 Comparison With Related Work . . . . . . . . . . . . . . . . . . . 1726.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

7 Conclusions 1767.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

7.2.1 Static Slicing of Service-Oriented Software . . . . . . . . . . . . . 1787.2.2 Dynamic Slicing of Service-Oriented Software . . . . . . . . . . . 1797.2.3 Black-box Testing of Service-Oriented Software . . . . . . . . . . . 1797.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

References 183

Appendices 206

iv

List of Abbreviations

AMSMT: Architectural Model Slicing through MDG Traversal

ASF: Apache Software Foundation

ADL: Architectural Description Language

ATGSD: Automatically Test Sequences Generation from Sequence Diagram

BP: Basic Profile

BSP: Basic Security Profile

B-Model: Behavior Model

BAS: Bookshop Automation Software

BFS: Breadth First Search

BPD: Business Process Diagram

BPM: Business process modeling

BPMN: Business Process Modeling Notation

COD: Cash On Delivery

CC: Common Components

CD: Communication diagram

CCFG: Concurrent Control Flow Graph

CFG: Control Flow Graph

DFS: Depth First Search

DSAS: Dynamic Software Architecture Slicing

DOM: Document Object Model

DTD: Document Type Definition

EFSM: Extended Finite State Machine

ESB: Enterprise Service Bus

v

GPL: General Public License

GUI: Graphical User Interface

GCD: Greatest Common Divisor

HAS: Hotel Automation Software

HRS: House Rental Software

JIS: Judiciary Information System

LGPL: Lesser General Public License

LIS: Library Information System

LOT: Lines of Tag

LTL: Linear Temporal Logic

MBGDS: Marking Based Global Dynamic Slicing

MSAS: Medicine Shop Automation Software

MEP: Message Exchange Pattern

MDG: Model Dependency Graph

MPSS: Motor Parts Shop Software

MGCAS: Municipalty Garbage Collection Automation Software

OCL: Object Constraint Language

OMG: Object Management Group

OSS: Online Shopping System

OWL: Web Ontology Language

OFS: Order Fulfillment Service

OASIS: Organization for the Advancement of Structured Information Standards

PDG: Program Dependence Graph

POS: Purchase Order Service

QoS: Quality of Service

vi

RRS: Railway Reservation Software

REST: Representational State Transfer

RQ: Research Question

RDF: Resource Discovery Framework

RAS: Restaurant Automation System

RRTS: Road Repair and Tracking System

SADG: Software Architectural Dependency Graph

SDT: Sequence Dependency Table

SDG: Sequence Diagram Graph

ATGSD: Sequences Generation from Sequence Diagram

SCEH: Service Choreography Execution History

SEC: Service Execution Case

SEH: Service Execution History

SEP: Service Execution Point

SI: Service Interface

SIDG: Service Interface Dependency Graph

SLA: Service Level Agreement

SoaML: Service oriented architecture Modeling Language

SUT: Service Under Test

SOA: Service-Oriented Architecture

SOC: Service-Oriented Computing

SOS: Service-Oriented Software

SOSC: Service-Oriented Software Choreography

SOSDG: Service-Oriented Software Dependence Graph

SOAP: Simple Object Access Protocol

vii

SADG: Software Architectural Dependency Graph

SCCS: Software Component Cataloguing Software

SaaS: Software-as-a-Service

SSSIM: Static Slicing of Service Interface Model

SCG: Structured Composite Graph

SAMS: Students Auditorium Management Software

SAS: Supermarket Automation Software

STDG: Synchronous Threaded System Dependence Graph

SDG: System Dependence Graph

STG: System Testing Graph

tModel: technical Model

TCGA: Test Case Generation Algorithm

UIG: UML interaction graph

UML: Unified Modeling Language

UDDI: Universal Description Discovery and Integration

UDG: Use case Diagram Graph

UTG: UML behavioral Test case Generator

WS-BPEL: Web Service Business Process Execution Language

WS-CDL: Web Service Choreography Description Language

WSCFG: Web Service Control Flow Graph

WSDG: Web Service Description Graph

WSDL: Web Service Description Language

WWW: World Wide Web

W3C: World Wide Web Consortium

WS-I: Web Service Interoperability

viii

XMI: XML Metadata Interchange

XSD: XML Schema Definition

XSLT: eXtensible Stylesheet Language Transformations

ix

List of Tables

4.1 Average run-time and memory space requirements of SSSIM algorithm . . 100

5.1 Average run-time of MBGDS algorithm . . . . . . . . . . . . . . . . . . . 1275.2 Comparison with related work . . . . . . . . . . . . . . . . . . . . . . . . 129

6.1 Average run-time of web services . . . . . . . . . . . . . . . . . . . . . . . 1516.2 Comparison with related work . . . . . . . . . . . . . . . . . . . . . . . . 1526.3 Inputs, data types and restrictions of service or task . . . . . . . . . . . . . 1646.4 Test cases with output for the example “online shopping system (OSS)” . . 1656.5 Test case execution results for “online shopping system (OSS) ” using SoaML

service interface diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716.6 Comparison with some related work . . . . . . . . . . . . . . . . . . . . . 174

x

List of Figures

1.1 Static slice of a sample program . . . . . . . . . . . . . . . . . . . . . . . 31.2 Dynamic slice of a sample program . . . . . . . . . . . . . . . . . . . . . . 41.3 Backward slice of a sample program . . . . . . . . . . . . . . . . . . . . . 51.4 Forward slice of a sample program . . . . . . . . . . . . . . . . . . . . . . 51.5 Executable and closure slices with respect to g2 at line (17) . . . . . . . . . 61.6 Examples of amorphous static slices . . . . . . . . . . . . . . . . . . . . . 71.7 Service encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.8 Service relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.9 Service communications . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.10 Conceptual schema of the planned work referencing objectives 1, 2, 5 and 6 221.11 Conceptual schema of the planned work referencing objectives 3, 5 and 6 . 231.12 Conceptual schema of the planned work referencing objectives 4, 5 and 6 . 231.13 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1 An example program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2 The CFG of the example program given in Fig. 2.1 . . . . . . . . . . . . . 342.3 The PDG of the example program given in Fig. 2.1 . . . . . . . . . . . . . 362.4 An example program consisting of a main program and two procedures . . . 382.5 The SDG of the example program given in Fig. 2.4 . . . . . . . . . . . . . 392.6 An example program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.7 SOA layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.8 A higher level abstraction of SOA . . . . . . . . . . . . . . . . . . . . . . 492.9 Web service standardized protocol stack and WS-* extensions . . . . . . . 502.10 A hierarchy of software testing [39, 265] . . . . . . . . . . . . . . . . . . . 532.11 A software testing process model [265] . . . . . . . . . . . . . . . . . . . . 542.12 SOA testing challenges classification . . . . . . . . . . . . . . . . . . . . . 56

3.1 An example program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.2 The DODG of the program given in Figure 3.1 on input argv[1]=3 . . . . . 74

4.1 Class diagram of service architecture . . . . . . . . . . . . . . . . . . . . . 904.2 Class diagram of web service . . . . . . . . . . . . . . . . . . . . . . . . . 914.3 Class diagram of service interface dependency graph (SIDG) . . . . . . . . 93

xi

4.4 Service interface diagram of POS . . . . . . . . . . . . . . . . . . . . . . . 954.5 SIDG of POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.6 Marked SIDG showing the static slices w.r.t slicing criterion (a) Consumer

and (b) Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.7 Design of our tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.8 Static slices of POS w.r.t slicing criterion Consumer . . . . . . . . . . . . . 994.9 Average run-time of SSSIM algorithm w.r.t number of nodes . . . . . . . . 100

5.1 The SoaML sequence diagram for buying a product . . . . . . . . . . . . . 1055.2 A SoaML service contract diagram involving multiple parties . . . . . . . . 1065.3 A static mapping of service choreography messages with web services . . . 1075.4 The WSCFG of the service choreography given in Fig. 5.1 . . . . . . . . . 1105.5 The SOSDG of the service choreography given in Fig. 5.1 . . . . . . . . . 1135.6 The updated SOSDG of the service choreography given in Fig. 5.1 . . . . . 1205.7 Schematic design of SOSDS . . . . . . . . . . . . . . . . . . . . . . . . . 1245.8 Average run-time of MBGDS algorithm . . . . . . . . . . . . . . . . . . . 128

6.1 A web service interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336.2 Comparison of WSDL 1.1 and WSDL 2.0 . . . . . . . . . . . . . . . . . . 1346.3 Generated XSD of compute gcd web service . . . . . . . . . . . . . . . . . 1366.4 WSDL of compute gcd web service . . . . . . . . . . . . . . . . . . . . . 1376.5 compute gcd web service . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.6 NetBeans tester service to invoke compute gcd web service . . . . . . . . . 1396.7 SOAP response for compute gcd web service . . . . . . . . . . . . . . . . 1396.8 Inherent Dependencies of WSDL . . . . . . . . . . . . . . . . . . . . . . . 1406.9 Our proposed approach for black-box testing using extended WSDL . . . . 1416.10 Extended XSD design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.11 Extended XSD for compute gcd web service . . . . . . . . . . . . . . . . . 1446.12 The XML file and result of valid test case execution on extended schema . . 1456.13 Result of invalid test case execution on extended schema . . . . . . . . . . 1466.14 Extended WSDL schema design . . . . . . . . . . . . . . . . . . . . . . . 1466.15 Extended WSDL for compute gcd web service . . . . . . . . . . . . . . . . 1476.16 Result of valid test execution on extended WSDL . . . . . . . . . . . . . . 1486.17 Result of invoking service consumer for compute gcd web service . . . . . 1486.18 Average run-time of web services w.r.t line of tag . . . . . . . . . . . . . . 1506.19 Proposed testing approach . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.20 A BPMN diagram for “online shopping system (OSS)” . . . . . . . . . . . 1576.21 Exporting BPMN with bizagi modeler . . . . . . . . . . . . . . . . . . . . 1586.22 Control flow graph of “Online Shopping System (OSS)” . . . . . . . . . . 1606.23 A BPMN file fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

xii

6.24 Internal data structure of XML DOM parser . . . . . . . . . . . . . . . . . 1626.25 SoaML service interface diagram for “online shopping system (OSS)” . . . 1666.26 XML schema or instant generation for “online shopping system (OSS)” . . 1676.27 Generated XML schema for “online shopping system (OSS)” . . . . . . . 1676.28 Instance generation in XML schema . . . . . . . . . . . . . . . . . . . . . 1686.29 A sample test case for XML schema instance . . . . . . . . . . . . . . . . 169

7.1 Use case diagram for our achievements . . . . . . . . . . . . . . . . . . . 176

xiii

CHAPTER - 1

Introduction

Program slicing is a method of separating out the relevant parts of a program with respect toa particular computation. Thus, a slice of a program is a set of statements of the program thataffects the value of a variable at a particular point of interest. Program slicing was originallyintroduced by Mark Weiser [140] as a method for automatically decomposing programs byanalyzing their data flow and control flow dependencies starting from a subset of a pro-gram’s behavior. Slicing reduces the program to a minimal form that still produces the samebehavior. The input that the slicing algorithm takes is usually an intermediate representationof the program under consideration [263]. Normally, the intermediate representation of theprogram under consideration is a graph.

The first step in slicing a program involves specifying a point of interest, called the slicing

criterion, which is expressed as (s, v), where s is the statement number and v is the variablethat is being used or defined at s. Since the last couple of decades, the area of program slicinghas been enriched by contributions from several researchers. Since its inception by MarkWeiser [140] as a debugging aid, many new techniques have evolved to enhance the accuracy,preciseness, and speed up of the process of slicing and to make program slicing usable indifferent applications. The technique of program slicing has evolved to handle unstructuredand multi-procedure programs, structured as well as object-oriented, aspect-oriented, andfeature-oriented programs. Also, these slicing techniques have found application in diverseproblem areas such as software testing, debugging, software maintenance, understanding,code reuse, software refactoring, change impact analysis, coupling measurement etc. [71,78, 79, 91, 127, 148, 149, 215, 216, 261].

Service-oriented architecture (SOA) is an architectural style for designing and devel-oping distributed systems. Drivers for SOA adoption are easy and flexible for integrationwith legacy systems, streamlined business processes, reduced costs, and ability to handlerapidly changing business processes. From architectural and QoS parameters perspective,these drivers usually translate to interoperability and modifiability, which are achieved by

1

adhering to a set of architectural principles for service-oriented systems such as loose cou-pling, standardization, reusability, composability, and discoverability.

Testing of the service-oriented system is challenged by key factors like autonomy, het-erogeneity, and dynamism. These autonomous systems have services/resources in their owncontrol. The tester can request to test the system but may not force it to do so. Heterogeneitypromotes software architect to design and construct components in their ways but duringtesting, the tester needs to test a variety of levels from networking protocols, encoding ofinformation up to date formats. Dynamic service-oriented systems behave arbitrarily andmay or may not participate in the business process. With these characteristics, testing ofSOA-based applications is a difficult task because services may change their interfaces orbehaviour at runtime.

1.1 Types of Program Slice

Many different notions of program slices and slicing criteria have been proposed sinceWeiser’s definition [140] of a slice. The main reason for this diversity is the fact that variousapplications of program slicing have been investigated, and that each application requiresspecific properties of the slices.

In this section, we discuss the various types of program slices: static and dynamic slices,backward and forward slices, and executable and closure slices, intra-procedural and inter-procedural slices, structured and unstructured slices, amorphous program slice, software ar-chitecture slice, real-time program slice, conditioned slice, and UML model slice.

1.1.1 Static and Dynamic Slices

One of the criteria for classifying slices is to distinguish between static and dynamic slices.Static slices are computed without making any assumptions regarding the values of the vari-ables. A static slice with respect to a variable and a location includes all the statements thatcould possibly affect the computation of that variable at that location. In contrast, dynamicslicing makes use of the input of the program in order to reduce the size of the slice. In otherwords, we can say that dynamic slicing techniques compute precise slices. Fig. 1.1(b) showsa static slice of the sample program given in Fig. 1.1(a) with respect to slicing criterion <13, prod >.

2

(a) A sample program (b) Static slice with respect to slicing criterion <13, prod >

FIGURE 1.1: Static slice of a sample program

Dynamic slicing was first suggested by Korel et al. [29] as a means for locating the causeof a program fault that is revealed by a particular execution. A dynamic slice with respect to a

slicing criterion < s; V >, for a particular execution, contains those statements that actually

affect the slicing criterion in the particular execution. Therefore, dynamic slices are usuallysmaller than static slices and are more useful in interactive applications such as programdebugging and testing. In such a situation, only the program’s behaviour for a specific input,rather than for the set of all inputs, is of interest. The sequence of statements that haveactually been executed for the specific input is referred to as a trajectory or execution history.A trajectory differentiates each occurrence of the same statement. Typically a dynamic sliceis computed with respect to an input, a variable, and a position in the trajectory. Dynamicslicing cannot be used to reason about all the possible computations with respect to a variable,and this characteristic limits its application to debugging. Static slices are computed usingonly static information whereas dynamic slices are generally (but not necessarily) computedusing only dynamic information. However, Choi et al. [111], and Duesterwald et al. [65]reduce the amount of computations that have to be performed during the execution of theprogram, by using static information. Fig. 1.2(b) shows a dynamic slice of the sampleprogram given in Fig. 1.2(a) with respect to slicing criterion < 13, sum, i = 5 & n = 9 >.

3

(a) A sample program (b) Dynamic slice w.r.t slicing criterion < 13,sum, i = 5 & n = 9 >

FIGURE 1.2: Dynamic slice of a sample program

A number of hybrid approaches act as a bridge between the two extremes of static anddynamic slicing, by considering a set of executions. The notion of quasi-static slice in whichthe values of some inputs are fixed while the other inputs are not specified was proposed byVenkatesh [80]. For Field et al. [112] a slice where any subset of the inputs of the programmay be supplied is called a constrained slice. Ning et al. [113] have proposed the notion ofcondition-based slicing in which the inputs in the slicing criterion were characterized by alogical expression (for example age> 30).

1.1.2 Backward and Forward Slices

Backward slices are composed of statements and control predicates that are collected bytraversing backward. Thus, a static backward slice provides the answer to the question:“which statements affect the slicing criterion?”. Hence, these slices are called backwardslices. Fig. 1.3(b) shows a backward slice of the sample program given in Fig. 1.3(a) withrespect to slicing criterion < 7, i>.

4

(a) A sample program (b) Backward slice with respect to slicing criterion< 7, i >

FIGURE 1.3: Backward slice of a sample program

Forward slices consist of the statements, which could (potentially) be affected by a givenslicing criterion. A forward slice provides the answer to the question: “which statements will

be affected by the slicing criterion?”. This variation of program slicing was first introducedby Bergeretti et al. [114] who called it information propagation within a program. The word“forward” was first used by Reps et al. [223]. Fig.1.4(b) shows a forward slice of the sampleprogram given in Fig. 1.4(a) with respect to slicing criterion < 2, sum >. in Fig. 1.4(b).Unless otherwise specified, we consider backward slices throughout this thesis.

(a) A sample program (b) Forward slice with respect to slicing cri-terion < 2, sum >

FIGURE 1.4: Forward slice of a sample program

5

1.1.3 Executable and Closure Slices

FIGURE 1.5: Executable and closure slices with respect to g2 at line (17)

Slices can be either executable or closure. Executable slices are syntactically valid programs,which preserve the behaviour of the original program with respect to the slicing criterion.On the other hand, closure slices consist of the statements and control predicates of theprogram that directly or indirectly affect the values computed at the criterion, but that donot necessarily constitute executable programs. An example that illustrates the differencebetween executable and closure slices is shown in Fig. 1.5. Fig. 1.5(a) shows the originalprogram; Figs. 1.5(b)-(d) show the slices with respect to g2 at line (17). Fig. 1.5(b) is aclosure slice and Figs. 1.5(c)-(d) are executable slices [156], where procedure p is specializedinto two variants: p 1 and p 2.

1.1.4 Intra-procedural and Inter-procedural Slices

Intra-procedural slicing computes slices within a single procedure. Calls to other proceduresare either not handled at all or handled conservatively. The difficulty associated with inter-procedural slicing is to determine the inter-statement dependencies that exist between thestatements from the calling procedure and those from the called procedure and those inter-statement dependencies that result from the call-return execution path. Many reported work[87, 90, 152] have successfully addressed the problems associated with slicing of programsinvolving inter-procedure calls. For distributed programs, intra-procedural slicing is mean-ingless as practical distributed programs contain more than one method. So, for distributedprograms, inter-procedural slicing is more useful.

6

1.1.5 Unstructured Program Slice

For many applications, particularly where maintenance problems are the primary motivationfor slicing, the slicing algorithm must be capable of constructing slices from “spaghetti” pro-grams, written before the benefits of structured programming were fully appreciated. Thisis because of unstructured programming style using goto statement; all forms of jump state-ment, such as break and continue can be regarded as special cases of the goto statement.Such programs are said to exhibit arbitrary control flow and are considered to be “unstruc-tured”. The traditional program dependence graph based approach by Ottenstein et al. [177]incorrectly fails to include any goto statements in a slice.

1.1.6 Amorphous Program Slice

Whether or not a slice is executable or non-executable, it is traditionally computed by delet-ing statements from the original program. The resulting slice can be regarded as a reducedversion of the program. An effect minimal slice (later renamed amorphous slice) maintainsthe effect that the original program has upon the set of variables for which a slice is con-structed. A variant of this conventional concept of a slice was introduced by Harman etal. [153]. Harman et al. [157] defined q as an amorphous static slice of p with respect tothe slicing criterion (K, i) if and only if q is a (τ (K,i),vAS) projection of p, where τ (K,i) issyntax-preserving semantically equivalent slice and vAS is semantic equivalence relation.

Consider the example program fragments in Fig. 1.6. All the fragments are (τ (x,5))

equivalent to one another, but none is a traditional static slice of any of the others, as none isa syntactic subset of any of the others. However, since Program 1 contains fewer commandsthan Program 2, which contains fewer commands than Program 3, it can be concluded thatProgram 1 is a (τ (x,5),vAS) projection of Program 2 and that Program 2 is (τ (x,5),vAS)

projection of Program 3. Furthermore, Program 1 is a (τ (x,5),vAS) minimal projection ofPrograms 2 and 3 (and of itself), because no other (τ (x,5)) equivalent program has fewer com-mands. Amorphous static slicing is simply traditional static slicing with a relaxed simplicitymeasure, allowing, for example, Program 1 of Fig. 1.6 to be regarded as a slice of Programs2 and 3 of Fig. 1.6.

FIGURE 1.6: Examples of amorphous static slices

7

However, the slice does not have to be a subset of the original program, and transfor-mations that preserve the semantics of the slice are allowed. Amorphous slicing does notslice away statements from the original program, one can argue that it cannot be accepted asa slicing method in the strict sense of the terminology. However, the important property ofslicing, relied upon by all its applications, is the way it slices away semantic sub-componentsof the original program. Amorphous slicing is thus slicing in the semantic sense but not inthe syntactic sense.

1.1.7 Software Architectural Slice

Software architecture is receiving increasing attention as a critical design level for softwaresystems. As software architectural design resources (in the form of architectural specifi-cations) are going to be accumulated, the development of techniques and tools to supportarchitectural understanding, testing, reengineering, maintenance, and reuse will become animportant issue. Jianjun Zhao [101] introduced a new form of slicing, named architecturalslicing, to aid architectural understanding and reuse. In contrast to traditional slicing, archi-tectural slicing is designed to operate on the architectural specification of a software system,rather than the source code of a program. Architectural slicing provides knowledge aboutthe high-level structure of a software system, rather than the low-level implementation de-tails of a program. In order to compute an architectural slice, he presents the architectureinformation flow graph, which can be used to represent information flows in software archi-tecture. Based on the graph, he gives a two-phase algorithm to compute an architectural slice.Kim et al. [217] introduced the notion of dynamic software architecture slicing (DSAS). A

dynamic software architecture slice represents the run-time behavior of those parts of the

software architecture that are selected according to a particular slicing criterion such as a

set of resources and events. They also described a methodology for using the notion, andan algorithm to generate dynamic software architecture slices. The feasibility and the ex-pected benefits of the approach were demonstrated through a study of part of an electroniccommerce system and a run-time execution of its architecture using a tool.

1.1.8 Real-Time Program Slice

Gerber et al. [196] described an approach to scheduling which relies upon slicing to identifythe observable parts of a real-time system (those that interact with the environment throughI/O operations) and the unobservable components (those which do not perform I/O). Theunobservable computations need not fit within the time frame allocated to the task and aremoved to the end of the task’s computation, increasing its schedulability. The system mixes

8

slicing and the single transformation code motion, but it does simply to re-order computationand does not delete computations. Therefore, the system does not produce amorphous slices.

1.1.9 Conditioned Slice

The conditioned slice was introduced by Canfora et al. [38]. A conditioned slice consists

of a subset of program statements, which preserves the behaviour of the original program

with respect to a set of program executions. The set of initial states of the program thatcharacterizes this execution is specified in terms of first order predicate logic formula on theinput variable. Conditioned slicing allows a better decomposition of the program giving themaintainer the possibility to analyze code fragments with respect to different perspectives.

1.1.10 UML Model Slice

Lallchandani et al. [118] have proposed an approach to slice UML model. He described amodel slice as a selection of model elements from a model, or a part of a model selectedbased on a particular slicing criterion.

1.1.11 Aspect-Oriented Program Slice

Aspect-oriented programs work by providing an explicit mechanism for capturing the struc-ture of crosscutting concern in a software system. Specific aspect-oriented features suchas join points, advice, and the aspect that are different from existing procedural or object-oriented programming language. Zhao [117] describes how to slice such large aspect-orientedsoftware. Various researchers have put their effort in slicing variant of aspect-oriented pro-grams can be found in the literature [63, 126, 164].

1.2 Issues in Program Slicing

In this section, we discuss some of the major issues in the program slicing of service-orientedsoftware (SOS).

• Accuracy

An accurate slice as defined by Agrawal [87] is one which includes a statement of aprogram only when the value of the given variable at the given location is affected by

9

an occurrence of that statement. Although the concept of an accurate slice is simplein its description, determining whether or not a slice is accurate is not trivial. Fur-thermore, testing that an algorithm always computes accurate slices would require theelaboration of an infinite test set. No formal proof has been provided by the researchcommunity regarding the accuracy of slices.

• Intermediate Representation

In order to slice a service-oriented architecture (SOA)-based software, first, the pro-gram should be represented by a suitable intermediate representation. This intermedi-ate representation should correctly represent the service-oriented architecture (SOA)features such as higher level abstraction, interoperability, composability, loose cou-pling, autonomy, reusability, statelessness, extensibility, testability and dynamic bind-ing. A suitable intermediate representation in Chapter 4 for addressing higher level

abstraction feature using service call dependency and composite dependency is de-veloped. This intermediate representation is extended in Chapter 5 to represent in-

teroperability and composibility features of service-oriented architecture (SOA)-basedsoftware by introducing intra-service dependency and inter-service dependency. InChapters 6, suitable techniques for addressing testability features using semantic ele-ments are developed.

• Memory Requirement

The memory requirement for both the intermediate representation and the static ordynamic slicing algorithms should be as small as possible. Otherwise, the stored datawill run out of memory due to the large sizes of service-oriented architecture (SOA)-based software. Our intermediate representations and both static and dynamic slicingalgorithms are equivalent to the existing ones with respect to memory space require-ment.

• Time Requirement

The time requirement for any static or dynamic slicing algorithm should also be assmall as possible as the algorithm will be generally used in interactive applicationssuch as testing & debugging. Otherwise, the response time will be too large. Sincewe use program slicing as the basis for testing, we do consider time requirement asthe performance criterion to measure the efficiency of our static and dynamic slicingalgorithms. Even in the worst case, our algorithms perform equivalently to the existingones.

• Correctness

The slicing algorithms should compute correct static or dynamic slices with respect toany given slicing criterion. A slice is said to be correct if it contains all the statements

10

that affect the slicing criterion. We claim that each of the proposed static or dynamicslicing algorithms computes correct static or dynamic slices with respect to any givenslicing criterion.

• Scalability

The static or dynamic slicing algorithms should be developed in such a way that thealgorithms can easily be extended to handle large scale software as the size of service-oriented software (SOS) are very large, involving multiple partner web services. Ourstatic or dynamic slicing algorithms can easily be extended to handle such large andcomplex software.

1.3 Overview of Service-Oriented Architecture (SOA)

The emergence of service-oriented architecture (SOA) as an approach for integrating busi-ness applications that expose services, introduces many new challenges to organizations re-sulting in significant risks to their business. Particularly important among those risks arefailures to effectively address QoS requirements such as performance, reliability, availabil-ity, security, testability and modifiability. Because the risk and impact of SOA are distributedacross applications, it is critical to perform an architectural or model testing early in the soft-ware development life cycle.

Service-oriented architecture (SOA) is a very popular architecture paradigm for design-ing and developing distributed systems. The SOA solutions have been crafted to satisfybusiness goals that include easy and flexible integration with legacy systems, streamlinedbusiness processes, reduced costs, innovative service to customers, agile adaptation and re-action to opportunities and competitive threats.

One of the most important software engineering principles is phase containment error,which introduces checkpoints into the software development lifecycle phases. Software ar-chitecture testing is particularly important because architecture is the bridge between busi-ness goals and the software systems. Testing architecture or model that satisfies functionalas well as non-functional (QoS) requirements (e.g., availability, security, and performance)is vital to the success of the system. Early testing of the requirements and the architecturesave time and money.

In this section, we define service-oriented architecture (SOA), and service. Also wediscusse the important service characteristics along with various advantages associated withSOA.

11

1.3.1 What is Service-Oriented Architecture (SOA)?

There are many definitions of SOA but none is universally accepted. We define a few impor-tant ones as below.

• Erl [219] defines service-oriented architecture as a model in which automation logic isdecomposed into smaller, distinct units of logic. Collectively, these units comprise alarger piece of business automation logic. Individually, these units can be distributed .

• OASIS [176] defines service-oriented architecture as a paradigm for organizing andutilizing distributed capabilities that may be under the control of different ownershipdomains. It provides a uniform means to offer, discover, interact with and use capabil-ities to produce desired effects consistent with measurable preconditions and expecta-tions .

• Opengroup [209] defines service-oriented architecture as an architectural style thatsupports service orientation. Service-orientation is a way of thinking in terms of ser-vices and service-based development and the outcomes of services .

• Microsoft [154] defines service-oriented architecture as an architectural pattern incomputer software design in which application components provide services to othercomponents via a communications protocol, typically over a network. The principlesof service-orientation are independent of any vendor, product or technology.

Service-oriented architecture (SOA) is a novel way to design, develop, deploy systems, inwhich services are reusable business functions exposed via well-defined interfaces, a separa-tion of concern between the interface and its implementation, and service clients use servicefunctionalities from available service descriptions. The SOA infrastructure enables dynamicdiscovery, dynamic composition, and dynamic invocation of services. From a technical pointof view, SOA is an architectural style or design paradigm. Systems that are built based onthe SOA principles are called service-oriented systems.

1.3.2 What is Service?

The central pillar of service-oriented architecture (SOA) is the services. For an SOA, service

• is a reusable component.

• is self-contained, highly modular, autonomous business task.

12

• is a distributed component.

• has a published service interface.

• stresses interoperability.

• is discoverable.

• is dynamically bound.

1.3.3 Important Service Characteristics

• Service EncapsulationsThe services encapsulate logic within a distinct context. This context can be specificto a business task, a business entity, or some other logical grouping. The concernaddressed by a service can be small or large. Therefore, the size and scope of thelogic represented by the service can vary. Further, service logic can encompass logicprovided by other services. In this case, one or more services are composed into acollective.

As shown in Fig. 1.7, when building an automation solution consisting of services,each service can encapsulate a task performed by an individual step or a sub-processcomprised of a set of steps. A service can even encapsulate the entire process logic. Inthe latter two cases, the larger scope represented by the services may encompass thelogic encapsulated by other services.

FIGURE 1.7: Service encapsulation

13

• Service RelationsWithin SOA, services can be used by other services or other programs. Regardless,the relationship between services is based on an understanding that for services tointeract, they must be aware of each other. This awareness is achieved through the useof service descriptions. A service description in its most basic format establishes thename of the service and the data expected and returned by the service. The the mannerin which services use service descriptions results in a relationship classified as loosely

coupled. For example, Fig. 1.8 illustrates that service A is aware of service B becauseservice A has acquired B’s service description.

FIGURE 1.8: Service relations

• Service Communications

FIGURE 1.9: Service communications

After a service sends a message on its way, it loses control of what happens to the mes-sage thereafter. That is why we require messages to be fitted with enough intelligence to

14

self-govern their parts of the processing logic. Hence, messages, like services, should beautonomous and self-governing. Fig 1.9 shows message existing as an independent unit ofcommunication.

1.3.4 What is a Business Process?

Business processes are a defined set of tasks that produce specific capabilities or products.Each task is composed of one or more services that are integrated to form the process [64].

1.4 Advantages of Service-Oriented Architecture (SOA)

This list of common advantages of SOA is generalized and certainly not complete. It ismerely an indication of the potential that SOA can offer [219].

• Improved integration (and intrinsic interoperability)SOA can result in the creation of solutions that consist of inherently interoperableservices. Because of the vendor-neutral communications framework established byweb services-driven SOAs, the potential is there for enterprises to implement highlystandardized service descriptions and message structures. The net result is intrinsic in-teroperability, which turns a cross-application integration project into less of a customdevelopment effort, and more of a modeling exercise.

• Inherent reuseService-orientation promotes the design of services that are inherently reusable. De-signing services to support reuse from the get-go opens the door to increased oppor-tunities for leveraging existing automation logic. Building service-oriented solutionsin such a manner that services fulfill immediate application-level requirements whilestill supporting the degree of reuse by future potential requesters establishes an envi-ronment wherein investments into existing systems can potentially be leveraged andre-leveraged as new solutions are built.

• Streamlined architectures and solutionsThe concept of composition is another fundamental part of SOA. It is not, however,limited to the assembly of service collections into aggregate services. The WS-* plat-form is based in its entirety on the principle of composability. The reduced perfor-mance requirements mentioned previously only refer to the fact that SOA extensionsare composable and therefore allow each application-level architecture to contain ex-tensions only relevant to its solution requirements.

15

• Leveraging the legacy investmentThe industry-wide acceptance of the web services technology set has spawned a largeadapter market, enabling many legacies environments to participate in service-orientedintegration architectures. This allows IT departments to work toward a state of feder-ation, where previously isolated environments now can interoperate without requiringthe development of expensive and sometimes fragile point-to-point integration chan-nels.

• Establishing standardized XML data representationOn its most fundamental level, SOA is built upon and driven by XML. As a result, anadoption of SOA leads to the opportunity to fully leverage the XML data representa-tion platform. A standardized data representation format (once fully established) canreduce the underlying complexity of all affected application environments. For exam-ples the XML documents and accompanying XML schema definition (XSD) passedbetween applications or application components fully standardize format and typingof all data communicated. The result is a predictable and therefore easily extensibleand adaptable communications network. XML’s self-descriptive nature enhances theability for data to be readily interpreted by architects, analysts, and developers. Theresult is the potential for data within messages to be more easily maintained, traced,and understood.

• Focused investment on communications infrastructureBecause web services establish a common communications framework, SOA can cen-tralize inter-application and intra-application communication as part of standard ITinfrastructure. This allows organizations to evolve enterprise-wide infrastructure byinvesting in a single technology set responsible for communication.

• “Best-of-breed” alternativesBecause SOA establishes a platform-neutral communications framework, it frees ITdepartments from being chained to a single proprietary development and/or middle-ware platform. For any given piece of automation that can expose an adequate serviceinterface, you now have a choice as to how you want to build the service that imple-ments it.

• Organizational agilityAgility is a quality inherent in just about any aspect of the enterprise. Much of service-orientation is based on the assumption that what you build today will evolve over time.One of the primary benefits of a well-designed SOA is to protect organizations fromthe impact of this evolution. When accommodating change becomes the norm in dis-tributed solution design, qualities such as reuse and interoperability become common-place. The predictability of these qualities within the enterprise leads to a reliable

16

level of organizational agility. However, all of this is attainable through proper designand standardization. Regardless of what parts of service-oriented environments areleveraged, the increased agility with which IT can respond to a business process ortechnology-related changes is significant.

1.5 Research Problem Definition

The research problem that we are going to address in our work can be formulated by raisingvarious questions as mentioned below:

• Research Hypothesis:

“Can program slicing be applied to test service-oriented software using service ori-ented architecture modeling language (SoaML) or business process modeling notation(BPMN) models ”?

• Research Assumption(s):

Nil

• What is the problem?The research problem can be defined by raising various research questions (RQs) anddefining the expected outcome as given below:

– Research Questions:

∗ RQ1: What are the problems related to the testing service-orientedarchitecture (SOA)-based software?

∗ RQ2: What are the benefits related to the testing service-oriented ar-chitecture (SOA)-based software?

∗ RQ3: What will be the process of testing it?

∗ RQ4: How effective will the proposed testing approach be for an orga-nization in terms of addressing the problems?

– Expected outcomes:

In general, the expected outcome of our research work will be a new technique orapproach, and knowledge acquisition which address the issues of testing service-oriented architecture (SOA)-based software. In particular, the final researchwork will include the following outcomes:

17

∗ Problems associated with testing service-oriented architecture (SOA)-basedsoftware.

∗ Advantages related to the testing service-oriented architecture (SOA)-basedsoftware.

∗ Development of some techniques for testing service-oriented architecture(SOA)-based software.

∗ Implementing the proposed testing approach/technique in an organization.

∗ The evaluation results of implementing the proposed test approach/tech-nique in an organization.

• Where is the problem?

The problem lies in testing service-oriented architecture (SOA)-based software.

• How to solve the problem?

The problem can be addressed by devising suitable intermediate representations usingSoaML or BPMN models and testing through program slicing technique.

• Why you want to solve the problem?

It helps the tester or IT vendors to test service-oriented architecture (SOA)-based soft-ware early in the design phase, so the cost of detecting and correcting errors will beless compared to error detection at coding phase.

• Is the problem current?

Yes, and can affect other parent software like cloud-based software too.

• Will the problem continue in the future if it is not solved? No.

• Who is suffering from that problem?

Software testers, IT vendors and other stakeholders.

• Will this improve or disprove the existing knowledge?

Yes, it will improve the existing knowledge.

1.6 Motivation for Our Research Work

SOA has started gaining importance in this competitive world of business and cloud-basedapplications. The research community along with IT vendors have started substantially con-tributing to the fast adoption of SOA in the business world.

18

Between 2005 and 2007, multiple surveys were conducted by organizations such as For-rester, Gartner, and IDC, which showed that the top drivers for SOA adoption were mainlyinternally focused: these top drivers generally included application integration, data integra-tion, and internal process improvement. This is changing. Forrester [73] showed that thenumber of organizations currently using SOA for external integration is approximately one-third of the surveyed organization [73]. While the percentage of externally focused SOAapplications is still a minority, this percentage has been growing and the trend will continueas organizations look at SOA adoption for supply-chain integration, access to real-time data,and cost reduction through the use of third-party services via the cloud or software-as-a-

service (SaaS).

All major IT vendors, a few names, such as IBM, Tibco, Software AG, Sun Oracle,SAP and so on have made huge investments into SOA in recent years, making up a globalestimated budget of $2 billion in 2007, which is further expected to rise and reach $9.1 billionby 2014 [95]. Even, corporate giants like Microsoft, IBM, Sun Oracle, SAP, Infosys havealready proposed their own SOA solutions and related software products. They have alsorolled out many success stories by implementing SOA in varied organizations. Even thereare major SOA failures reported across the globe.

The current year 2016 is a big boost for SOA as many e-commerce companies adoptedSOA for their business processes. This has helped immensely to improve agility and businessintegration. This also gives an indication that we need more reliable SOA-based systems andtheir testing is inevitable.

But still, the challenges are live like standardization of architectures, increased businessagility, flexibility, reuse, data rationalization, integration, testing, error handling, security,costs reduction, and so on. Different SOA frameworks being used in the enterprise sectorface mainly integration challenges to put together data, business process, security, and stake-holders. All these raise a vital issue of quality of SOA-based software. There is a need forSOA-based software to be testable across different enterprise applications giving emphasizeon quality.

Web services can be offered within organizational borders in private SOA deployments,as well as across organizational borders by third party providers. Recent years have seenan increasing number of web services made available over the internet by various serviceproviders. As a consequence, the issues of trust and dependability on third-party providershave been receiving increasing importance. Service requesters need to ensure that providedweb services satisfy their requirements in different aspects and that they have also beencorrectly implemented, before integrating them into their systems.

Web services are a concrete implementation of the SOA concept. They incorporate appli-

19

cations that provide a set of operations accessed by other applications through the Internet,using XML standards such as SOAP, WSDL, and UDDI. This technology enables to inter-connect different enterprises and to build complex business applications which are used insafety critical environments. SOA and web services add new factors that need to be con-sidered during software development. Hence, it goes without saying that web services thatsupport SOA implementation opens up a lot of scope for testing.

One problem with the current standard for web service description language (WSDL) isthat it lacks support for service interface descriptions beyond the external interface of op-eration signatures. WSDL descriptions lack the means to specify the testing support of aweb service so that requesters are aware of the exact behaviour expected from the consumedservice. Therefore, different standards or languages are required to describe the additionalfunctional and non-functional web service aspects, including its behaviour to support testa-bility.

To the best of our knowledge, a few SOA testing methodologies have been reported.For example according to Canfora et al. [75], SOA testing must span several levels, fromindividual services to inter-enterprise federations of systems and must cover functional andnon-functional aspects. SOA has a unique combination of features, such as the run-timediscovery of services, ultra-late binding, QoS-aware composition, and SLA automated nego-tiation [76]. Run-time discovery and ultra-late binding entail that the actual configuration ofa system is known only during the execution and this may make many existing integrationstesting techniques inadequate [76].

Last but not the least, distribution, lack of control and observability, dynamic integra-tion with other applications, and XML standards usage are key features of this new type ofsoftware. In this context, software testing is essential to guarantee a high degree of servicequality and reliability.

So, there is a pressing necessity to devise a testing approach for SOA-based software.We also notice that testing approaches have been changed from traditional applications toobject-oriented applications and must be changed for SOA-based software too. We havegiven kind attention to this aspect.

With this motivation for developing techniques for testing SOA-based software, in thenext section, we identify the major goals of this thesis.

20

1.7 Goals and Objectives of Our Research Work

The main goal of our research work is to test SOA-based software through program slicingtechnique during design, testing and maintenance phases of software development lifecycle.To address this broad objective, we identify the following goals:

1. We first wish to compute static slices of SOA-based software using SoaML models,for this we want to develop:

• Suitable intermediate representations for SOA-based software on which the slic-ing algorithms can be applied.

• Static slicing algorithms for SOA-based software using the proposed intermedi-ate representation.

2. Then, we wish to extend this approach for computing dynamic slices of SOA-basedsoftware, as dynamic slices are useful for interactive applications such as testing &debugging.

3. Next, we aim to test web services from its WSDL using program slicing artifacts i.edependence graph.

4. At last, we aim to propose an approach to test SOA-based software using BPMN andSoaML models.

5. In addition to investigating our slicing algorithms and testing algorithms, theoretically,we wish to implement all the proposed algorithms experimentally for verifying theirperformance, correctness, and preciseness.

6. Finally, we plan to carry out an analysis of our experimental studies to draw broadconclusions about the realized work for time and space requirements.

Fig. 1.10 presents a conceptual schema of our work targeted towards meeting the afore-mentioned objectives. It shows that a key component of our work focuses on representationof SoaML models that is suitable for model slicing. The conceptual schema depicted inFig. 1.10 comprises four blocks viz., input, algorithm, implementation, and output respec-tively. The input block depicts the different inputs to be given, namely, a SoaML model anda slicing criterion, that can be given to the algorithm block. Moreover, a SoaML systemdesign is supposed to be given input using the interfaces, contracts, participants, choreogra-phies, and architectures models. Next, the box titled “proposed technique” represents the

21

Interfaces

Choreographies

Contracts

Participants

Architectures

Proposed Technique

Model Slicing

Prototype Tool

Model Slicer

Intermediate

Static

Dynamic

Representation

ModelSlice

ModelSlice

SoaML

Model

Input

Slicing

Criterion

Algorithm Implementation Output

FIGURE 1.10: Conceptual schema of the planned work referencing objectives 1, 2, 5 and 6

algorithm block depicting that this thesis deals with proposing model slicing algorithms.Further, the implementation block indicates that the experimental studies presented in thisthesis are carried out through the development of different prototype tools. This is repre-sented using a box titled “prototype tool” for the corresponding technique proposed in thealgorithm block. Subsequently, the output block shows the expected outcome from the the-sis work viz., intermediate representation, static and dynamic model slices. In the context ofthe above-identified objectives for our work, the block marked algorithm in the conceptualschema corresponds to the Objectives 1, 2 while the implementation block corresponds tothe Objectives 6, 7.

Next, Fig. 1.11 presents a conceptual schema of our work targeted towards meeting theaforementioned objectives. It shows that a key component of our work focuses on web ser-vice description language (WSDL) that is suitable for black-box testing. The conceptualschema depicted in Fig. 1.11 comprises four blocks viz., input, technique/approach, imple-mentation, and output respectively. The input block depicts the different inputs to be given,namely, a WSDL, XSD, and a test case, that can be given to the technique/approach block.Moreover, an SOA-based software is supposed to be given input using the SOA artifactssuch as XML, XSD, WSDL, SOAP, and UDDI. Next, the box titled “proposed technique”represents the algorithm block depicting that this thesis deals with proposing an extensionto WSDL using XSD. Further, the implementation block indicates that the experimentalstudies presented in this thesis are carried out through the testing tools. This is representedusing a box titled “open source testing tool” for the corresponding technique proposed inthe technique/approach block. Subsequently, the output block shows the actual results fromexecuting test cases. In the context of the above-identified objectives for our work, the block

22

XSD

WSDL

XML

UDDI

SOAP

Proposed Technique

Extended WSDL

Open Source Testing Tool

Actual

Output

SOA

Artifacts

Input

Test Case

Technique/Approach Implementation Output

FIGURE 1.11: Conceptual schema of the planned work referencing objectives 3, 5 and 6

marked technique/approach in the conceptual schema corresponds to the Objectives 3 whilethe implementation block corresponds to the Objectives 5, 6.

Interfaces

BPMN

Contracts

Participants

Architectures

Proposed Technique

CFG Generation Test Path Generation

Test Case Result

Model

Input Algorithm & Implementation Output

Choreography

XSD Shema XSD Schema

Instance GenerationGeneration

Test Case Result

Test Case

Execution

FIGURE 1.12: Conceptual schema of the planned work referencing objectives 4, 5 and 6

Further, Fig. 1.12 presents a conceptual schema of our work targeted towards meeting theaforementioned objectives. It shows that a key component of our work focuses on SoaMLand BPMN models. The conceptual schema depicted in Fig. 1.12 comprises three blocksviz., input, algorithm & implementation, and output respectively. The input block depicts thedifferent inputs to be given, namely, a SoaML service interface diagram and BPMN diagramthat can be given to the algorithm&implementation block. Next, the box titled “proposed

23

technique” represents the algorithm block depicting that this thesis deals with proposing CFGgeneration, test path generation, XSD schema generation, XSD schema instance generation,and test case execution respectively for each model. Subsequently, the output block showsthe test result from this technique. In the context of the above-identified objectives for ourwork, the block marked algorithm&implementation in the conceptual schema correspondsto the Objectives 4, 5, and 6.

1.8 Scope of Our Research Work

The scope of our work will be limited up to service-oriented software testing. It includeswhich aspects of SOA-based software should be tested (specification/model/code), the ele-ments to be tested (web service, web service description language (WSDL), XML schema(XSD), universal description discovery and integration (UDDI), simple object access proto-col (SOAP)) and other XML artifacts produced during the testing effort. Also, it includestesting strategies for the unit, integration, and systems-level testing of SOA based web ser-vices (for both functional and non-functional attributes).

This means that instead of covering small pieces of testing SOA software developmentprocess, we preferred to advance as far as possible on slicing and testing SOA-based softwarewith the aim of being able to present convincing solutions to the SOA challenges discussedin Section 2.4. Without a doubt, slicing and testing service-oriented software are complexproblems as well and deserve to be investigated intensively, which has been done in the scopeof this thesis.

1.9 Original Contributions of Our Research Work

In this research work, we have made progress in the field of slicing and testing service-oriented software. We have developed novel techniques for solving the previously listedchallenges and implemented software prototypes to prove the applicability of our concepts.The most significant contributions and achievements are as follows:

• A simple technique for static slicing of SOA-based software, based on an intermediaterepresentations.

• A technique for dynamic slicing of SOA-based software, using an intermediate repre-sentations.

24

• An approach for testing SOA-based software, based on WSDL which provides busi-ness flexibility.

• Some approaches for testing SOA-based software using BPMN and SoaML models.

Moreover, we have published the software prototype as open-source, as a contribution to theresearch community.

1.10 Evaluation of Our Contributions

The presentation of novel concepts always requires an evaluation in order to prove theirapplicability, usefulness, and correctness. Depending on the type of concepts, different typesof evaluations make sense to be applied. For this work, however, the evaluation was nottrivial.

We have performed a comparative evaluation, by matching our approach to other avail-able ones, in order to prove applicability of our proposed concepts. This is mainly due tothe novelty of our work and the lack of direct competitors. Also, we have not done a pre-cise performance evaluation, as our contribution is not about performance issues nor does itprove the quality of our approach in any case. It would merely assess the applicability of ourprototype implementation, which is primary importance being a proof of concept.

Without a doubt, a real-world evaluation, where our concepts and prototypes are appliedin real SOA development projects would make the most sense and give valuable insightsinto how much the testing process got improved by our contribution. Unfortunately, this wasnot possible as (i) we did not have access to test a significant number of real-world SOAprojects and (ii) it would have been not easy to convince the testers to apply our prototypeimplementation in their work.

Instead, we evaluated our concepts in a selective manner, choosing what we regardedas reasonable and realizable case studies. For instance, we included a test case generationtechnique which deals with generating test cases at design time from SoaML service interfacediagrams. In contrast to that, we tested SOA-based software at the run-time, which has asignificant effect on test results. Moreover, we applied our approach to several standardizedcase study projects for an internal assessment and as a proof of usability of the prototypeimplementation.

25

1.11 Research Methodology

The term methodology refers to the overall approaches and perspectives of the research pro-cess as a whole. A preliminary total of four research questions is proposed for our researchwork. The answer to each research question is associated with proper selection of researchmethods.

• Qualitative MethodsThe qualitative part of the research deals with the participatory knowledge claims,open-ended interviewing and narrative design. First, the knowledge participates forfinding the related problems through literature and interviews along with designingthe narrative solution for the problem.

The RQ1, RQ2, and RQ3 will be answered through interviews and literature review,which will identify the problems and benefits related to testing SOA-based software.In addition, the process will be defined after analyzing the results of RQ1, RQ2, andRQ3.

• Quantitative MethodsThe quantitative part of the research deals with the experimental strategy of testingSOA-based software, results, and their comparisons. First, the study defines the testingprocess and then collects/creates the data to observe the testing process. To evaluatethe defined testing approach in the qualitative part, experimentation is needed for theevaluation of its effectiveness in order to answer RQ3 and RQ4. The design of theexperiment has been finalized after having a discussion with the supervisor. Experi-ments have been performed and demonstrated to the supervisor. Even the results areproduced for comparison with related work.

• Research Question Methodology

– RQ1: Literature Review

– RQ2: Literature Review

– RQ3: Interview/Experiment

– RQ4: Experiment

Finally, we announce our data formulation process required for our work by raising var-ious questions as mentioned below:

• Why did you collect certain data?

26

• What data you collected?

• From where you collected it?

• How you collected it?

• How you analyzed it?

The main research methodologies to generate data for our testing purpose can be linked totwo approaches named positivistic research and phenomenological research. The positivisticresearch approach includes surveys, experimental studies, longitudinal studies, and cross-sectional studies. The phenomenological research approach includes case studies, actionresearch, ethnography, participative inquiry, feminist perspectives, and grounded theory.

For our research work, we have followed the following specific methodologies whichhave been selected from both positivistic and phenomenological research approaches:

• Descriptive survey is concerned with identifying and counting the frequency of a par-ticular response among the survey group.

• Analytical survey is used to analyze the relationship between different elements (vari-ables) in a sample group.

• Experimental studies are carried out in carefully controlled and structured environ-ments and enables the causal relationships of phenomena to be identified and analyzed.The variables can be manipulated or controlled to observe the effects on the subjectsstudied.

• Longitudinal studies are carried out over an extended period to observe the effect thattime has on the situation under observation and to collect primary data (data collectedat first hand) of these changes.

• Case studies offer the opportunity to study a particular subject and usually involvesgathering and analyzing information. Information may be both qualitative and quanti-tative. Case studies can be used to formulate theories or, be:

– Descriptive (e.g. where current practice is described in detail)

– Illustrative (e.g. where the case studies illustrate new practices adopted by anorganization)

– Experimental (e.g. where difficulties in adopting new practices or proceduresare examined)

27

– Explanatory (e.g. where theories are used as a basis for understanding and ex-plaining practices or procedures)

1.12 Outline of the Thesis

The rest of the thesis is organized into chapters as follows.

Chapter 2 discusses the basic concepts related to program slicing, service-oriented ar-chitecture (SOA), and software testing which are used in the rest of the thesis. We discusssome graph-theoretic concepts and definitions which will be used later in our algorithms.Then, we discuss some intermediate program representation concepts which are used in slic-ing techniques. Then, we discuss the concepts of precision and correctness of a dynamicslice. Further, we discuss service-oriented architecture (SOA) layers and its architecturalprinciples. Finally, we discuss software testing.

Chapter 3 provides a brief review of the related work relevant to our contribution. Inthis chapter, we first discuss the work on static slicing of service-oriented software. Then,we discuss the work on dynamic slicing of service-oriented software. Further, we discussthe related work on white-box testing of web services. Finally, we discuss the work reportedon WSDL based testing and model-based test case generation technique.

Chapter 4 presents our static slicing algorithm for service-oriented software using ser-vice oriented architecture modeling language (SoaML) service interface diagram. We firstdiscuss some definitions related to static slicing. This is followed by the proposal of anintermediate representation for service-oriented software named SIDG (service interface de-pendency graph) and then a static slicing algorithm SSSIM (static slicing of service interfacemodel) along with its pseudocode. A complexity analysis for SSSIM is next presented.Finally, we present an implementation of our prototype tool and discuss the experimentalresults obtained using the prototype tool.

Chapter 5 presents our dynamic slicing algorithm for service-oriented software usingservice oriented architecture modeling language (SoaML) choreography diagram. We intro-duce few basic concepts and definitions pertinent to the dynamic slicing of service-orientedsoftware. We first develop an intermediate representation of service-oriented software calledSOSDG (service-oriented software dependence graph) and then present the dynamic slic-ing algorithm MBGDS (marking based global dynamic slicing) along with its pseudocode.The complexity analysis of MBGDS is next discussed. Subsequently, based on our MBGDSalgorithm, we describe a prototype tool implementation named SOSDS (service-orientedsoftware dynamic slicer). We also present the experimental results obtained in slicing sev-

28

eral SoaML models using SOSDS. We claim that our algorithm MBGDS computes correctdynamic slices.

Chapter 6 reports our approaches for carrying out black-box testing of service-orientedsoftware. In the first technique of black-box testing, we first present fundamentals of webservice description language (WSDL) document, which describes the service interface and isof prime focus for black-box testing. Next, we present our proposal of extending the WSDLdocument. Then, we describe the proof of our extension by carrying out black-box testingusing various WSDL data sets. Finally, we claim that our extension increases testability ofweb services without violating the architectural principles of services.

Secondly, we present novel approaches to test service-oriented software using BPMNand SoaML models. First, we describe our testing algorithm for service-oriented softwareusing BPMN (business process modeling notation) diagram. In this approach, we present aCFG generation algorithm and its implementation. Subsequently, we discuss the test pathand test case execution for the generated CFG. In the second approach, we present anotheralgorithm for testing service-oriented software using SoaML (service oriented architecturemodeling language) service interface diagram. In that context, we discuss the XML schemageneration and its instance generation process. Finally, we discuss the test case execution ofXML schema instance.

Chapter 7 concludes the thesis with a summary of our contributions. Finally, we discussthe possible future extensions to our work.

The work flow diagram of the complete thesis is shown in Fig. 1.13.

Service-Oriented Architecture,

Slicing of SOA-based Software

Testing of SOA-based Software

Broad Conclusion

Chapter 1

Introduction

Chapter 2

Basic Concepts

Chapter 3

Review of

Related Work

Chapter 4

Static Slicing of

Service-Oriented

Software

Chapter 5

Dynamic Slicing of

Service-Oriented

Software

Chapter 7

Conclusion andFuture Work

Program Slicing,

SLICING OF SOA-BASED SOFTWARE AND ITS APPLICATION TO TESTING

Chapter 6

Black-box Testing

Service-OrientedSoftware

of

Software Testing

FIGURE 1.13: Thesis outline

29

CHAPTER - 2

Basic Concepts

The area of program slicing has been enriched over the last two decades by contributionsfrom several researchers. Since its inception many new concepts have been introduced tospeed up the process of slicing, the precision of slices, and to make program slicing usablein different applications. The technique of program slicing has been extended to sequen-tial, non-sequential multi-procedure programs, as well as object-oriented programs, dis-tributed programs, concurrent programs, web applications, aspect-oriented programs, andUML (Unified Modeling Language) models. Also, these slicing techniques have been ap-plied to diverse problem areas. Some of the important applications of slicing have beendiscussed in Section 2.1.6 of this chapter.

This chapter provides a detailed description of the background theory used in the rest ofthis thesis. For the sake of conciseness and to avoid trivial discussions, we do not aim topresent a detailed description of the background theory. Instead, we provide a brief intro-duction aimed at highlighting the basic concepts and definitions that contribute to the under-standing of this thesis. The basic concepts and definitions are used in subsequent chapters ofthis thesis.

Section 2.1.1 contains some definitions which will be used later in our dynamic slic-ing algorithms. Section 2.1.2 describes some intermediate program representation conceptswhich are commonly used in slicing techniques. Section 2.1.3 discusses program depen-dence graph. Section 2.1.4 discusses some basic concepts on slicing which will help inunderstanding our dynamic slicing algorithms. Section 2.1.5 briefly discusses the conceptsof precision and correctness of slice. Some important applications are given in Section 2.1.6.Section 2.2.1 discusses the SOA layers. Section 2.2.2 briefly discusses the SOA architecturalprinciples. Section 2.3 discusses some basic concepts of software testing. Section 2.4 dis-cusses SOA testing challenges. Section 2.5 discusses testing SOA functional requirements.Finally, Section 2.6 summarizes this chapter.

30

2.1 Program Slicing

Program slicing is a technique that extracts the statements of a program P that (potentially)affect the computation of a variable of P at a specific location of P. The tuple consisting ofthe program, the variable, and the program location is referred to as the slicing criterion.The slicing criterion is sometimes extended to a set of variables. The parts of the programselected by program slicing for a slicing criterion constitute the program slice with respectto that criterion.

The original concept of program slicing was proposed by Mark Weiser [140] as anotherapproach for debugging sequential programs. Weiser claims that program slicing corre-sponds to the mental abstraction performed by programmers while debugging programs. In1986, Weiser and Lyle [141] performed a set of experiments that showed that some variationsof slices significantly reduced the amount of time needed to debug programs. Program slicingis an active area of research, and this is reflected in various research works [115, 119, 146],Tip’s survey [69], and in overviews [56, 147].

2.1.1 Preliminary Concepts and Definitions

In this section, we discuss a few concepts, notations, and terminologies that are used later inthis thesis. The existing program slicing literature shows a wide variation, diversity, disparityand disagreement in the notations used in program slicing. We explain our usage here be-cause of this lack of common consensus. The usage presented here does not come from anysingle source but rather is a personal blending of ideas from many sources. In the followingdefinitions and throughout the thesis, we use the terms node and vertex interchangeably.

Definition 2.1 Directed Graph: A directed graph G is a pair (N,E) where N is a finitenon-empty set of nodes, and E ⊆ N ×N is a set of directed edges between the nodes.

Let G = (N,E) be a directed graph. If (x, y) is an edge of G, then x is called a pre-

decessor of y and y is called a successor of x. The number of predecessors of a node isits in-degree, and the number of successors of a node is its out-degree. A directed path ( orpath) from a node x1 to a node xk in a graphG = (N,E) is a sequence of nodes x1, x2, . . . xksuch that (xi, xi+1) ∈ E for every i, 1 ≤ i ≤ k − 1. In this thesis, we use the words graph

and directed graph interchangeably.

Definition 2.2 Flow Graph: A flow graph is a quadruple (N,E, Start, Stop) where (N,E)is a graph, Start ∈N is a distinguished node of in-degree 0 called the start node, Stop ∈N is

31

a distinguished node of out-degree 0 called the stop node, there is a path from Start to everyother node in the graph, and there is a path from every other node in the graph to Stop.

Definition 2.3 Dominance: If x and y are two nodes in a flow graph then x dominates yiff every path from Start to y passes through x. y post-dominates x iff every path from x toStop passes through y.

Let x and y be nodes in a flow graph G. Node x is said to be immediate post-dominatorof node y iff x is a post-dominator of y, x 6= y and each post-dominator z 6= x of y post-dominates x. The post-dominator tree of a flow graph G is the tree that consists of the nodesof G, has the root Stop, and has an edge (x, y) iff x is the immediate post-dominator of y.

2 {

3 int x, y, prod;

9 ++ x; }

12 cout<< prod;

13 }

4 cin>> x;

7 while(x < 5) {

6 prod = 1;

5 cin>> y;

8 prod = prod * y;

1 main()

10 cout<< prod;11 prod = y;

FIGURE 2.1: An example program

Consider the flow graph of the example program of Fig. 2.1, which is given in Fig. 2.2.In the flow graph, each of the nodes 4, 5 and 6 dominate 7. Node 8 does not dominate node10. Node 10 post-dominates each of the nodes 4, 5, 6, 7, 8 and 9. Node 9 post-dominatesnode 8. Node 9 post-dominates none of the nodes 4, 5, 6, 7, 10, 11 and 12. Node 6 is theimmediate post-dominator of node 5. Node 10 is the immediate post-dominator of node 7.

2.1.2 Intermediate Program Representation

Various types of program representation schemes exist which include high-level source code,pseudo-code, a set of machine instructions in a computer’s memory, a flow chart, and oth-ers. The purpose of each of these representations depends upon the exact context of use.Different representations may be required to facilitate human readability, annotation for ver-ifiability, and transformation for running a program on platforms such as multiprocessorsand distributed computers, etc. In the context of program slicing, program representationsare used to support efficient automation of slicing.

For a very simple program, a slice for any given slicing criterion can be determined man-ually. But with increasing size and complexity of the programs, automatic slice computation

32

is essential. Current automated slicing techniques require that the information available in asource code form of the program to be sliced be transformed into some mathematical repre-sentation during the slicing process. Various representation schemes have resulted from thesearch for ever more complete and efficient slicing techniques.

In the following, we present a few basic concepts associated with intermediate programrepresentations that are used later in this thesis. A common corner stone for most of theslicing algorithms is that programs are represented by a directed graph which captures dataand control dependencies.

The standard intermediate program representations for slicing are the Control Flow Graph

(CFG) and the Program Dependence Graph (PDG). CFG based slicing algorithms usuallyaddress data flow analysis, whereas PDG slicing algorithms address the graph-reachabilityproblems. Generally, PDG slicing is much more efficient than CFG slicing.

It is important to note that there is no single correct way of constructing, say, a Con-

trol Flow Graph (CFG) or Program Dependence Graph (PDG), nor there is a set of rulesor standards which must be available for slicing. Researchers present different techniquesaccording to the needs of the problem at hand. Nevertheless, there is a general agreementas to the class information to be contained in each type of program representation for thepurpose of slicing. The various representations shown here are illustrative of these generalagreements but are not necessarily faithful to any single researcher’s style.

2.1.2.1 Control Flow Graph

The Control Flow Graph (CFG) is an intermediate representation for programs that are use-ful for data flow analysis and in many code optimizing transformations such as commonsubexpression elimination, copy propagation, dead code elimination, induction variableselimination, reduction in induction variable’s strength and code motion [9, 70]. But, theCFG does not give any information regarding data dependency between two nodes.

Definition 2.4 Control Flow Graph: Let the set N represents the set of statements of a pro-gram P . The Control Flow Graph of program P is the flow graph G = (N1, E, Start, Stop)

where N1 = N ∪ {Start, Stop}. An edge (m,n) ∈ E indicates the possible flow of controlfrom node m to node n.

Note that the existence of an edge (x, y) in the control flow graph means that control must

transfer from x to y during program execution. Fig. 2.2 represents the CFG of the exampleprogram given in Fig. 2.1. The CFG of a program P models the branching structures of theprogram, and it can be built while parsing the source code using algorithms that have linear

33

7

10

1112

89

Stop

654Start 1

FIGURE 2.2: The CFG of the example program given in Fig. 2.1

time complexity in the size of the program [26].

2.1.2.2 Data Dependence Graph

The CFG of a program represents the flow of control through the program. However, theconcept that is often more useful in program analysis is the flow of data through a program.Data flow describes the flow of the values of variables from the points of their definitions tothe points where their values are used.

Dependencies are relationships among program statements. There are two major type,control and data dependencies. Other dependencies do exist in the context of concurrent/dis-tributed programs that we would discuss in the chapters to follow. In a program, these twotypes create dependencies among the statements of a program.

Definition 2.5 Data Dependence: Let G be the CFG of a program P . A node n is saidto be data dependent on a node m if there exits a variable var of the program P such that thefollowing hold:

(i) the node m defines var,

(ii) the node n uses var, and

(iii) there exists a directed path from m to n along which there is no intervening definitionof var.

Consider the example program given in Fig. 2.1 and its CFG in Fig. 2.2. Node 8 has datadependence on each of the nodes 5, 6, and 8. Node 11 has data dependence on node 5. Notethat node 11 has data dependence on none of the nodes 6 and 8.

34

The term reaching definition is used to mean that a value defined at a node may be used atanother node [9]. That is, node x is a reaching definition for a node y iff y is data dependenton x. A data dependence from node x to node y indicates that a value computed at x maybe used at y under some path through the control flow graph. A dependence from x to y isa conservative approximation which says that under some conditions a value computed at xmay be used at y.

Definition 2.6 Data Dependence Graph: The data dependence graph of a program P isthe graph G = (N,E), where each node n ∈ N represents a statement of the program P and(x, y) ∈ E iff x is data dependent on y.

2.1.2.3 Control Dependence Graph

Ferrante et al. [70] introduced the notion of control dependencies to represent the relationsbetween program entities arising due to control flow.

Definition 2.7 Control Dependence: Let G be the CFG of a program P . Let x and y

be two nodes in G. Node y is control dependent on a node x if the following hold:

(i) there exists a directed path D from x to y,

(ii) y post-dominates every z in D (excluding x and y), and

(iii) y does not post-dominate x.

Let x and y be two nodes in the CFG G of a program P . If y is control dependent on x,then x must have multiple successors in G. Conversely, if x has multiple successors, then, atleast, one of its successors must be control dependent on it.

Consider the example program given in Fig. 2.1 and its CFG in Fig. 2.2. Each of thenodes 8 and 9 is control dependent on the node 7. Note that the node 7 has two successornodes 8 and 10, and the node 8 has control dependence on 7.

Definition 2.8 Control Dependence Graph: The control dependence graph of a program P

is the graph G = (N,E), where each node n ∈ N represents a statement of the program P

and (x, y) ∈ E iff x is control dependent on y.

35

2.1.3 Program Dependence Graph

Ferrante et al. [70] presented a new mechanism of program representation called Program

Dependence Graph (PDG). Unlike the flow graphs, an important feature of PDG is that itexplicitly represents both control and data dependencies in a single program representation.A PDG models a program as a graph in which the nodes represent the statements and theedges represent inter-statement data or control dependencies.

Definition 2.9 Program Dependence Graph (PDG): The program dependence graph G

of a program P is the graph G = (N,E), where each node n ∈ N represents a statement ofthe program P . The graph contains two kinds of directed edges: control dependence edges

and data dependence edges. A control (or data) dependence edge (m,n) indicates that n iscontrol (or data) dependent on m.

1

4

5 7

6

1011

12

9 8

Control dependence edge

Data dependence edge

FIGURE 2.3: The PDG of the example program given in Fig. 2.1

Note that the PDG of a program P is the union of a pair of graphs : the data dependence

graph of P and the control dependence graph of P . Consider the program given in Fig. 2.1.Its PDG is given in Fig. 2.3. In Fig. 2.3, the nodes of the graph represent the statements ofthe example program of Fig. 2.1. The solid edges represent the control dependencies and thedotted edges represent the data dependencies.

The program dependence graph of a program P can be built from its control flow graphin O(n2) time, where n is the number of nodes in the control flow graph [70].

2.1.3.1 System Dependence Graph

The PDG of a program combines the control dependencies and the data dependencies intoa common framework. The PDG has been found to be suitable for intra-procedural slic-ing. However, it cannot handle procedure calls. Horwitz et al. [90] enhanced the PDGrepresentation to facilitate inter-procedural slicing. They introduced the System Dependence

36

Graph (SDG) representation which models the main program together with all associatedprocedures. The SDG, an extension of the PDG, models programs in a language with thefollowing properties [90]:

• A complete program consists of the main program and a collection of auxiliary proce-dures.

• Procedures end with return statements. A return statement does not include a list ofvariables.

• Parameters are passed by value-results.

The SDG is very similar to the PDG. Indeed, a PDG of the main program is a subgraphof the SDG. In other words, for a program without procedure calls, the PDG and SDG areidentical. The technique for constructing a SDG consists of first constructing a PDG forevery procedure, including the main procedure, and then adding auxiliary dependence edgeswhich link the various subgraphs together. This results in a program representation whichincludes the information necessary for slicing across procedure boundaries.

A SDG includes several types of nodes to model procedure calls and parameter passing:

• Call-site nodes represent the procedure call statements in a program.

• Actual-in and actual-out nodes represent the input and output parameters at call sites.They are control dependent on the call-site nodes.

• Formal-in and Formal-out nodes represent the input and output parameters at the calledprocedures. They are control dependent on the procedure’s entry node.

Control dependence edges and data dependence edges are used to link the individualPDGs in an SDG. The additional edges that are used to link the PDGs together as follows:

• Call edges link the call-site nodes with the procedure entry nodes.

• Parameter-in edges link the actual-in nodes with the formal-in nodes.

• Parameter-out edges link the formal-out nodes with the actual-out nodes.

Finally, summary edges are added to represent the transitive dependencies that arise dueto procedure calls. A summary edge is added from an actual-in node A to an actual-out node

37

{

s = 0;

i = 1;

while (i < 10) do

{

add(s, i);

inc(i);

}

write(s);

}

main( )

int s, i;

void add(int a, int b)

{

a = a + b;

return;

}

void inc(int z)

{

add(z,1);

return;

}

FIGURE 2.4: An example program consisting of a main program and two procedures

B, if the value associated with the actual-in node A affects the value associated with theactual-out node B, due to the transitive flow of dependence. The transitive flow of depen-dence may be caused by data dependencies, control dependencies or both. Fig. 2.5 representsthe SDG of the example program given in Fig. 2.4.

2.1.4 Basic Concepts in Static Slicing

In this section, we first discuss some work on static slicing of object-oriented programswhich are essential for understanding static slicing of service-oriented software. In the nextchapter, we discuss how these basic slicing techniques have subsequently been extended tohandle dynamic slicing of service-oriented software.

The intermediate program representation is analyzed to compute a static slice. Horwitzet al. [90] developed system dependence graph (SDG) as an intermediate program repre-sentation and proposed a two-phase graph reachability algorithm on the SDG to computeinter-procedural slice. The first pass of the inter-procedural slicing algorithm traverses back-ward along all the edges of the SDG except parameter-out edges, and marks those verticesreached. The second pass traverses backward from all vertices marked during the first passalong all edges except call and parameter-in edges and marks the reached vertices. The sliceis the union of the vertices marked during pass one and pass two.

Larson and Harrold [132] enhanced the SDG [90] to represent object-oriented programs.Their SDG successfully represents object-oriented features such as method calls, inheritance,and polymorphism. After constructing the SDG for a complete object-oriented program,they have used the two-pass graph reachability algorithm [90] for computing static slices.One limitation of this approach is that it fails to consider the fact that in different methodinvocations, the data members used by the methods might belong to different objects. So,the resulting data dependencies become imprecise. A second limitation of the approach isthat it does not handle cases in which an object is used as a parameter or as a data member

38

entry main

s=0 i=1 write(s)

add

ain= s bin= i s=aout

inc

in= i

entry inc

in addzout=z

ain=z bin=1

entry add

a=ain b=bin a=a+b a =a

call, parameter−in, parameter−out edge

data dependence edge

control dependence edge

summary edge

z=aout

while (i<10)

i=z out

z=z

z

out

FIGURE 2.5: The SDG of the example program given in Fig. 2.4

of another object.

2.1.5 Precision and Correctness of Slice

Let P be a program, and S be a static slice of P with respect to a slicing criterion C. In theoriginal definition of Weiser [140], the reduced program S is required to be an executableprogram and its behavior with respect to the slicing criterion must be same as the originalprogram P . A slice S of P with respect to a slicing criterion C is statement-minimal if noother slice of P with respect to the slicing criterion has fewer statements than S. Weiser[140] has shown that the problem of computing statement-minimal slices is undecidable.

Another common definition of a static slice is the following: a slice S of a program

39

P with respect to a slicing criterion C is a subset of the statements of the program whichdirectly or indirectly affect the slicing criterion [70, 90, 177]. Note, that such a slice neednot be executable. Unless specified otherwise, we follow this definition of a slice throughoutthe discussion in the thesis.

Let GC be the control flow graph (CFG) of a program P . In all the existing programslicing frameworks, for each statement s in the program P , two sets are maintained. One setcontains the variable names used at s and the other set contains the variable names defined ats. The inter-statement dependencies in the program P are captured using the CFG GC andthe variable names in these two sets, for each statement s.

1. read(m);

2. i = 1;

3. x = 4;

4. z = m − m;

5. write(z);

integer m, i, x, z;


Note that statement 4 of the example program given in Fig. 2.6 uses the variable m.Though statement 4 assigns the value zero (m−m) to the variable z, it has a dependence onstatement 1 in the program slicing frameworks since statement 1 is a reaching definition ofthe variable m for the statement 4.

It is, therefore, reasonable to define the precision of a dynamic slice in the existing pro-gram slicing frameworks as follows. A dynamic slice is said to be precise if it contains only

those statements that actually affect the slicing criterion in the particular execution.

Note that a precise dynamic slice need not be a statement-minimal slice. Consider theexample program given in Fig. 2.6. For any input value of the variable m, the statement-

minimal slice with respect to the slicing criterion< 4, z > should be empty set as z is alwaysassigned the value 0 = m−m. In the existing program slicing frameworks, the precise slicefor the slicing criterion is certainly {1} as statement 1 is a reaching definition of the variablem for the statement 4.

A slice is said to be correct if it contains all the statements that affect the slicing criterion.A slice is said to be incorrect if it fails to contain some statements that affect the slicingcriterion. Note that the whole program is always a correct slice of any slicing criterion. Acorrect slice is imprecise if it contains, at least, one statement that does not affect the slicingcriterion.

40

2.1.6 Applications of Program Slicing

This section describes the use of program slicing techniques in various applications. In tryingto use the basic slicing concepts in diverse domains, several variations of the notions of pro-gram slicing as described in Section 1.1 are developed. The program slicing technique wasoriginally developed to realize automated static code decomposition tools. The primary ob-jective of those tools was to aid program debugging. From this modest beginning, the use ofprogram slicing techniques have now ramified into a powerful set of tools for use in such di-verse applications as program understanding, program verification, automated computationof several software engineering metrics, software maintenance and testing, functional co-hesion, dead code elimination, reverse engineering, parallelization of sequential programs,software portability, reusable component generation, compiler optimization, program inte-gration, showing differences between programs, software quality assurance, software refac-toring etc. [71, 78, 79, 91, 127, 148, 149, 261]. A comprehensive study on the applicationsof program slicing is made by Binkley and Gallagher [57] and Lucia [128]. In the following,we briefly discuss some of these applications of program slicing.

2.1.6.1 Differencing

Programmers often face the problem of finding the differences between two programs. Al-gorithms for finding textual differences between programs are often insufficient. Programslicing can be used to identify semantic differences between two programs [58]. There aretwo related differencing problems:

1. Find all the components of two programs that have different behavior.

2. Produce a program that captures the semantic differences between two programs.

For programs old and new, a straightforward solution to problem 1 is obtained by com-paring the backward slices of the vertices in old and new’s dependence graphs Gold andGnew. Here, the backward slice is computed with respect to a given slicing criterion. Com-ponents whose vertices in Gnew and Gold have isomorphic slices have the same behavior inold and new; thus the set of vertices from Gnew for which there is no vertex in Gold with anisomorphic slice approximates the set of components new with changed behavior.

A solution to the second differencing problem is obtained by taking the backward slicewith respect to the set of affected points (i.e., the vertices in Gnew with different behaviorthan in Gold). For programs with method calls, two modifications are necessary: First, inter-procedural slicing techniques are required to be used to ensure that the resulting program

41

slice is executable. Second, this solution is overly pessimistic: consider a component c inmethod P that is invoked from two call-sites c1 and c2. If c is identified as an affected pointby a forward slice that enters P through c1 then we will include c1 but not c2 in the programthat captures the differences. However, the backward slice with respect to c would includeboth c1 and c2.

2.1.6.2 Debugging

Finding bugs in a program is always difficult. The process of finding a bug usually involvesrunning the program over and over, learning more and narrowing down the search each time,until the bug is finally located. In distributed systems, the problem is more difficult becauseof control and data dependencies and also communication dependencies that might lead toadditional, often non-repeatable bugs. Program slicing was originally proposed by observ-ing the operation typically carried out by programmers while debugging a piece of code.Programmers mentally slice a code while debugging it. Even after several advancements tothe basic slicing techniques, program debugging remains the main application area of slicingtechniques. Debugging can be a difficult task when one is confronted with a large programand little clues regarding the location of a bug. During debugging, a programmer usually hasa test case in mind which causes the program to fail. Program slicing is useful for debugging,because it potentially allows one to ignore many statements in the process of localizing thebug [127, 140]. If a program computes an erroneous value for a variable x only the state-ments in the slice with respect to x have (possibly) contributed to the computation of thatvalue; all statements which are not in the slice can safely be ignored. A program slicer thatis integrated into the debugger can be very useful in discovering the reason for the error byvisualizing control and data dependencies and by highlighting the statements that are part ofthe slice.

Several variants of program slicing have been developed to further assist the programmerin debugging: program dicing [127] identifies statements those are likely to contain bugs byusing information that some variables fail some tests while others pass all tests. Slices canbe combined with each other in different ways: for example, the intersection of two slicescontains all statements that lead to an error in both test cases; the intersection of slice a withthe complement of slice b excludes from slice a all statements that do not lead to an errorin the second test case. Another variant of program slicing is program chopping [195]. Itidentifies statements that lie between two points a and b in the program which will be affectedby a change made at a. This can be useful when a change at a causes an incorrect result atb. Debugging should be focussed on the statements between a and b that transmit the changeof a to b.

42

2.1.6.3 Software Maintenance

Software maintenance is a costly process because each modification to a program must takeinto account many complex dependence relationships in the existing software. The mainchallenges in effective software maintenance, are to understand various dependencies in anexisting software and to make changes to the existing software without introducing newbugs. One of the problems in software maintenance is that of the ripple effect, i.e., whethera code change in a program will affect the behavior of other codes of the program. To avoidthis problem, it is necessary to know which variables in which statements will be affectedby a modified variable, and which variables in which statements will affect a modified vari-able during software maintenance. The needs can be satisfied by slicing the program beingmaintained [78].

2.1.6.4 Testing

Software maintainers often carry out regression testing. Regression testing essentially im-plies retesting software after modification [59, 194, 252]. Even after the smallest change to apiece of code, extensive tests may be necessary which might involve running a large numberof test cases to rule out any unwanted behavior arising due to the change. While decompo-sition slicing eliminates the need for regression testing on the complement, there may stillbe a substantial number of tests to be run on the dependent, independent and changed parts.Slicing can be used to reduce the number of these tests.

Suppose a program modification only changes the value of the variable x at program pointp. If the forward slice with respect to x and p is disjoint from the coverage of regression test t,then the test t does not have to be rerun. Suppose a coverage tool reveals that a use of variablex at program point p has not been tested. What input data is required in order to cover p?The answer lies in the backward slice of x with respect to p. A lot of work has also beenreported in order to test programs incrementally, to simplify testing, to apply program slicingto regression testing, to partition testing, and to test path selection [36, 72, 79, 91, 150, 252].

2.1.6.5 Program Integration

Programmers frequently face the problem of integrating several variants of a base program.Of course, the first step is to look for textual differences. More sophisticated techniques forthis purpose have now become available. Semantic-based program integration is a techniquethat attempts to create an integrated program that incorporates the changed computations ofthe variants as well as the computations of the base program that are preserved in all variants

43

[60, 93]. Horwitz et al. [79] presented an algorithm for semantic-based program integrationthat creates the integrated program by merging certain program slices of the variants. Theirintegration algorithm takes as input three programs, Base, A and B, where A and B arevariants of Base. The integrated program is produced by (1) building graphs that representBase, A and B, (2) combining program slices of the program dependence graphs of Base, Aand B to form a merged graph, (3) testing the merged graph for certain interference criteria,and (4) reconstructing a program from the merged graph. Yang extends the algorithm ofHorwitz et al. [79] for detecting program components with equivalent behaviors and it canaccommodate semantics-preserving transformations.

2.1.6.6 Functional Cohesion

Cohesion measures the relatedness of the code of some component [37]. A highly cohesivesoftware component is one that has only one function that is indivisible. Bieman and Ott[27] define data slices to consist of data tokens (instead of statements). Data tokens may bevariables of constant definitions and references. Data slices are computed for each outputof a procedure (e.g., output to a file, output parameter, assignment to a global variable).The tokens that are common to more than one data slice are the connections between theslices. They are called glue. The glue binds the slices together. The tokens that are in everydata slice of a function are called super-glue. Strong functional cohesion can be expressedas the ratio of super-glue tokens to the total number of tokens in the slice, whereas weak

functional cohesion may be seen as the ratio of glue tokens to the total number of tokens. Theadhesiveness of a token is another measure expressing how many slices are glued togetherby that token.

2.1.6.7 Software Quality Assurance

Software quality assurance auditors have to locate safety critical code and to ascertain itseffect throughout the system. Program slicing can be used to locate all code that influencesthe values of variables that might be part of a safety critical component. But beforehandthese critical components have to be determined by domain experts.

One possible way to assure high quality is to make the system redundant [57, 194]. If twooutput values are critical, then these output values should be computed independently. Theyshould not depend on the same internal functions, since the same error might manifest in bothoutput values, in the same way, thereby hiding the error. One technique to defend againstsuch errors is to use functional diversity, where multiple algorithms are used for the samepurpose. Thus, the critical output values depend on different internal functions. Program

44

slicing can be used to determine the logical independence of the slices computed for the twooutput values.

2.1.6.8 Parallelization

Program slicing can be used to decompose a conventional program into substantially inde-pendent slices for assignment to separate processors as a way to parallelize the program. Agoal of such parallelization is to determine slices with almost no overlap. Assuming that acombination slicer-compiler could produce a sliced executable code suitable for a parallelmachine, an issue of some complexity is the problem of reconstructing the original behav-ior by splicing the results of the separate outputs of different slices. Such a technique isinvestigated in [149].

2.1.6.9 Anomaly Detection

Static slicing methods can detect dead code, i.e., statements which cannot affect any out-put of the program. Often such statements are not executable because of the presence of abug. Static slicing can also be used to determine uninitialized variables which are used inexpressions, another symptom of an error in the program.

2.1.6.10 Program Specialization and Reuse

Executed slices can be thought of as specialized programs. Slices can be used to makecode reuse more efficient [133]. Instead of reusing the entire package, a slice can be used toidentify only those parts that are really needed. Slicing isolates computational threads, whichhelps in identifying logical components. The threads can be extracted and either replaced orused to create new programs.

2.1.6.11 Reverse Engineering

Reverse engineering concerns the problem of comprehending the current design of a programand the way this design differs from the original design [194]. This involves abstracting outof the source code, the design decisions and the rationale for the initial development (designrecognition) and understanding the algorithms (algorithm recognition).

Program slicing provides a tool set for this type of re-abstraction [28]. For example, aprogram can be displayed as a lattice of slices ordered by the is-a-slice-of relation. Com-

45

paring the original lattice and the lattice after (years of) maintenance can guide an engineertowards places where reverse engineering energy should be spent. Because slices are notnecessarily contiguous blocks of code they are well suited for identifying differences in al-gorithms that may span multiple blocks or procedures.

2.1.6.12 Other Applications of Program Slicing

As mentioned earlier, program slicing methods have been used in several other applicationssuch as compiler optimizations, detecting dead code, software portability analysis, programunderstanding, program verification, software refactoring, measuring class cohesion, etc.These applications can be found in [37, 78, 189].

2.2 Service-Oriented Architecture (SOA)

Service-oriented architecture (SOA) is an architectural style for designing and developingdistributed systems. As organizations expand their systems to cross organizational bound-aries, testers will have to test the use of SOA as an architectural style in these systems. Theymay need to test their systems in such a way that qualities are met without sacrificing theloosely coupled, stateless, standards-based nature of the relationship between service con-sumers and service providers characteristics that have made SOA a worthwhile technologyto adopt.

In this section, we discuss the SOA layers and their architectural principles which areimportant for understanding the design and development of SOA-based software.

2.2.1 Service-Oriented Architecture (SOA) Layers

There are many research articles that provide a reference architecture or layered approachfor systems that use a service-orientation approach [12, 30]. These layers facilitate separa-tion of concerns and designers have a set of architectural decisions that need to be made ineach layer. Fig. 2.7 shows the typical layers of a service-oriented system that are primarilyfunctional in nature.

46

FIGURE 2.7: SOA layers

The service-oriented system includes the following layers [184]:

• Presentation Layer: The benefit of creating a presentation layer is decoupling theclient-side presentation implementation from the service implementation to allow eachto change independently. This layer is generally not the focus of service-orienteddesign.

• Business Process Layer: The services provided in the services layer are often com-posed into workflows to assist in the development of applications. This provides flex-ibility to change the workflows as business processes change.

• Services Layer: Services reside in this layer. The invocation of these services can be

47

determined at design time or bound dynamically through a service registry at runtime.These services are broken into additional layers to assist in the composition of servicesinto complete business processes. The additional layers include:

– Utility-based services: This service provides utility-based functions such asnotification, logging, and exception handling. These operations are largely ag-nostic to business processes and can, therefore, be reused in multiple businessprocesses.

– Entity-based services: These services operate on a set of business entities (ordata entities). These operations are largely agnostic to business processes andcan, therefore, be reused in multiple business processes.

– Task-based services: These services are “business services with a functionalboundary directly associated with a specific parent business task or process”[184].

• Enterprise Layer: These components contain code that specifically fulfills serviceneeds or code that accesses the functionality in operational systems. “These specialcomponents are managed, and governed set of enterprise assets that are funded by theenterprise or the business unit level. This layer typically uses container-based tech-nologies such as application servers to implement the components, workload manage-ment, higher availability, and load balancing” [12].

• Operational Systems Layer: This layer consists of existing custom-built, commer-cial, external systems or some combination of these. Careful analysis of these systemsneeds to be completed to determine the operations that should be exposed as services.These services are considered to have enterprise-wide utility.

2.2.2 SOA Architectural Principles

SOA architectural principles are general guidelines for designing service-oriented systems.These principles are ideally enabled by the decisions taken during designing the system. Theservice-oriented architecture at a higher level of abstraction, consists of four major typesof elements: service consumers, SOA infrastructure, service interfaces, and service imple-mentation, as shown in Fig. 2.8. Erl [219] defined additional principles for service design.The principles in this section are similar, but they are applied to the full architecture of theservice-oriented system: the integration of services (interface and implementation), serviceconsumers, and the SOA infrastructure.

48

SOA Architects often find themselves in conflicting situations. On one hand, they havebusiness/mission goals and QoS requirements driving the architecture of a system. On theother hand, there are principles of service-orientation that influence the architecture of asystem and impact a system’s QoS attributes. It is at this intersection of these two sets ofquality attributes where conflicts arise and an SOA architect needs to make suitable deci-sions. Therefore, the responsibility of the SOA architect is to try to apply each principle inthe context of the business goals of the system and to balance trade-offs and architecturaldecisions in order to meet the system’s business goals [184].

FIGURE 2.8: A higher level abstraction of SOA

1. InteroperabilityOne of the key enablers of widespread SOA adoption is standardization at multiplelevels, as shown in Fig. 2.9. Standardization in service-oriented systems has multipleadvantages including tool support and leverage of third-party system components that,in the end, can lead to shorter development times [184].

The WS-* base stack (HTTP, XML, SOAP, and WSDL) is fairly stable and has largetool support. For example, there are multiple tools that will take a web service descrip-tion language (WSDL) document as input and produce all the code necessary to invokethe associated service. However, beyond the base stack, it is not that straightforwardbecause of the over-abundance of standards.

49

FIGURE 2.9: Web service standardized protocol stack and WS-* extensions

There are currently over 100+ WS-* standards produced by organizations such as OA-SIS [176] and W3C [238] in areas that include business process specification, com-position, messaging, reliable messaging, transaction management, security, and man-agement. Some of these standards are complementary and some have competitivebehaviroul specifications. Additionally, many of these standards have extensions, thatcan be interpreted in different ways.

The web services interoperability organization (WS-I) is an organization chartered topromote web services interoperability across platforms, applications, and program-ming languages [244]. WS-I has profiles for the basic stack and for security to provideclarifications, refinements, interpretations, and amplifications in areas of the standardsthat are subject to multiple interpretations. There are also tools to check that XMLartifact (e.g., a WSDL file) and actual messages being exchanged are in conformancewith the profiles. The WS-I tools are especially useful in cases in which WSDL andXML files are automatically generated and may not conform to the assumptions ofthe development and deployment environment, e.g., different XML schema versions,different namespaces, malformed XML, etc. The tools that facilitate the usage of these

50

standards will be one criterion that an architect uses to select between competing stan-dards.

2. Loose CouplingLoose coupling is also one of the key goals for SOA adoption. Service consumersshould be allowed to select technologies that best fit their organizational context andpolicies. The SOA architect should define how messages will be exchanged, howmessages will be designed, and how services will be described. SOA implementationsthat are built using web services use XML for message exchange and WSDL and stablestandards such as SOAP and HTTP for communications. These XML technologiesmake loose coupling possible in service-oriented environments.

3. Reusability The goal of increasing reuse is mostly associated with service reusability.Services are reusable because they represent self-contained functionality that can beused in multiple business processes. SOA architect can abstract utility services andmay reuse it.

4. Composibility A composition may rely heavily on infrastructure such as an orchestra-tion engine for the choreography of services based on business workflows of BPEL.

5. Discoverability In a service-oriented environment, services are created and publishedin a UDDI that is accessible to service consumers. Ideally, service consumers canquery this service registry looking for services that satisfy desired business function-ality.

2.3 Software Testing

When a program is developed as an implementation of any algorithm or logic, thedevelopers are always doubtful about its performance and correctness. The developersmust have the confidence that the software achieves a certain level of quality. Softwaretesting can be appropriately used to ensure the quality of the software to a certain level.A quality software should be correct. A software can only be correct, iff it computesresults for the entire domain of input, and all the results it computes are specified.Thus, the software requires exhaustive testing to validate the input domain. A softwaretesting approach can only suggest the presence of faults and cannot highlight theirabsence if it is not exhaustive. According to Karner et al. [105], exhaustive testing ofthe software is not possible for the following reasons:

• the input domain is too large, for example, to test the greatest among two num-bers, the input domain can be any number n that belongs to the Integer set, I.

51

• there are too many possible input paths to test, so the difficulties alluded toby this assertion are exacerbated by the fact that certain execution paths in aprogram could be infeasible [171, 225].

• design and specifications can change during software development and are thusdifficult to test, this is because software testing is an algorithmically unsolvableproblem and specification errors cause major design errors [39]. According toManna et al. [158], it is not possible to surely know the correctness of thespecifications.

Hamlet et al. [94] have formally stated the goals of a software testing methodologyand Morell et al. [159] have highlighted its limitations. Young et al. [256] observedthat there was always a trade-off between exhaustive testing and computational costbecause the presence of defects was always undecidable. Therefore, no testing tech-nique can be completely accurate and generic to all the programs. Even though thetesting process is challenged with many limitations, but the consistent application of atesting technique in an intelligent manner can ensure an acceptable level of softwarequality. Therefore, testing is an important phase in software development life cycle.This phase incurs 60% of the total cost of the software. Therefore, it becomes highlyessential to devise proper testing techniques in order to design the test cases so thatthe software can be tested properly. Testing strategies are based on verification andvalidation. The static techniques available for a testing map to the verification pro-cess without executing the code, whereas the dynamic testing techniques map to thevalidation process by executing the code.

Fig. 2.10 shows the hierarchical decomposition of the testing strategies along withtheir association with different test adequacy criteria. The decomposition shown in Fig.2.10 follows the definitions given in [39, 265]. The execution-based testing techniquesare decomposed into either program-based, specification-based, or combined as shownin Fig. 2.10. The chosen adequacy criterion C determines the types of test cases thatbelong to the test suite, T. A program-based testing approach creates T by analyzing thesource code of a program, P, based upon its structure and attributes. A specification-based testing technique creates the desired test suite from the functional and/or non-functional requirements for P. Whereas, combined testing uses both program-basedand specification-based testing approaches to generate T. Based on the kind of testingstrategy that is followed to create T, the test cases are categorized into three types:

• Black-box, test cases that are created without knowledge of P’s source code.

• White-box, test cases that are created considering the entire source code of P.

• Grey Box, test cases only consider a portion of P’s source code.

52

Fig. 2.10 also shows the association of these testing strategies with the correspondingtest adequacy criteria. A structure-based criterion requires T to satisfy exercising ofcertain control structures and variables within P, such as statement coverage, branchcoverage, condition coverage, path coverage, etc. Therefore, structure-based test ad-equacy criterion requires program-based testing. Fault-based test adequacy criterionensures that the types of faults that are commonly introduced into P by the program-mers are revealed by T. Finally, error-based testing approaches rely upon the fact that Tdoes not deviate from the specifications in any way. Therefore, error-based adequacycriteria motivate for specification-based testing approaches.

FIGURE 2.10: A hierarchy of software testing [39, 265]

2.3.1 Test, Test Case, and Test suite

In the context of software testing, test and test cases are often used interchangeably.A test case consists of an initial state, inputs, and expected outputs. The state refersto pre-conditions, if any, that is circumstances that hold prior to the test execution.Each test case is also identified by a unique identification number. The process oftesting is to check whether the inputs yield the expected outputs or not. The test caseis said to fail if the actual output differs from the expected output. If the test case fails,then it requires debugging to reach the cause of this failure. A set of these test casesdesignated to test an application is called test suite. A test suite may be segregated intoa set of successful and unsuccessful test cases.

53

FIGURE 2.11: A software testing process model [265]

2.3.2 Execution-based Software Testing

Fig. 2.11 shows the process of execution-based software testing. In this Figure, therectangles denote the testing activities and the parallelograms denote the outcome ofthese activities. The testing process starts with a system under test, P, and a test ade-quacy criterion, C, as input. The testing process is iterative and stops iterating whenthe test cases in test suite T satisfy the adequacy criterion C and assure some level ofconfidence in the quality of P [265]. However, the testing process can also stop in caseof deadline misses or budget overrun. The testing process can also halt if the tester getsan intuition of achieving some acceptable level of quality. Even if the testing processstops or meets with C, it does not guarantee that all the defects have been revealedby the test cases. Therefore, testers set many adequacy criteria (different coveragecriteria, software metrics, etc.) to build the confidence on quality. The test adequacycriteria depend on the chosen program representation and definition of some qualityparameters that T should satisfy. The test specification stage evaluates P in the context

54

of chosen criterion C in order to construct an adequate test suite T. Once the test casedescriptions for P has been generated, the test case generation phase begins. A lot ofdifferent techniques and tools have been proposed to manually or automatically gener-ate the test cases. After the generation of the test cases, the execution of the test casesstarts. Once again, the execution of the tests within T can be performed in a manualor automated fashion. The results from the execution of the test cases are analyzed interms of coverage. Thus, iterative testing of P continues throughout its initial develop-ment. However, it is also important to continue testing after P undergoes changes inthe maintenance phase.

Regression testing is an important software maintenance activity carried out to ensurethat the changes made does not adversely affect the correctness of P. All of the previ-ously mentioned stages iteratively continue for the regression testing process based onthe existing test cases (new test cases may be added) and the adequacy measurementsdefined for these tests [14, 39, 105, 134, 172, 197].

2.4 SOA Testing Challenges

SOA testing challenges are broadly classified according to the functional and non-functional requirements. The functional requirement testing challenges are associatedwith common components, web service, web service composition, and competency ofthe tester. The non-functional requirement testing challenges are availability, reliabil-ity, security, performance and usability. Further, the SOA-specific testing challengesinclude interoperability, agility, adaptability, reusability, and governance.

At a higher level, testing SOA implementation (web service) is similar to testingtraditional systems using conventional testing techniques. But at a lower level, itbecomes a complex task. A tester may test its functional and non-functional re-quirements first. The functional requirement testing of the service-oriented systemmust check whether business requirements documented in service level agreement(SLA)/specification document is traceable up to the SOA deployment level. This ver-ification includes testing of common components, composite service, and end-to-endbusiness process. The non-functional requirements testing checks various quality ofservice (QoS) attributes like availability, reliability, agility, interoperability, security,performance, and adaptability etc. A service that does not balance QoS level up toexpected level can be considered as a violation of the SLA. In this section, we discussSOA testing challenges according to the classification shown in Fig. 2.12.

55

SOA Testing Challenge

Functional requirement

Web service Web servicecompetency

Non-functional requirement

SOA specific

composition

Commoncomponent

Availability Reliability Security Performance UsabilityTester

Interoperability Agility Adaptability Reusability Governance

Testing Environment

FIGURE 2.12: SOA testing challenges classification

2.4.1 Functional Requirement Testing Challenges

In this section, we discuss the major factors and associated challenges that seriouslyaffect the SOA testing process from the perspective of common components (CC) likeinfrastructure components, web service, composite services, and tester capability.

• Common Components (CC) Testing Challenges

– Highly complex configurationThe identified SOA infrastructure components are web services, web servers,universal description discovery and integration (UDDI), enterprise servicebus (ESB) and web service clients more specifically a web browser, typi-cally these are vendor supported software. All these have their own con-figuration for installation, updating and up gradation. Such componentsmust be configured correctly for testing which otherwise may lead to in-correct results. Sometimes these components have multiple inconsistentconfigurations which complicate the testing effort.

– Inconsistent SOA implementation platformsWeb services are commonly implemented through J2EE and .net tech-nology platforms. Both are inconsistent with respect to standards, pro-tocols, interfaces, service implementation etc. For example, J2EE involvesweb service description language (WSDL), simple object access proto-col (SOAP), and HTTP protocol stack layers while .net involves WSDL,UDDI, SOAP, HTTP etc. These inconsistencies in standards or protocolstack layers lead to misunderstanding of SOA concepts and thus increaseproblems in testing SOA.

– Lack of testing environmentA testing environment mirrors deployment environment and includes test-

56

ing tools, test case, and test data. Since SOA deployment environment isdistributed, heterogeneous it is very difficult to mirror. Even it cost high.

– Lack of software version control management toolsMultiple versions and releases of key SOA infrastructure may be acces-sible within and across sites. Such software components must be alignedconsistently which further necessitates software version control manage-ment tools within and across the organizations. Developing and deployingversioning tool will be costly.

– Lack of quality of service (QoS) informationSometimes the infrastructure providers do not have any QoS informationwhich must be desired for safety critical systems. Lack of such informationmay harm human lives, or even catastrophic events may occur. Even, thesystem with less QoS requirement will put down consumer’s satisfactionlevel.

• Web Service Testing Challenges A web service is a software system designedto support interoperable machine-to-machine interaction over a network [234].There are two main styles for web services one is representational state transfer(REST) and other is simple object access protocol (SOAP). SOAP web servicesuse SOAP and WSDL protocol stack to carry message payloads and describeservice descriptions respectively whereas REST based web services use HTMLand HTTP protocol layers to transport, describe, publish and consume messages.In this section we are going to analyze key testing challenges from the perspec-tive of atomic web services, encapsulating functional task.

– Absence of source and build codeGenerally, the web service is being called by web client more specifically aweb browser. In such scenario, the source code or build code is hidden fromthe client which makes web service to be most eligible for black box testingwhere service code is hidden. With this fact, a tester can not apply whitebox testing techniques until (s) he makes the assumption of availabilitysource code or can infer dependencies and behavioral operation by outsideobservations.

– Undisclosed usage conditionsA web service can be better utilized for reuse if its usage conditions arewell known. But it is difficult to create a service for potential reuse forall situations or environments. To cope with it service developer may bestestimate the common reuse context and prepare test cases in that contextonly. Ideally, exhaustive testing of all reuse contexts is difficult to achieve.

57

– Unpredictable load demand and adverse impact on QoS requirementsAn atomic web service can be consumed by service clients scattered acrossvarious sites. The load on entities like network, propagation delay, transferrates, routing mechanism etc. cannot be estimated until the service invoca-tion. Therefore, it is problematic to test and to validate QoS requirements.

• Web Service Composition Testing Challenges

– Unavailability of web service composition membersA web service may be an atomic, aggregate or composite. Composite webservice relies on service composition members which may be controlledby multiple service providers residing within or across organizations. Soduring testing, such composite web service tester needs availability of eachcomposition members involved in. Otherwise, the testing process fails ateach end of the composite. The tester may put simplified behavior in theabsentia of composite members which is not feasible or may schedule itonly when all the composite members are available which again requirespatience.

– Lack of cooperation among multiple service providerComposite member service seems to be a black-box to the tester. The ser-vice testers do not have sufficient information which may be required fromeach composite member services for rigorous testing. Sometimes even theservice providers are not ready to disclose such information because ofconfidentiality or policy adopted by an organization or noncooperation dueto untrustworthy environments. In such situation, testing will be a longrunning process involving convincing fruitfulness of disclosing contextualinformation.

– Lack of common semantic web standardsAll participating web service may enforce adoption of common semanticdata model like ontology web language (OWL), resource discovery frame-work (RDF) schema etc. However common consensus on these semanticweb standards is notoriously difficult because of multi-party involvement,unaware of inconsistencies induced due to the adoption of various semanticdata models.

– Lack of common fault and exception handling mechanismFault or exception may occur at any time any point during web serviceinvocation. Exception handling mechanism includes compensation webservices in place so that as it generates the compensation web service takescharge and ensures smooth invocation of web services within and across

58

organizations. Noncooperation among participant or composite serviceleads to the adoption of inconsistent fault or exception handling mecha-nism, blurring the testing process as dark.

– Lack of common transaction management protocolsTransaction of an atomic, aggregated or composite service may cross theorganizational boundaries. Different composite service may implementdifferent transaction management protocols like ACID-compliant transac-tion or atomic transaction etc. These differences may arise only in unusualconditions where multiple concurrent transactions from multiple serviceslead to inconsistent state or service failure. Testing in such inconsistent orfailure state will be an enormously challenging task.

– Lack of common coordination protocolsComposite services invocation involves various composition member ser-vices. In a composite service, it is difficult to determine which memberservices play what role for example activation, registration, protocol spe-cific or coordinator services. Due to multi-party involvement within andacross organization boundaries, testing in such conflicting environment istoo much difficult.

– Side effect propagationAtomic services may be part of a composite or an aggregate. Testing anatomic service may inadvertently affect other composite member servicesalso. However, it is difficult to determine that a service is a side effectfree by tester until it is tested. In the worst case, the tester is unable todetermine the roots of side effects due to dynamic binding which occurswithin composite and beyond that.

– Lack of governance and source code control managementNeither one owns nor does one control the web services. Any change incomposite member service can result in failure in entire composite service.If service tester is unaware of changes, (s)he may be unable to identify theroot source of failure. The tester may perform a set of regression test tocease foreseen errors.

– Lack of service comprehension toolCurrently, business process composites can be formed and well executedby web service business process execution language (WS-BPEL) and webservice choreography description language (WS-CDL). These languagesvalidate the business process and their endpoints. Up to our knowledge,no tool exist that supports service comprehension. Lack of such servicecomprehension tool increases the testing complexity.

59

– Lack of debugging capabilityLocalization of errors within and beyond composite is difficult due to dy-namic binding, non-reproducibility etc. Such unanticipated scenarios worsenthe testing effort.

– Lack of common security protocolsA composite service involves various security protocols for example SAML,kerberos, and x.509. A Common consensus on security protocols is diffi-cult to achieve due to organization policy. Testing in such inconsistentsecurity protocols limits the effort of the tester.

• Competency of tester for testing SOA capabilities

– Inadequacy of the testerA tester who have worked for testing conventional systems using tradi-tional testing techniques like black or white box testing for them SOA test-ing will be a new one. They do not have technical knowledge about howthe SOA is designed, developed, integrated and deployed. Even the expe-rienced tester might overlook tangible benefits of it. In fact, such testersmight resist themselves from learning SOA concepts, and its associatedtechnologies the web services. An SOA tester must have knowledge of allinterfaces, organizational business requirements and strategies.

– Unable to capture global snapshotThe tester does not have zooming capability to visualize and record allthe contextual information, SOAP request /response messages generatedacross various sites which further complicates inconsistency within andacross organizations. In general, it is difficult to capture consistent globalcut due to the limited capacity of the tester in visualizing and recording.Without this, it is difficult to test across the inconsistent cut.

– Lack of efforts and funds in establishing simulation environment fortestingThe simulation environment is analogous to the actual deployment environ-ment .This environment enables a tester to design and execute test casesprior to deployment of web services. However, establishing such envi-ronment is difficult because of participation of distributed, heterogeneousinfrastructure components, their cost and security concern.

– False information provided by service providersThe service provider registers their service using WSDL. In doing so ser-vice provider may provide incorrect information which probably increase

60

their selection rank among other competitive service providers and thusinfluences consumer’s decision.

2.4.2 Non-functional Requirement Testing Challenges

In this section, we discuss testing aspects of major quality of service (QoS) parameterslike availability, reliability, security, performance, and usability.

• Availability TestingA service is autonomous. So, when it is invoked it may not be available atthe same time. To ensure high availability, replicas of services may be dis-tributed across various sites, which may again lead to inconsistencies amongthem. Again each replica increases the cost of testing effort.

• Reliability TestingA message-level reliability can be achieved with various standardized messageexchange patterns (MEPs) and reliable transport protocols like TCP/IP. Relia-bility testing ensures that service or business process gets reproducible resultswhen invoked repeatedly over a certain period of time. In short, high availabilitygives rise to the reliability of services.

• Security TestingThe major initiatives towards SOA adoption are its exposed nature over worldwide web. This will open the services for vulnerabilities, attacks, and penetra-tion. Security policies and trustworthy environment should be placed at each in-teraction level. Sometimes, security testing outperforms reusability testing whenservice consumptions violate trustworthy environments among the federated or-ganizations. A Security testing must validate security even in an untrustwor-thy environment. The identified common vulnerabilities are denial-of-serviceattacks encapsulated in SOAP message retrieved by SOA intermediary nodes,bypassing authentication and authorization policies, executing malicious code,tracking username and passwords [54].

• Performance TestingThe performance of the service-oriented system with respect to response timeand throughput is very poor due to XML-based communication, layered archi-tecture and distribution of services across world wide web (WWW) networkwith associated latency. Such system has high XML payload compared to con-ventional binary communication payloads. Even, the small services SOAP mes-sage need to be processed by each intermediate node which add extra overheadin computing the results. The performance testing of service-oriented systems

61

should be performed from the end-to-end business process, at unit level of webservices, on validating each service interfaces and load testing of each service.

• Usability TestingSOA service does not have a user interface. Even, these services are invisible tothe testing team. Testing such invisible services demands specifically designedtesting tools. Without such automated tools, tester spent lots of time in tediousoperations like composing WSDL, SOAP message and calling the services etc.

2.4.3 SOA Specific Testing Challenges

In this section, we discuss SOA specific testing challenges like interoperability, agility,adaptability, reusability, and governance.

• Interoperability TestingDeveloping business over the web through web services involves different pro-cess, technology, and tools, it is possible that service providers may use differenttools to design service interface (WSDL), SLA and SOAP messages, and it isexpected that all the deployed services must conform to standard interoperabil-ity profiles to become interoperable. The web service interoperability (WS-I)organization has developed basic profile (BP) and basic security profile (BSP) toenforce compatibility and interoperability. The WS-I has designed testing toolsto test whether web services conforms to WS-I profiles.

Interoperability exists between services and is not inherent in the services. In-teroperability of web service in SOA environment requires standardization orcontract at different layers between service consumers and service providers.The contract includes contracts at each layer of TCP/IP and ISO , contracts atXML based standards WSDL, SOAP, REST, and UDDI, contract at semanticstandards OWL, RDF, OWL-S, contracts at transaction protocols ACID, WS-Atomic transaction, contract at organizational level SLA, WS-BPEL, WS-CDL,and WS-Coordination, contracts at exception handling mechanism. Thus inter-operability testing becomes a matter of testing the service’s adherence to stan-dards.

• Agility TestingA service-oriented system is expected to be modified easily. As its internal struc-ture is not visible to the service consumer the system may change its implemen-tation without knowing its consumers and without changing its interfaces. Test-ing complexity increase because each change in the system needs to be tested

62

properly. An organization may deploy a source code control system to alignservice versions properly.

• Adaptability TestingServices are expected to be agile enough to cope with changing business needs.Adaptability testing necessitates the understanding of overall service usage sce-narios and how quickly the services can be provisioned to accept new customers.Identifying volatile part of requirement helps to test service for future change ifarises. Since business environment changes rapidly, a complete system testingmust be carried out in prior to deploying it thoroughly. Automated testing toolsand regression testing will play a crucial role in this context.

Syntactic interoperability can be achieved by standardizing service interface andits protocols. As, SOA capability spans various federated organizations, andnon-interoperable security policies adopted by them it becomes difficult to testinteroperability among them.

• Reusability TestingService in a service-oriented system may be reused at each possible context ofusage if it is standardized and identified properly. Reusability testing fostersstandardization among heterogeneous systems. These data format conversionamong service-oriented systems leads to significant overhead in processing. Atested service needs to be tested again at each possible reuse context.

• SOA Governance TestingThe SOA governance testing is mainly challenged by inter-organizational com-munication of services and dynamic composition of services during run-time.SOA Governance testing ensures that all the standards, policies, and rules con-tracted by peer business organizations related to design, development, and de-ployment of services-oriented systems conform to it. Bertolino et al. [2] haveproposed a governance monitor for the establishment of governance standards,policies and rules defined during foundation time, design time and runtime.

2.4.4 Testing Environment Challenges

It is difficult and costlier to establish an SOA testing environment mirroring/simulatingthe actual SOA deployment environment because of distributed environment, hetero-geneity among SOA software and hardware. Even, this environment must enable thetester to design, develop, and executes test cases. Additionally, it enables the tester tocapture all contextual information related to web services, business processes and QoSparameters of SOA.

63

Some organization might place stubs, proxies and virtual machines to provide com-plete SOA deployment environment. These stubs and proxies serve the roles on behalfof missing services or business processes. And the virtual machines simulates the SOAsoftware and hardware components. This testing environment should be available toservice providers during development so they can start testing service and businessprocesses in parallel with development. Doing so enables service providers to verifyphase containment errors and can trace business requirements early in the developmentphase.

In short, the testing environment should incorporate testing tools to create, manage,executes and validates test cases, management of test inputs/outputs, version manage-ment among the service or business processes, and simulation of in absentia of servicesor processes.

2.5 Testing SOA Functional Requirements

The components which built service-oriented systems are web services, web servers,UDDI, ESB and web service clients (web browsers).

2.5.1 SOA Web Service Testing

Web services are the main capabilities in the service-oriented system. The first steptowards web service testing is to determine whether its functional requirements aremet. Additionally, a test case can be executed to ensure interoperability.

• Unit TestingTesting SOA web services in the absence of customized automated testing toolsimpose great challenges due to lack of control over web service and absenceof other services which the service under test (SUT) call or may be called by.Web service testing is very similar to the unit testing of regular software. Stubsand proxies may be used to mock the behaviour of unavailable services. Insuch circumstances, the quality of testing depends heavily on the stub and proxyservices. Complex services are difficult to be mocked because understandingthe complex behaviour and developing the stub services is a complex task. Eventhe interface description of stub service is evolving since development is not yetcompleted, leads to uncertainty in testing results.

• WSDL TestingSOA service descriptions mus be correctly described in a WSDL document.It must include XML elements like service name, the location of the service

64

(URL), service operations, input/output messages, service port, and service bind-ing. These predefined XML elements must be validated prior to its publishing.

• Web Service Functional TestingThe main goal of this testing is to ensure that service responds with correct re-sponse for given request message. Due to a variety of service consumers/clients(web browsers), it is impossible to anticipate exactly types of request messagethe clients will send. Exhaustive testing of all possible request is unbounded.

• SLA TestingService provider and consumer stipulate an SLA, in which the service providerguarantees to consumer certain functionality with a given level of QoS. Thus,an SLA spells out who is responsible for what, what each party will do, andwhat they will not do. SLA testing involves various measurable qualities likeaccuracy, availability, capacity, cost, latency, reliable messaging and scalability.Optionally it includes unmeasurable attributes like interoperability, modifiabil-ity, and security.

• Regression TestingRegression testing of web service ensures that modifications due to bug fixes donot cause unexpected changes or failures. Each time a defect is fixed the poten-tial exists to inadvertently introduce new errors, problems or defects. Regressiontesting of SOA services is the selective retesting of an old test suite on the eachmodification to the services or after each bug is fixed to ensure that no new bugshave been introduced as a result of bug fixing. The main purpose of regressiontesting is that web services up to the point of repair have not been adversely af-fected by the fix. Business organizations may devise guidelines to decide whento start regression testing. It includes up gradation/updating of services, up gra-dation of WSDL or SLA, change in the deployment environment, and retire-ment of services. The actual decision regarding when to perform regressiontesting will be based on many factors, which includes nature of change and us-age environment of services. An organization must perform regression testingin a situation where the services involve human life, environmental change orbusiness economy change.

• Robustness TestingRobustness Testing ensures that proper recovery mechanism is placed to handlethe unexpected behaviour of services. Compensation services will handle excep-tions when they arise. For that, both WSDL and SOAP messages may includefault section to cope with it.

65

• Load TestingLoad or stress testing of service is used to test the performance of the web servicewhen many users are accessing the services simultaneously. The response of theweb service must be constant and its performance must not degrade with theincrease in the number of users.

2.5.2 Web Service Integration Testing

Problems encountered during the integration testing of SOA web service are sameto integration testing of object-oriented systems. Late binding, missing service par-ticipant at the moment of testing and dependencies to external services are the mainproblems associated with it. For example, which particular service is invoked in corre-spondence to service call can not be determined due to late binding. External serviceto which the service is dependent can change without notice.

• Dynamic Web Service Composition TestingDynamic web service composition is the key characteristics of SOA, enablingruntime service composition by combining pre-existing services using standardlanguages. Web service composition is a group of related or confined serviceseither locally or globally hosted on web servers. These compositions often spanacross the enterprise boundaries and deals with the involvement of stakehold-ers requirements and goals to meet the desired design process. More ever,these composite services is a business process that usually requires advancedprogramming skills and vast knowledge about SOA-enabled technologies likeweb services [260]. Recently, many web service languages have been proposed.These languages support long running transactions and multi-service scenarios[103]. SOA composite services can be formed by choreography and orches-tration [180]. Therefore, testing service composition can be classified into twocategories choreography and orchestration testing.

• Choreography TestingService choreography involves interaction among multi-party with multiple re-sources, and each party is autonomous and controls its own behaviour. Thechoreography is the process that tracks the message sequences among multipleparties and sources [218]. A choreography of services between distributed par-ties, specifies which services to use, in which order, and under which conditions[77]. Additionally, web service choreography describes collaboration protocolsof cooperating web service participants from a global view [193]. An exampleis web service choreography description language (WS-CDL). Testing service

66

choreography refers to testing of the entire path involved in executing the busi-ness process. The path encounters a number of services, disparate applications,and multiple participants. Therefore choreography testing should consider gov-ernance testing across federated organizations, testing of long-running businessprocesses, testing of loosely coupled services including regression testing. Thetesting process for choreography is similar to the testing process of typical soft-ware systems. Scenarios for the business process should be devised along withbasic, critical and optional flow paths. Test cases must traverse these paths andcan additionally test the dynamism of composites services. The critical flowpath must be identified carefully and specifically tested for both functional andnon-functional characteristics.

• Orchestration TestingOrchestration refers to an executable business process that can interact with bothinternal and external web services [180]. It is the process where interactionsbetween web services occur at the message level. The interaction procedure in-cludes business logic and task execution order. The orchestration process canspan applications and organizations, as a whole to achieve long-term transac-tions and multi-step process model. The scenario of web service involves party’sperspective and orchestration always achieve control considering the party’s per-spective. The orchestration is used to describe and execute a single viewpointmodel [235]. Web service orchestration refers to web service description whichtakes a local point of view [205]. This means orchestration resembles web ser-vice collaboration in predefined patterns based on a local decision about webservice interactions at message level or execution level. A representative for thisis WS-BPEL [68].

The WS-BPEL models business processes by specifying the workflows of car-rying out business transactions. From a general perspective, the orchestrationof services means to provide specification and realization of business processesthat allows the message exchanges between one or more web services. Testingof BPEL is similar to testing services, and its interactions.

2.5.3 SOA Registry/UDDI Testing

The main objective of testing SOA registry is to ensure that only qualified servicesbecome part of SOA registry. Validation of service description involves proper map-ping of WSDL to tModel data structure of UDDI, searching and invoking servicesbased on certain business functions. Testing should be extended to know that registrydata is valid, legitimate and up to date. Additionally, UDDI operations like identify-

67

ing, naming, describing, classifying, relating, grouping, and associating related sharedinformation needs to be tested. Moreover, the XML data structure (UDDI) used tostore service description should be tested for overflow and underflow conditions. Ad-ditionally, the tester may validate bindingTemplate data structure to ensure that onlyspecification compliant services are included. SOA registry can be deployed publiclyor privately. Testing private SOA registry will be difficult due to limited visibility andcontrol. Testing public SOA registry involves business services publishing across theWWW, which requires a rigorous testing process in place. The public service registrymay be tested for inconsistencies among various replicas of registry distributed acrossvarious sites. The tester should expect change control and version control managementsystem should be in place to align versions and update UDDI across sites.

Testing dynamic service discovery capabilities of service registry ensures that onlypublished or subscribed services can be found while invoking services. Also, it in-cludes searching the web services using various inputs and rules. Subscription andnotification capabilities of UDDI can be tested when a new version of service descrip-tion is published all the concerned service consumers should be informed. Servicemonitors may be deployed at SOA registry level to log service usage data which en-ables the service providers to analyze data for identifying frequent service consumers,highly loaded and lightly loaded services, identifying security threats, analyzing loadbalancing scheme, audits etc. In this context, service virtualization may be employedto create virtual service endpoints effective in load balancing of highly and lightlyloaded services. Finally, testing should be carried out in SOAP messages as UDDIruns over SOAP messages.

2.5.4 ESB Testing

ESB, a middleware software supports SOA services and applications integration, coor-dinate resources and manipulate information driven by business requirements. Ribarovet al. [129] have proposed a test-enabled ESB which intercepts and controls the com-munications between ESB and services. The intercepted message may be modifiedto support fault injection and test generation. Further, this modified message can berecorded for debugging, visualizing, analysis and black-box testing.

2.5.5 SOA System Testing

This testing phase will ensure that the SOA technical solution has delivered the de-fined business requirements and has met the defined business acceptance criteria. Toensure that this phase/level of testing is targeting only the key business scenarios of the

68

solution, the business stakeholders and testers must fully understand the quality andtest coverage that have been achieved in the previous test phases.

2.6 Summary

In this chapter, we have discussed some definitions and concepts that will be used laterin our algorithms. First, we have discussed various intermediate program representa-tions. Next, we have discussed some basic concepts of slicing which are required tounderstand our dynamic slicing techniques. Then, we briefly dealt in precision andcorrectness issues of slices. We provided an overview of some important applicationsof program slicing. Then, we discussed the SOA layers and their architectural prin-ciples. Finally, we have discussed software testing and testing challenges associatedwith SOA.

69

CHAPTER - 3Review of Related Work

This chapter discusses the work done by previous researchers on static slicing ofobject-oriented software, dynamic slicing of object-oriented software, and black-boxtesting of SOA-based software. As we could not find any reported work in the litera-ture on static and dynamic slicing of SOA-based software, so in this chapter, first webriefly discuss static and dynamic slicing of object-oriented software. Then, we reviewthe work reported on black-box testing of SOA-based software. Finally, we describethe available work on model-based testing of SOA-based software.

3.1 Static Slicing of Object-Oriented Software

To the best of our knowledge, no work has been done on static slicing of SOA-basedsoftware. So, in this section, we discuss the work reported on static slicing of object-oriented software.

A natural way of localizing an error is to consider only those statements of a program,which tend to the erroneous behaviour being observed. Often this results in finding thestatements of a program relevant to the value of a chosen variable at a given location ofthat program. This approach is called program slicing. The given variable and locationform the slicing criterion. The original concept of program slicing was proposed byMark Weiser [140] as another approach for debugging sequential programs. He claimsthat program slicing corresponds to the mental abstraction performed by programmerswhile debugging programs. Agrawal et al. [86] have presented a uniform approach tocompute dynamic slices of programs that may involve unconstrained pointers, com-posite variables, and procedures. Program slicing is an active area of research, and thisis reflected in various surveys such as in [69].

In 1995, Sun Microsystems Inc. introduced a new programming language called“Java”. The Sun Microsystems Inc., now Oracle and Sun Microsystems Inc. definedJava as “simple, object-oriented, network-savvy, interpreted, robust, secure, architec-turally neutral, portable, high-performance, multithreaded and dynamic language. Java

70

has become the standard language for sending platform independent program over theinternet and executing them as part of web pages.

Bik et al. [10] worked on restricting compiler that converts implicit parallelism inJava into explicit parallelism. Zhao [116] gave solution for static slicing concurrentJava programs. Nanda et al. [139] gave issues and solution for slicing concurrent Javaprograms, their work was inspired from [116]. Nanda et al. [139] described variousalgorithms for slicing concurrent inter-procedural and intra-procedural Java programsand gave formal proof of all the algorithms.

Catano [170] described a framework to slice Java event space for Java memory model.He defined Java event space as the partial orders of the memory and thread actionsgenerated by a multithreaded Java program. He suggested an approach to reduce thesize of Java event space and described the problem of aliasing that arises when two ormore variables of the event space point of the same memory address. He suggested analgorithm to deal with it.

Lallchandani et al. [99, 110] have presented static slicing of UML architectural modelby merging class diagram with a sequence diagram. They defined various dependen-cies like member, method, data, call, return, attribute, control, inter-sequence call andinter-sequence return. They extended the work presented in [131]. Zhao [100] intro-duced static slicing technique, considering ACME ADL for dependence analysis ofsoftware architecture.

3.2 Dynamic Slicing of Object-Oriented Software

In this section, we briefly present the reported work on dynamic slicing, architecturaland UML model based slicing of object-oriented software. Most of the work reportedin the literature are focused on the development of techniques for slicing UML modelslike class diagram, sequence diagram, use case diagram, activity diagram etc.

Korel and Laski [29] introduced a new form of slicing. This new form of slicing isdependent on input data and is generated during execution-time analysis as opposedto Weiser’s static slicing [140] and is therefore called dynamic slicing. Similar tomajor objective of static slicing, dynamic slicing was specifically designed as an aidto debugging, and can be used to help in the search for offending statements whichcaused the program error [128].

Considerable research results on dynamic slicing of procedural programs are avail-able [29, 147]. But dynamic slicing of object-oriented programs have scarcely beenreported in the literature [69, 140]. Agrawal and Horgan [22] were the first to present

71

algorithms for finding dynamic slices of procedural programs using program depen-dence graphs. They have proposed a dynamic slicing method by marking nodes ona static program dependence graph. The computed slice is not always precise, be-cause some dependencies might not hold in dynamic execution. They also proposeda precise method based on the dynamic dependence graph (DDG) [22]. Zhao [269]extended the DDG of Agrawal and Horgan [22], known as dynamic object-oriented

dependence graph (DODG) to represent various dynamic dependencies between state-ment instances for a particular execution of an object-oriented program. The DODG isan arc-classified diagraph (V, A), where V is the multi-set of flow-graph vertices, andA is the set of arcs representing dynamic control dependencies and data dependenciesbetween vertices. His construction of the DODG is based on dynamic analysis of con-trol flow and data flow of the program, and similar to those for constructing dynamicdependence graphs for procedural programs [23]. They have constructed the DODGby creating a new node for each occurrence of a statement in the execution history,and creating all the dependence edges associated with the occurrence at run-time. Hehas also considered the specific features of object-oriented programs such as methodcalls, inheritance and polymorphism. The DODG of the example program in Fig. 3.1on input argv[1] = 3, is shown in Fig. 3.2.

Zhao has adopted the following concepts for dynamic slicing of object-oriented pro-grams:

• A slicing criterion for an object-oriented program P is of the form (s, v, t, i),where s is a statement in the program, v is a variable used at s, and t is anexecution trace of the program with input i.

• A dynamic slice of an object-oriented program P on a given slicing criterion (s,

v, t, i) consists of all statements in the program that actually affected the valueof a variable v at statement s, for the given input i.

Based on the DODG, Zhao has used a two-phase algorithm to compute dynamic slicesof object-oriented programs. Computation of dynamic slices using the DODG is car-ried out as a graph-reachability problem. The two phases of the algorithm are:

(a) Computing a dynamic slice over the DODG of the object-oriented program.(This can be done by using a usual depth-first or breadth-first graph traversal al-gorithm to traverse the DODG of the program by taking the vertex correspondingto the statement of interest as the start point of traversal.)

(b) Mapping the slice over the DODG to the source code to obtain a dynamic sliceof the program.(This can be done by simply defining a mapping function.)

72


73

FIGURE 3.2: The DODG of the program given in Figure 3.1 on input argv[1]=3

Mohapatra [55] have presented work concerning dynamic slicing of object-orientedprograms. He developed intermediate representation extended system dependence

graph (ESDG). Then, he presented dynamic slicing algorithm edge marking dynamic

slicing (EMDS) using ESDG. The EMDS algorithm is based on marking and unmark-ing the edges of the ESDG as and when dependencies arise and cease during run-time.EMDS algorithm marks an edge of the ESDG when its associated dependence existsand unmarks an edge when the dependence ceases to exist. Then, he presented an-other dynamic slicing algorithm node marking dynamic slicing (NMDS) using ESDGas the intermediate representation. The NMDS algorithm is based on marking andunmarking the nodes of the ESDG appropriately during run-time. He had shown thateach of his proposed algorithm is more efficient than the related algorithms [269].Next, he extended intermediate representation (ESDG) to concurrent object-oriented

programs. He named this intermediate representation as concurrent system depen-

dence graph (CSDG). The CSDG represents the concurrency aspects such as synchro-

nization dependencies and communication dependencies of object-oriented programs.Then, he extended edge marking dynamic slicing (EMDS) algorithm to handle con-

currency issues in object-oriented programs. He named algorithm as marking based

dynamic slicing (MBDS). The MBDS algorithm handles synchronization dependen-

cies and communication dependencies while computing dynamic slices.

Zhao [101] was the first person to introduce the concept of architectural slicing basedon architectural description language (ADL) ACME. He defined component-connector

74

dependency, connector component dependency, and additional dependency. He hadproposed an algorithm to compute architectural slice based on software architecturaldependency graph (SADG). He extended his previous work [100] by introducing archi-tectural information flow graph with information flow arcs like component-connector,connector-component, and internal flow arcs based on WRIGHT ADL. Kim et al.[217] have introduced dynamic software architecture slicing (DSAS) as a set of ar-chitect components and connectors that are relevant to the particular variable andevents of interest at some point during the execution of software architecture. Korelet al.[25] have presented deterministic and nondeterministic slicing based on extendedfinite state machines (EFSMs). They have developed a tool to demonstrate their slic-ing technique. Kagdi [92] have introduced the concept of model slice, which extractsslices from a class diagram.

Samuel et al. [190] have presented a technique to test object-oriented software usingdynamic slicing of UML sequence diagram. They used message guards on sequencediagram to generate dynamic slice with respect to each conditional predicates. Sliceswere generated from the dependency graph for all the variables at each message pointin the sequence diagram.

Lallchandani et al. [99, 131] have used generic class diagram and generic sequencediagram and integrated them to generate a model dependency graph (MDG). Theyhave proposed an algorithm for architectural model slicing through MDG traversal(AMSMT) to produce the static and dynamic architectural model slices. The algo-rithm traversed the edges of model dependency graph (MDG) according to the slicingcriterion. They developed a tool which computed dynamic slices from UML architec-tural models.

Noda et al. [104] have extended their own work on dynamic slicing of the sequencediagram. They generated behavior model (B-Model), which defined various dependen-cies and calculated slices. They supported their work by incorporating exceptions andmultithreading programs. They implemented a tool as Eclipse plug-in to demonstratetheir proposed method.

3.3 Black-box Testing of Service-Oriented Software

In this section, we briefly present the reported work on black-box testing of web ser-vices, testing tools available for web services and model-based testing approaches,frameworks, and tools.

There exists a slight difference between web services and web applications. The webservices are for machines or programs to machines or program communication over a

75

network whereas web application is for users. Web applications usually present datain HTML which looks nice to the user and web services usually present data in XMLwhich easy to parse by other applications. A web application may contain both agraphical user interface for human users, as well as a set of web services for computer“users” (clients). For example, a payment service like Paypal has both a graphical userinterface for human users, as well as a set of web services through which we can haveown backend systems accessing the Paypal services.

The service-oriented technology hinders the application of practical traditional test-ing techniques, such as white-box approaches [49]. Bartolini et al. [49] introducedservice-oriented coverage testing (SOCT), which probed the instrumented service code,and the service (tcov) to retrieve coverage related information through WSDL inter-face. The survey by Canfora et al. [84] gave good solutions to the challenges analyzedfrom the viewpoints of different stakeholders including different levels of testing i.eunit, integration, and regression testing. Motlagh [67] summarized literature on unit,integration, and regression testing in table formats. Canfora et al. [83] gave overviewof SOA testings and fundamental testing issues such as changes in inputs, dynamicbinding, service level agreement (SLA) violation, change in the functionality or qual-ity of service (QoS) along with solutions for mutation testing, integration testing andregression testing. Kalamegam et al. [187] inspected recent research related to SOAtesting. Patil [231] suggested various recommendation to test web services, interop-erability testing, load testing, use of JMeter [6] to test web services, and some of themajor web service testing tools.

The WSDL formalized descriptions of service operations and of their input and out-put parameters can be in fact taken as a reference for black-box testing at the serviceinterface [33]. Many of the proposed approaches for WSDL-based data generation arebased on the XML schema (XSD) data type information [15, 34, 40, 120, 210, 212,250, 266]. In these approaches, the datatype with various constraints allows genera-tion of test data. The complex types are decomposed into simple types to generate testdata. Tsai et al. [237] have proposed an extension to WSDL description to find outvarious dependencies such as input-output dependency, invocation sequences, hierar-chical functional descriptions, and concurrent sequence specification. The test datageneration using WSDL is limited to the XSD constraints because it lacks run-timeinformation of the services. As a result, many researchers have focused for other al-ternative specifications. The use of semantic model OWL-S for test data generation isproposed in [81, 246, 253, 257].

The existence of known errors can be detected by test cases, but the faults in systembehaviour can not be determined through it. Fault-based test data generation aims atproving the absence of prescribed faults in web services. The fault-based test data

76

generation technique generates erroneous test data intentionally [120, 121].

Zhu [88] analyzed key challenges to test web services and proposed a service-orientedtesting framework to test web services, where T-services are the testing services work-ing on behalf of the customer and test broker services which search and invoke testerscapable of performing testing on demand of the customers. Schieferdecker et al. [97]considered the applicability of testing and test control notation TTCN-3 for functionaland load testing of web services. Mei [130] have proposed a context-aware frameworkfor testing service orchestration and choreography in the presence of a context (run-time environment). In the work [206] various examples for white-box, black-box andgray box testing of services have been illustrated.

3.3.1 Testing Tools For Web Services

A few testing tools are available in market to test service-oriented software (SOS)based on web services. The most commonly used tools are:

• SmartBear SoapUI

• Crosschecknet SOAPSonar

• HP QuickTest Professional

• Parasoft SOAtest

• Apache JMeter

• Oracle Testing Accelerators for Web Services

• PushToTest TestMaker, and

• WebInject

All the above mentioned tools somehow support testing of web services from func-tional and nonfunctional aspects. Some of them offer an option for validation ofWSDL document for conformances to the WS-I [244] profile. The organization forthe advancement of structured information standards (OASIS) [176] is an industryconsortium, which defined a set of rules showing how standards should be used andhave designed various profiles related with web service interoperability. Also, it pro-vides testing tools for use by the tester community to help in developing, deployingand testing interoperable web services.

77

• SmartBear SoapUISoapUI [207] is an open-source testing tool for service-oriented architecture(SOA) and web service testing. It is developed by SmartBear software companyand is provided freely under the GNU lesser general public license (LGPL). Itprovides complete test coverage and supports all the standard protocols and tech-nologies. SoapUI facilitates quick creation of advanced performance tests andexecution of automated functional tests of any test scenarios. The set of featuresoffered by soapUI helps in performance evaluation of web services. It requiresWSDL files to generate tests, messages, validations and mocking services. Un-fortunately , soapUI supports only 1.1 version of WSDL, it can’t provide supportfor WSDL 2.0. SoapUI conforms WS-I profile [244] for 1.1 version of WSDL.The new version 1.7 includes plug-ins for the NetBeans, IntelliJ, and EclipseIDEs. SoapUI can easily create functional, regression, compliance, and loadtests. SoapUI provides code-free test environment. Analysis of the test resultsprovides a mean to improve the quality of services and applications.

Recently released version SoapUI NG Pro allows the option for flow to testvariables, properties requests, and context. Test data for data-driven tests can beprovided from external databases resources. SoapUI’s MockServices, a feature,which allows mimicking web services before they are developed. It removes thecost of building web service. MockServices can simulate any desired behaviorof web service, no matter how complex, the service responses can be completelyconfigured.

• Crosschecknet SOAPSonar

SOAPSonar [208] is a specialized tool for testing and analyzing web services. Itcan perform regression tests, performance tests, generate reports and many othertests. The test case is developed via easy to use graphical interfaces. It supportsboth WSDL 1.1 and 2.0 documents. The professional edition of SOAPSonarhas test flow management options and can create a chain of WSDL requests-response or data-driven test case for the exchange of SOAP messages.

Almost all the versions of SOAPSonar uses test request and response analysisdata from e.g. database tables. The application can automatically change valuesof variables in SOAP message headers, body, tasks and can change global vari-ables and automation variables. SOAPSonar has vulnerability mode, which as-sociates each test request with a set of attack. Analyzing SOAP responses helpsto find any existing vulnerabilities and leakage of information. It can parse theWSDL documents and automatically generate a list of the operations describedby it. It can also be used to send SOAP request messages to the target web

78

service and capture the responses.

• HP QuickTest Professional

HP QuickTest Professional tool [89] is an automated testing suite. It uses bothWSDL 1.1 and WSDL 2.0. It can perform automated testing on a variety ofsoftware and in varied environments. It allows regression and functional testing.The main functionality of HP QuickTest Professional is its ability to performvalidation of WSDL using the WS-I tool [244]. It is quite complex but a morepowerful tool compared to the other competitors.

• Parasoft SOAtest

SOAtest [181] is used for testing service-oriented architecture (SOA) based ap-plications. It automates application testing, message/protocol testing, cloud test-ing, and security testing. Its graphical user interface is based on Eclipse. It al-lows creating tests, defining the behavior of the tests and configuring specifictests.

SOAtest’s main functionality is to test web services. It automatically generatestests from XML, XML schema definition (XSD), web service description lan-guage (WSDL), universal description discovery and integration (UDDI), WADL,WSIL, business process execution language (BPEL) and other. SOAtest can val-idate WSDL documents and can emulate the client or the server. Complex test-ing scenarios can be executed in a sequence. Failed test case are distinctivelyhighlighted in the generated results. Parameters for the requests can be enteredby the user or can be automated to be read from a file.

Even, SOAtest can trace and visualize how SOAP messages and events flowthrough enterprise service bus (ESB), message brokers, applications, and databaseswhile tests are executed. Such tracing allows interpreting problems directly fromthe testing environment. SOAtest provides regression tests and functional tests.They will cause an alert when changes affect application’s behaviour. Functionaltests like load testing can be performed for performance monitoring. Securitypenetration tests are performed at the message level. SOAtest is promising soft-ware to perform web services testing.

• Apache JMeter

JMeter [6] is an open-source testing tool for web services. It is developed byapache software foundation (ASF). It is distributed under Apache License. Ini-tially, it was designed to test web applications but has been extended to test web

79

services. The core functionality of JMeter is to load test client/server applica-tions/services. It can also be used for performance evaluation of applications.Additionally, JMeter helps in regression testing by facilitating creation of auto-mated test scripts with predefined assertions. By this, we can verify the applica-tion’s results.

JMeter incorporated support for multithreading that allows concurrent functionsexecution by a number of threads. JMeter offers easy to use user interface.Configuration and setting up a testing plan is somewhat complex and requireslittle efforts. JMeter can generate a number of statistical reports and graphicalresults.

• Oracle Testing Accelerators for Web Services

Oracle application testing suite, includes testing accelerators for web Services.It allows testing quality and performance of service-oriented architectures basedapplications directly from web service interface level. It automates functionaland regression testing of services and uses an OpenScript platform to allow usersto generate scripts. These scripts can combine multiple simple object accessprotocol (SOAP) requests in a single test script. Web services test scripts can becreated by selecting which methods to call from this store of parsed web servicemethod requests or by specifying the requests manually. It can also specify datainputs for those web service requests using data banks. It can reuse responsevalues from one request, parse them and then use it as input for subsequent re-quests of web services using script variables. However, it does not make anycoverage analysis and suggests or create any test cases. It reports whether thetest succeeds or passed.

• PushToTest TestMaker

TestMaker [182] is a web service testing application from PushToTest softwarecompany. TestMaker’s tests are embodied in scripts called test agents . Itprovides an agent wizard that will read a WSDL definition and automaticallycreates a skeletal test agent. TestMaker can also be used to test Web applica-tions. It includes a network monitoring tool that can watch HTTP traffic be-tween the browser and a target web application and generate test cases fromthis interaction. TestMaker test agents are written in Jython (python is writtenin Java). Jython can access all the Java libraries provided with TestMaker. Itsupports communication protocols: HTTP, HTTPS, SOAP, POP3, JDBC, andmuch more. Therefore, the tester can create test cases that approach any clientapplication the web service is likely to be called by.

80

• WebInject

WebInject [245] is a lightweight testing tool that can automate the testing ofboth web services and web applications. It is free, open-source, and licensedunder the GNU general public license (GPL). The new version 1.41 is able totest XML/SOAP web services. WebInject is written in Perl but it is built so thatyou can easily construct tests without learning too much about Perl.

3.3.2 Model-based Testing of Service-Oriented Software

Model-based testing is a special type of black-box technique that offers many advan-tages over traditional testing techniques. First, the construction of design models canbegin early in the development cycle and it allows improvement in the design too.Therefore maintenance cost can be minimized. Even the test cases are available earlyin the development cycle so it makes the test planning more effective. Since it findsfaults at the initial stage of software development lifecycle, it reduces the testing time.Second, the modeling exposes ambiguities, inconsistencies, incompleteness and errorsin the specification or design of software. Further, these model can be reused in futuretesting, even when the specifications changes rapidly. Moreover, these models are eas-ier to update than a complete testing suite. The test data obtained from this techniqueis independent of the implementation architecture. Most importantly, these modelsembody information that can be used with graph theory to generate many different in-termediate representations, test cases, test sequences, and test scenarios automatically.

Model-based testing requires that the models must be complete, consistent, unambigu-ous, and correct. Otherwise, testing will fail as the model is the core part. There arevarious challenges involved in model-based testing of SOA-based software. Some ofthese challenges are listed below:

• The web service description language (WSDL) is insufficient for testing as itcontains only service description information, and the tester requires the com-plete business process model.

• Generally, we prefer UML for modeling static and dynamic behaviour of object-oriented software. Since SOA is heterogeneous and distributed and there doesnot exist any support for modeling such properties in UML, it complicates thetesting process.

• There is no consensus about best modeling language for SOA. The object-orientedsoftware is based on classes, objects, design patterns while service-oriented soft-ware has services, interface descriptions, business workflows etc.

81

In this section, we briefly present the reported work on model-based testing approaches,frameworks, and tools. Most of the work reported in the literature are focused on thedevelopment of testing techniques or frameworks based on models.

Once the analysis and requirement phase is completed the modeling phase starts. Themost commonly used models are: finite state machines (FSMs), unified modeling lan-guage (UML), formal grammars, markov chains, petri nets, decision tables, decisiontrees, data flow diagrams, business process execution language (BPEL) and statecharts.Application of some of the models for testing web services can be found in the litera-ture [16, 41, 42, 106, 122, 247]. Model-based testing techniques using petri nets havealso been explored extensively in literature [48, 249, 259]. Cao et al. [226] have used aformal model, named timed extended finite state machine (TEFSM), defined by Lallaliet al. [160, 161] to model web service composition. They developed web service on-line testing framework (WSOTF) to test a web service based on WSDL specificationor a web service orchestration.

The business process execution language for web service (BPEL4WS), now BPEL, isan XML-based web service composition, orchestration, coordination and executablelanguage for business processes in an SOA. A business process execution language forweb service (BPEL4WS or BPEL) process is mainly composed of activities, whichcan be separated into basic activities, such as invoke, receive, reply, assign, throw, ex-ist and structure activities, such as sequence, pick, if, while, repeatuntil, flow etc. Theflow (<flow>) activity is used to define a set of activities that can be invoked in par-allel. The web service composition promotes reusability by creating new web servicecapabilities through combining existing web service capabilities. The coordination inother hand refers to WS-coordination protocol or WS-business protocol which is usedto denote the set of valid sequence of invocations that occur among the service partic-ipants during execution of the certain business process. Nowadays, business processexecution language (BPEL) has become the de-facto standard for the compositions ofweb services.

Fu et al. [254] have presented a web service analysis tool (WSAT) for analyzing andverifying composite web service designs. The WSAT consists of a translator whichconverts business process execution language (BPE4WS or BPEL) to an interme-diate representation (GSFA), and spin model checker [85] to check LTL properties.Antonova et al. [62] have presented a tool named testing of service implementations(TESSI), which supported test case generation, execution and management. The corefunctionality of the TESSI tool includes generation of simple object access proto-col (SOAP) request templates, definition of assertions at hypertext transfer protocol(HTTP), simple object access protocol (SOAP) and business process execution lan-guage (BPEL) variable levels, support of data driven testing, test execution and man-

82

agement. Looker et al. [174] discussed software implemented fault injection (SWIFI)based tools. The SWIFI tool allowed specific systems running on target hardware tobe effectively targeted without injecting faults into other parts of the system. Varioustools for test input generation using dynamic symbolic execution have been researchedextensively such as Pex [173], DART [188], Cute and Jcute [107]. DART [188] wasthe first tool for dynamic symbolic execution of C programs. Cute [107] is an ex-tension of DART for handling concurrent programs, where it’s Java version is namedJcute. The recent tool, Pex is a white box test generator for .NET programs.

Unified modeling language (UML) is a standardized general purpose modeling lan-guage used in the field of engineering. UML diagrams represent two different viewsof a system model, static and dynamic. Static or structural view emphasizes the staticstructure of the system using objects, attributes, operations and relationships. Thestatic view includes class diagrams and composite structure diagrams. Dynamic orbehavioural view emphasizes the dynamic behaviour of the system by showing col-laborations among multiple objects and changes to the internal states of objects. Thedynamic view includes sequence diagrams, activity diagrams, and state machine di-agrams. Many testing techniques have been reported towards the generation of testcases. The scenario-based techniques are based on coverage criteria. The model-based techniques identify respective test cases for the software using models such asUML diagrams. The path-based testing is based on static as well as dynamic controlflow of the software. Static path testing is carried out by symbolic execution whereasdynamic path testing is carried out by executing the program. Finally, the goal-basedtechniques identify test cases covering a selected goal such as a statement or branch,irrespective of the path taken.

Samuel et al. [191] generated test cases from UML communication diagram. Theygenerated communication tree from communication diagram (CD), performed post-order traversal on conditional predicates and apply function minimization technique togenerate test data.They implemented a tool named UML behavioral test case generator

(UTG) to demonstrate the generation of test cases.

Soldal et al. [142] defined a test generation scheme based on a conformance testing anda formal operational semantics for sequence diagrams, which takes input as sequencediagrams that may contain the operators assert and neg and that produces tests in theform of sequence diagrams. The algorithm is based on a formal operational semanticsfor sequence diagrams and is an adaption of J. Tretmans et al. [98]. The operational se-mantics and the test generation algorithm are implemented in term rewriting languageMaude defined by M. Clavel [135].

Prasanna et al. [136] have presented a model based approach for automated genera-tion of test cases in object-oriented systems. They consider UML object diagram and

83

genetic algorithm’s tree crossover operator to generate new generation tree. The newgeneration of trees is converted into binary trees. Then, depth first search traversal isperformed on binary trees to generate test cases.

Sharma et al. [144] have presented use case diagram graph (UDG) and sequencediagram graph (SDG) for generating test cases from use case and sequence diagramsrespectively. They integrated UGD and SDG into system testing graph (STG). TheSTG is traversed to get test cases.They use a PIN authentication scenario of an ATMsystem. Also, they implemented a tool with the help of MagicDraw and Rational Rose.

Kundu et al. [52] have presented an approach for generating test cases from UML 2.0activity diagrams with use case scope. They defined an activity path coverage criterion.Additionally, the generated test cases are capable of detecting various types of faultswhich may occur.

Swain et al. [200] illustrated a method to derive test cases from analysis artifacts suchas use cases and their corresponding sequence diagrams. They generated test casesfrom use case dependency graph (UDG) and concurrent control flow graph (CCFG)from use case diagram and corresponding sequence diagram respectively. They gen-erated test case using full predicate coverage criteria. They used library informationsystem (LIS) to demonstrate their work.

Nayak et al. [3] have proposed an approach of synthesizing test data from informa-tion available from class diagrams, sequence diagrams and object constraint language(OCL) constraints. They generated a structured composite graph (SCG), incorporatingsystem-wide information to generate test cases.

Shanthi et al. [1] focused on test case generation from UML sequence diagram usinga genetic algorithm. They extracted information from sequence diagram and creates asequence dependency table (SDT). With the help of SDT test path are generated. Andthen genetic algorithm are used to prioritize test cases.

Kosindrdecha [166] have proposed a technique to derive and generate tests from statechart diagram. They carried out an extensive literature survey and classified vari-ous test generation technique as specification-based techniques, sketch diagram-basedtechniques, and source code-based techniques. Grigorjevs et al. [102] have presented atesting technique for model generation from UML sequence diagram to UML Testingprofile. They discussed principles of model transformation to generate test cases fromsequence diagram and shows practical approach to specific model. Patnaik et al. [51]put an effort to represent deadlock situations with the help of graph in a distributed en-vironment. They proposed an algorithm to detect deadlock with the help of real timebanking system and generated test cases for it.

Panthi et al. [228, 229] generated test cases from sequence diagram automatically.

84

They named their approach as automatically test sequences generation from sequencediagram (ATGSD). In ATGSD, they first converted the sequence diagram into se-quence graph then, the graph is traversed to select the predicate functions. Next, theytransformed predicate into the source code. Then, they constructed extended finitestate machine (EFSM) from the code. Finally, they generate test data correspondingto the transformed predicate functions and stored the generated test data for futureuse. They demonstrated their work based on bank ATM system and tool based onModelJunit library.

Sumalatha et al. [227] have presented a technique to generate test cases from integrat-ing UML activity and sequence diagram. They used breadth first search on activitysequence graph which is generated from merging activity and sequence diagram. Priyaet al. [199] generated test path from UML sequence diagram of a medical consultationsystem. Swain et al. [192] used condition slicing and generate test cases from UMLinteraction diagrams. They generated test cases from message flow dependence graphfrom UML sequence diagram and then applies conditioned slicing on a predicate nodeof the graph.

Meena [53] generated test cases from UML sequence diagram and interaction overviewdiagram. They transformed the sequence diagram and interaction overview diagramto an intermediate form called UML interaction graph (UIG) using XMI code. Then,UIG is traversed to find the all valid path and generate test cases. Kaur et al. [137]developed a methodology to derive test cases using conditional predicates.

The control flow graph (CFG) is an efficient intermediate representation or form ofa program or software which is used to analyze various properties of a program andwhich in turn would be useful for software testing, software maintenance, and softwaremeasure or metrics. Also, CFG makes easier the understandability and comprehensi-bility of the source code which is more important for complex software like service-oriented software (SOS). A large number of CFG construction approaches have beenproposed for many programming languages like procedural, object-oriented program-ming and aspect-oriented etc.

As stated earlier, model-based testing is considered as black-box testing but businessprocess execution language (BPEL) testing, is performed in a white-box manner [185,267]. Using business process execution language (BPEL), tester has access to theinternal logic of the whole business process. As a result, tester can generate test casesaccording to the required coverage criteria.

Jehan et al. [214] have proposed a test case generation approach that combines con-straints which are extracted from the business process execution language (BPEL)process activities directly with pre-conditions and post-conditions for called services.First, they transform a business process execution language (BPEL) program to a con-

85

trol flow graph. Then, they generated test data using the lp solver [163]. At last, theyexecuted the test cases using BPEL Unit tool [61].

Alemneh et al. [66] have proposed a static code analysis tool SAT4BSC to computemetrics and draw control flow graph (CFG) for BPEL source code. Ouyang et al. [43]have proposed a tool WofBPEL, which performed static analysis on business processexecution language (BPEL) processes by translating business process execution lan-guage (BPEL) processes into petri nets. This tool can detect conflicting messages,unreachable paths or activities and can serve as a garbage collector.

Yuan et al. [258], generated business flow graph (BFG) by converting business processexecution language for web service (BPEL) code to a control flow graph (CFG). It’sjust a specialization of control flow graph (CFG) for BPEL. Then they generated testcases from business flow graph (BFG). Endo et al. [17] have proposed a graph parallelcontrol flow graph (PCFG) that is composed of multiple CFGs representing servicecomposition and interactions among these CFGs and have also presented a tool thatsupports the proposed technique. Hou et al. [213] have proposed an approach whichconverts BPEL processes to message sequence graph (MSG) and then they generatedtest cases from this MSG. Other approaches for test case generation from BPEL pro-cesses is based on control flow graphs (CFGs), graph search algorithms, and constraintsolvers can be found in the literature [17, 123, 258].

Mao [44] have proposed a method for static slicing of business process execution lan-guage (BPEL) programs for understanding and debugging purpose. They created anextended control flow graph (ECFG) based on elements <flow> and <pick>. Then,data dependence relations between service participants are computed. Based on thisanalysis, a dependence graph named as BPDG is built by introducing the concept ofsynchronized edge. Subsequently, the static (backward / forward) slicing algorithm isillustrated with the help of BusinessTravelProcess [162].

Yee [45] have presented a test case generation tool employing a data dependency forweb services business process execution language (WS-BPEL or BPEL). In this ap-proach, data dependencies are defined using XPath expression for a BPEL process un-der test (PUT). These dependencies along with Type definitions in WSDL documentsare then used to automatically generate input test data and corresponding verificationconditions. Finally, test cases are executed using these data. Nonchot et al. [46] fo-cused on test case generation from a business process modeling notation (BPMN) withBPEL diagram and XSD schema (XSD). Lallai et al. [160, 161] extended the finitestate machine as the web service time extended finite state machine (WS-TEFSM)to generate test cases that aim to exercise the time constraints in web service com-positions i.e business process execution language (BPEL). They developed the toolBPEL2IF for the transformation of business process execution language (BPEL) to an

86

intermediate form, and TESTGen-IF to generate the test cases. Ma et al. [47] have pro-posed stream x-machine based testing techniques to BPEL and the stream x-machinegenerated test cases.

Linzhang et al. [248] have presented a technique that generated test cases from UMLactivity diagram using gray box method, where the model represented the expectedstructure and behavior of the system under test (SUT), and which were used for cre-ating reused design. Then, all the contextual information for test case generation,i.e. input or output sequence and parameters, the constraint conditions and expectedobject method sequence, are derived from each test scenario. Finally, the possiblevalues of all the input/output parameters are generated by applying category-partitionmethod. They developed a prototype tool UMLTGF to support the testing process.They overcome the limitations of white-box testing technique which was unable tofind all the potential paths. Then, test cases are generated which satisfied the path cov-erage conditions constructed by black-box testing. Their approach was able to resolvethe problems associated with both black-box and white-box testing techniques.

Kaur et al. [186] used UML statechart diagrams to automatically derive test paths us-ing graph coverage techniques. Additionally, they developed a tool which supportedTestOptimal. From statecharts, model coverage graphs were constructed with the helpof TestOptimal and then test paths were generated. The generated test paths coverednode coverage, edge coverage, edge-pair coverage and prime path coverage. Further,they used chinese postman and prefix-based algorithms for manual and automatic gen-eration of test cases. Bhattacharjee et al. [82] have presented a test case generationtechnique based on UML activity diagram and tabu search algorithm to find out thetest path with the highest priority. Gupta [124] generated test scenarios automaticallyfrom activity diagram using depth search (DFS) method. In this technique, they gener-ated a directed graph called activity flow graph (AFG) and an intermediate table calledactivity dependency table (ADT) automatically for each activity diagram. Automatedtest paths were generated from AFG and the test cases were generated to cover all thetest paths of the AFG. Ashu Mishra [18] generated test sequences using UML activ-ity diagram. Then, they used an ant colony optimization algorithm to prioritize testsequences.

Paradkar et al. [19] have proposed a model-based test data generation technique forsemantic web services. In their approach, test cases were generated using pre-definedfault models and semantic specification. Florencio [125] developed a tool, SOA testaccelerator (SOATA), to automate test creation in service-oriented architectures. Ku-mar [20] have proposed a model to get the automatic test cases for SOA based applica-tion. He applied different assertions on each service operation for generating the testcases. Kumar et al. [21] have proposed an automatic test data generation approach for

87

web services through XML schema. Their approach ensured the traceability of eachelement present in the XML schema by using XML tree table structure and furthergenerated test cases.

Zhang et al. [268] extended UML 2.0 activity diagram to describe the syntax and be-haviors of business process execution language (BPEL). They have mapped, businessprocess execution language (BPEL) structure activity such as sequence, pick, if, while,repeatuntil, flow to UML 2.0 activity diagram. Next, they generated XML instancesfrom the XML schema (XSD) using XML based partition testing (XPT) approach [15].The XPT divided the input domain into a subdomain such that, within each of themthere was no change in the program behavior. They implemented a tool, named testingby automatically generated XML instances (TAXI).

Ionita et al. [7] modeled services for water management system using SoaML serviceinterface diagram. They discussed the usefulness of SoaML for communication andmonitor water pollution on Romanian rivers. Ali et al. [169] have proposed Ambient-SoaML profile for mobile devices which changes location frequently. Fazziki et al. [8]have presented a process to align business requirement to service oriented architectureusing BPMN, SoaML, and component model. Gebhart et al. [145] evaluated designdecision such as loose coupling, high autonomy, discoverable etc. when designinga new service. Bhuyan et al. [183] have proposed a layered architecture which hadthe capability to analyze the developed services by comparing the users requirementsusing self-analysis database.

3.4 Summary

In this chapter, we have briefly reviewed the available work on slicing of object-oriented software and testing of SOA-based software relevant to our research. Wehave discussed the work on static and dynamic slicing of object-oriented program,slicing of UML, and SoaML models. Since there were no research reports availableon static and dynamic slicing of SOA-based software, we have briefly reviewed staticand dynamic slicing of object-oriented programs, architecture, slicing UML, and slic-ing of SoaML models. We also have discussed the reported literature for black-boxand model-based testing of SOA-based software. As dynamic slicing algorithms areused in interactive applications such as debugging and testing, to meet this, we attemptto develop dynamic slicing algorithms and testing techniques for SOA-based softwarein the subsequent chapters in alignment with the goals of this thesis.

88

CHAPTER - 4Static Slicing of Service-Oriented

Software

Nowadays many organizations are shifting their focus from technology-oriented busi-ness process to SOA (service-oriented architecture) based business process. Thisparadigm shift occurs due to major advantages offered by SOA over the traditionalmanual business processes. SOA enables organizations to align their business pro-cesses with changing customer needs creating flexible, and agile business environ-ments. Understanding such dynamic SOA enables one to have great insight and com-prehension of a business process. Since it is a difficult task, a better understanding ofsuch processes can be obtained through models.

Design models help organizations simplify and visualize business processes. UMLhas been widely used as a general purpose modeling language for object-oriented sys-tems which is not intended for modeling distributed systems like SOA [96]. Serviceoriented architecture modeling language (SoaML), an emerging standard for modelingSOA, is specified by object management group (OMG) and is supported by major ITvendors like IBM, Visual Paradigm, Eclipse and many other organizations. With thismotivation, we define our objective and scope of our work for this chapter as follows:

• Research Question and ObjectiveOur main research question is “are we able to compute the static slices of SOA-based software?”. This work partly answers the question by computing staticslices for service-oriented software (SOS) using SoaML service interface dia-gram.

• Scope of WorkThe scope of our work is limited up to SOS testing.

With above defined objective and scope, we present a novel technique for static slic-ing of service-oriented software (SOS) using SoaML (service oriented architecture

89

modeling language) service interface diagram. In this technique, a service interfacediagram is converted into an intermediate representation which we have named ser-

vice interface dependency graph (SIDG). The SIDG identifies service call dependency

and composite dependency from service interface diagram. Giving slicing criterion asinput, our algorithm traverses the SIDG and identifies the affected service interfacenodes. The novelty of our work lies in the computation of slices based on SIDG andits dependencies induced within SIDG.

We first present some basic concepts and definitions that will be used in our algo-rithm. Then, we discuss the intermediate program representation: service interface

dependency graph (SIDG). Next, we present our marking based static slicing (SS-SIM) algorithm for service-oriented software. Also, we present a brief description ofa slicing tool we have developed to implement our proposed static slicing algorithm.Then, we compare our algorithm with some related algorithms. Finally, we present theconclusion of this chapter.

4.1 Basic Concepts and Definitions

In this section, we discuss service architecture and its web service implementation.We then, define some important definitions which are essential for understanding staticslicing of service interface diagram discussed subsequently.

4.1.1 Service Architecture and Web Services

FIGURE 4.1: Class diagram of service architecture

The purpose of service architecture is to specify the service-oriented architecture (SOA) ofsome organization, community, component or process to provide mutual values [175]. As

90

shown in the Fig. 4.1, the class diagram of service architecture is composed of service inter-face diagram, service choreography diagram, service participant diagram and service con-tract diagram. The service interface diagram describes service and participant’s interactions.The service interface diagram is a kind of simple or service interface based on discriminatorcommunication protocol. The simple interface focuses on one-way communication that doesnot require the caller identity while the service interface requires two-way communicationamong the participants. The service interface may also describe the choreography of theservice which specifies information exchange and its sequence among the participants. Inshort, the service choreography diagram is a kind of UML sequence diagram representingcertain scenarios among the participants. The service participant diagram models the par-ticipants that play various roles in service completion. Service participants may be people,organizations, software or individuals that provide and/or consume service(s). The servicecontract diagram defines the agreement among the participants specifying how a service isto be provided and consumed. The participants must obey the agreement while the service isbeing invoked. The majority of our work is focused on service interface diagram.

From the implementation perspective of SOA, web services are the only available plat-form to realize SOA. A generic class diagram of web service has been depicted in Fig. 4.2.A generic web service includes three basic classes service registry, service consumer andservice provider. The service provider designs WSDL document and publishes in the ser-vice registry using publish() method. The Service consumer looks up the service registry forpossible match against business needs using discover() method and finally calls the matchedweb service using request() method and accordingly, the service provider responds with re-

sponse() method

FIGURE 4.2: Class diagram of web service

91

4.1.2 Some Important Definitions

A slice can be computed by finding different participants and the dependencies among themfrom service interface model. These participants can be identified based on a slicing crite-

rion.

Definition 4.1: Slicing CriterionFor a service interface dependency graph (SIDG) G of a service-oriented software havinga service interface (SI) node SI(n) with an edge symbolized with method M() from SI nodeSI(n) in G during the execution of a certain business scenario S, a slicing criterion is a triplet[SI(n),M(),S]. The slicing criterion represented by [SI(n),M(),S] is said to involve the par-ticipant of SI(n), and a method M() using composite and service call dependence edges. Itshould be noted that M() and S is ignored when static slices are computed, and the slicingcriterion becomes [SI(n)], only.

Definition 4.2: Service Interface Model SliceA service interface model slice is a part of service-oriented software consisting of the set ofall participants with their properties affecting directly or indirectly in method call M() basedon slicing criterion [SI(n),M(),S].

Definition 4.3: Static Slices of a Service Interface ModelLet a static slice of service interface dependency graph (SIDG) G with respect to slicingcriterion [SI(n)] be SSSIM(SI(n)). Let ((SI(n1),SI(n2)), . . . , (SI(n1),SI(k))) be the set of alldependence edges that can be traversed from SI(n) in the SIDG G. Then the static slice ofthe service interface model can be expressed as

SSSIM(SI(n))=((SI(n1),SI(n2))∪ . . .∪(SI(n1),SI(k))∪SSSIM(SI(n2))∪ . . .∪SSSIM(SI(k)))

4.2 Service Interface Dependency Graph (SIDG): Our Pro-posed Intermediate Representation of Service InterfaceModel

The SIDG represents an intermediate form of service interfaces and uses information avail-able from service interface model. It consists of interface nodes and different types of edgeslike composite dependence and service call dependence edges. The composite dependence

92

edge represents the existence of services within the organization. The service call depen-dence edge between consumer and provider represents service invocation from consumer toprovider.

4.2.1 Properties of Service Interface Dependency Graph (SIDG)

A class diagram of service interface dependency graph (SIDG) shown in Fig. 4.3 indicatesvarious elements in structuring SIDG. Each object of SIDG is composed of one or morenodes along with one or more edges representing various types of dependencies as shownin Fig. 4.3. A node in the class diagram represents participants and an edge representstheir association while participants play certain roles. As participants play various roles,we cannot differentiate the node types. A composite edge exists between a provider andthe organization which owns services. A service call edge exists between consumer andprovider. A service call is being followed by service response.

FIGURE 4.3: Class diagram of service interface dependency graph (SIDG)

4.3 Computing Static Slices of Service-Oriented Softwarefrom SIDG

In this section, first we describe our proposed algorithm for computing static slices of service-oriented software (SOS). Then we explain the working of our algorithm through an example.Below we discuss an example: TLS’s purchase order service (POS) [219] to explain ourproposed approach.

93

4.3.1 The SSSIM Algorithm

Now, we present a novel static slicing algorithm for service interface model. We named ouralgorithm static slicing of service interface model (SSSIM). The SSSIM algorithm takes theservice interface model and slicing criterion as input and produces static slices. The SSSIMalgorithm works in two Phases, Phase 1 construct the SIDG and Phase 2 traverse the SIDGto compute and display the static slices.

In Phase 1, the SIDG is constructed from the service interface diagram. The SIDG con-struction involves creation, initialization of service interface nodes and representing servicecalls or drawing composite dependence edges among the nodes. In second Phase, the con-structed SIDG is traversed for a given slicing criterion. The SIDG traversal identifies differ-ent service interface nodes forming the slices. The resulted slices are being displayed in theSIDG itself which helps SSSIM algorithm to save storage space as the resulted slices are notstored anywhere. The SSSIM algorithm assumes service interface diagram to be in XMLmetadata interchange (XMI) format.

Algorithm : SSSIM (Static Slicing of Service Interface Model) Algorithm.

Input : Service Interface Diagram in XMI format, and a Slicing Criterion

Output : Static Slices

Phase 1 : Construction of SIDG from service interface diagram1. For each node of service interface diagram do the followings:(a) Create a node SI(n).(b) Initialize the node.2. Add service call and composite dependence edgesfor each node SI(i), do followings:,for each node SI(j), do followings:,(a) Add service call dependence edge (SI(i),SI(j)), if node SI(i) calls service of nodeSI(j).(b) Add composite dependence edge (SI(i),SI(j)), if node SI(i)’s functionality is com-posed by node SI(j).Phase 2: Computation of static slicesFor each node SI(n) with slicing criterion [SI(n)], traverse and do the followings:(a) Mark the service call dependence edge (SI(i),SI(j)), if node SI(i) calls service ofnode SI(j).

94

(b) Mark composite dependence edge (SI(i),SI(j)), if node SI(i)’s functionality is com-posed by node SI(j).(c) Remove unmarked nodes from SIDG.(d) Display the marked nodes as sliced nodes.

Given the slicing criterion as input, the SSSIM algorithm computes the static slices by exe-cuting Phase 2 of the algorithm.

4.3.2 The SIDG Example

The service interface model for TLS’s purchase order service (POS) [219] is shown in Fig.4.4. TLS’s purchase order service submits electronic purchase orders (POs) that are receivedby RailCo’s order fulfillment service (OFS). It defines TLS as a consumer and RailCo asa provider. The TLS’s POS uses the POSOrder() operation of RailCo’s OFS and RailCo’sOFS uses the OFSConfirmed() operation of TLS’s POS. Corresponding to Fig. 4.4, an inter-mediate representation SIDG has been shown in Fig. 4.5. Since service interface may playvarious roles depending on business scenarios, we cannot distinguish the node types. Also,it shows three SI nodes, namely consumer, provider, and purchase order service. It definesservice call dependence edge between consumer and provider and composite dependenceedge between provider and purchase order service.

FIGURE 4.4: Service interface diagram of POS

95

FIGURE 4.5: SIDG of POS

4.3.3 Complexity Analysis of SSSIM Algorithm

In this section, we analyze the time and space complexity of our proposed SSSIM algorithm.The space complexity SSSIM is O(n2), where n is the number of service interface nodes.Phase 1 takes O(n) memory space to construct SIDG from XMI and Phase 2 takes O(n2)space to traverse, accumulate and to display slices. So, the computed space requirement isO(n2). The time complexity of SSSIM is O(n), where n is the number of service interfacenodes. Phase 1 and Phase 2, each requires O(n) time. Hence, the time complexity of ourSSSIM algorithm is O(n).

4.3.4 Working of SSSIM Algorithm

We will explain the working of our SSSIM algorithm using the example of SIDG given inFig. 4.5 which will be obtained at the end of Phase 1 of the algorithm. Let us computestatic slices for the slicing criterion Consumer. We have shown the SIDG obtained after thePhase 2 of SSSIM in Fig. 4.6(a) displaying the service interface nodes forming the slices.As the consumer, provider and purchase order service are being traversed from service calldependence edge and composite dependence edges they form the static slices. Similarly,for the slicing criterion Provider, the composite dependence edge is being traversed and thesliced nodes are shown in Fig. 4.6(b).

96

FIGURE 4.6: Marked SIDG showing the static slices w.r.t slicing criterion (a) Consumerand (b) Provider

4.3.5 Correctness of SSSIM Algorithm

In this section, we sketch the proof of correctness of our SSSIM algorithm.

Theorem 4.1 SSSIM algorithm always finds a correct dynamic slice with respect to a given

slicing criterion.

Proof. The proof is given through mathematical induction. Let S be a service-orientedsoftware for which a static slice is to be computed using SSSIM algorithm. For any given setof input values to S, the static slice with respect to the first node SI(n) is certainly correct,according to the definition. From this, we can argue that, the static slice with respect to thesecond node SI(m) is also correct. During static analysis of the service-oriented softwareS, assume that the algorithm has computed correct static slices prior to the node SI(u). Tocomplete the proof, we need only to show that the static slice computed after node SI(u) iscorrect. Note that the nodes that affect nodes SI(u) must have been affected prior to the nodeSI(u). It is obvious that the static slice SSSIM(SI(n)) contains all those nodes which haveaffected the node SI(u), since our SSSIM algorithm has marked all the incoming edgesto SI(u) only from those nodes on which node u is dependent. The Steps (a), and (b) ofPhase 2 of the SSSIM algorithm ensure that the node SI(u) is dependent (with respect to itsslicing criterion) on a node SI(v) if and only if the edge (u, v) is marked in the SIDG of theprogram S. If a node does not affect node SI(v), then it will not be included in the staticslice SSSIM(SI(n)). So, SSSIM(SI(n)) is a correct static slice. In other words, we can say thatthe static slices computed for the node SI(u) are correct. Therefore, the Steps (a), (b), and(c) of Phase 2 of the SSSIM algorithm ensure that the static slices computed for the nodeSI(u) are correct. This establishes the correctness of the algorithm.

97

4.4 Implementation and Experimental Results

In this section, we present an implementation of our concept. We have named our slicingtool SOS Static Slicing (SOSSS). The design of our tool SOSSS has been shown in Fig. 4.7.It takes SoaML service interface diagram in XMI form as input, which is being parsed byextensible stylesheet language transformations (XSLT) [251]. The XSLT extracts and gathersinformation related to nodes and generates SIDG. The graphical user interface (GUI) acceptsslicing criterion as input, which is being used to traverse and compute static slices. We haveused visual paradigm professional edition [230] for modeling and exporting SoaML serviceinterface diagram into XML metadata interchange (XMI). We have used Java script to inputthe slicing criterion. Java applet and JGraph [109] are used to display SIDG. According toKundu et al. [52], it is difficult to construct control flow graph from XMI representation. So,we have used XSLT to parse XMI and to traverse the SIDG. Static SIDG will be generatedwhen the user clicks on Static Graph button. Fig. 4.8 shows the resultant slices, with respectto the slicing criterion Consumer which is supplied as input. Similarly, an alternative slicingcriterion Provider is given as input and static slices are being computed.

SoaMLService Interface Diagram

XSLT SIDG GUI

(XMI Representation)

Slicing

Criterion

ComputedStaticSlice

FIGURE 4.7: Design of our tool

4.4.1 Experimental Results

We have tested the working of SSSIM algorithm using the case study examples as stated in[194] with a service call and composite dependencies using SIDG.

The system configuration used to run SSSIM algorithm is windows 7 professional ser-vice pack 1, intel(R) core(TM) i3-3240 CPU@ 3.40GHz running at 3.40 GHz, with 4.00 GBRAM. We studied the run-time requirements of our SSSIM algorithm for these case stud-ies and for several runs. All the measured times reported in this section are overall times,including parsing and building of SIDG representation. Table 4.1 summarizes the average

run-time and memory space requirements of SSSIM algorithm. From Table 4.1 the followingobservations can be made:

98

FIGURE 4.8: Static slices of POS w.r.t slicing criterion Consumer

1. The SIDG (Service Interface Diagram) is a connected and acyclic graph which is usedas an intermediate representation for computing the slices.

2. The SIDG is a connected, acyclic and n = e + 1.

3. Every two service interface nodes of SIDG are joined by a unique path.

As we are not aware of the existence of any algorithm for static slicing of service-orientedprograms, so we have not presented any comparative results. We have presented only theresults obtained from our experiments. Since we computed the static slices at different ser-vice interface nodes of a service interface diagram, we have calculated the average run-timerequirements of the SSSIM algorithm.

From the experimental results, it can be observed that the average run-time increasessublinearly as the number of service interface nodes increases in a service interface diagramas shown in Fig. 4.9. Average run-time increases linearly as the number of service interfacenodes in SIDG increase. In Fig. 4.9, for 13 nodes the average run-time is 0.60 Seconds. Theexperiments have been performed for graphs having maximum number of nodes 13. SSSIMalgorithm is scalable to handle the real situation where large numbers of nodes arise. But, thetime complexity and space complexity will increase significantly. The performance resultsof our implementation agree with the theoretical analysis.

99

FIGURE 4.9: Average run-time of SSSIM algorithm w.r.t number of nodes

TABLE 4.1: Average run-time and memory space requirements of SSSIM algorithm

Sl. No. Benchmark Model # Nodes # Edges SlicingCrite-rion

Avg. MemorySpace

in SIDG in SIDG [SI(n)] Run-Time

Reqs.

(inSec)

(in KB)

1 Online Shopping System(OSS)

13 12 Consumer 0.60 6.9

2 Hotel Automation Software(HAS)

9 8 Consumer 0.50 6.8

3 Medicine Shop AutomationSoftware (MSAS)

9 8 Provider 0.50 6.9

4 Bookshop Automation Soft-ware (BAS)

9 8 Consumer 0.50 6.8

5 Road Repair and TrackingSystem (RRTS)

8 7 Provider 0.49 6.8

6 Restaurant Automation Sys-tem (RAS)

8 7 Consumer 0.50 6.9

7 Student’s Auditorium Man-agement Software (SAMS)

8 7 Provider 0.49 6.8

8 Library Information System(LIS)

8 7 Consumer 0.50 6.8

9 Software Component Cata-loguing Software (SCCS)

7 6 Consumer 0.40 6.8

10 Supermarket AutomationSoftware (SAS)

7 6 Consumer 0.40 6.9

11 Judiciary Information System(JIS)

6 5 Consumer 0.20 6.5

12 Municipality Garbage Col-lection Automation Software(MGCAS) [Appendix-A]

5 4 Consumer 0.10 6.5

13 Motor Parts Shop Software(MPSS)

4 3 Consumer 0.10 6.3

14 Railway Reservation Soft-ware (RRS) [Appendix-A]

4 3 Provider 0.09 6.3

15 House Rental Software(HRS) [Appendix-A]

4 3 Provider 0.09 6.3

100

4.5 Comparison with Related Work

To the best of our knowledge, no work has been done on static slicing of SOA-based soft-ware. The only comparable work to our work is the work of Lallchandani et al. [99, 110].With respect to asymptotic analysis both perform equally. Lallchandani et al. [99, 110]have merged class diagram and sequence diagram in order to get better information of thesystem, while we used SoaML service interface diagram. From the implementation perspec-tive, Lallchandani et al. [99, 110] used document object model (DOM) parser, while we usedXSLT parser.

4.6 Conclusion

In this chapter, we have proposed a novel technique for static slicing of SOA-based softwareusing SoaML service interface diagram. Such slicing based on SoaML service interfacediagram is difficult due to distributed participants with implicit dependencies among themin SOA-based software. We first construct SIDG, an intermediate representation for serviceinterfaces. Then, our SSSIM algorithm uses SIDG information to compute static slices. Suchstatic slices can be used for understanding change impact analysis, and SOA comprehensionetc.

The algorithm in this chapter is not suitable to be applied to SOA-based web servicesrunning on several nodes connected through a network. Even, such static slices are smallat higher-level of abstractions as in case of service interface diagram, but at lower-levelof implementation, it may contain large number of web service statements affected by thevalues of variables. In the next chapter, we will extend our framework to compute dynamicslices of service-oriented software in which services run on several nodes, as is common inClient-Server applications.

101

CHAPTER - 5

Dynamic Slicing of Service-OrientedSoftware

One major drawback of the static slices computed in the last chapter was that they werefound to be highly abstracted. This was due to two main reasons. First, the computed staticslices were small in terms of number of service interface nodes. And, the slicing criterionconsidered service interface nodes based on static analysis rather than any particular businessscenario. Such a slice computation exercise decreases the utility of those slices, especiallywhen the requirement arises to identify specific services based on a certain business scenarioexecution. Though such static slices can be used in applications such as understanding,but when we need to develop a slicing-based technique for test case generation, the utilityof small static slices becomes limited. Therefore, there arises a need to compute slicesconsidering a specific business scenario execution along with a particular input. These slicesare generally termed as dynamic slices. A major goal of any dynamic slicing techniqueis efficiency since the slicing results may be used during interactive applications such asprogram debugging and testing. Efficiency is especially an important concern for slicingSOA-based software since their sizes are typically very large. Large software results in verylarge intermediate graphs and can result in response times of several hundreds of seconds.

Many of the real life SOA-based software services are distributed which run on differ-ent machines connected to a network. It is usually accepted that testing and debugging ofservices are much harder compared to those of sequential programs. The non-deterministicnature of distributed services, statelessness, non-availability of source code, unsynchronizedinteractions among services, and dynamic nature are some reasons for this difficulty. An in-creasing amount of resources are being spent in understanding, debugging, testing and main-taining these software. Slicing techniques promise to come in handy at this point. However,research results in slicing SOA-based software have not been reported in the literature. Itis the objective of this chapter to present our work concerning development of a dynamicslicing algorithm for SOA-based software.

102

SoaML (Service oriented architecture modeling language) diagrams are the basic mod-eling artifacts for service-oriented architecture (SOA). These SoaML models can be used fortesting service-oriented software (SOS). Testing can be planned at the design phase of soft-ware development life cycle. With this motivation, in this chapter we propose a new globaldynamic slicing algorithm for computing slices of SOA-based software. Only the interoper-

atibility, composibility, and non-availability of source code issues are addressed here. Withthis context, we present a novel technique to compute global dynamic slices for service-oriented software (SOS) based on SoaML Sequence Diagram. In our technique, we firstmap each message in sequence diagram with the corresponding web service messages. Thismapping is observable. After that, we construct an intermediate representation of SoaMLsequence diagram which we called service-oriented software dependence graph (SOSDG)which is an intermediate representation that needs to be stored and traversed to get a globaldynamic slice as and when web services get executed. This SOSDG identifies data, control,intra-service and inter- service dependencies from SoaML sequence diagram and from webservice execution. For a given slicing criterion our algorithm computes global dynamic slicefrom SOSDG and identifies the affected service. The novelty of our work lies in comput-ing of global dynamic slices based on SOSDG, its dependencies induced within or acrossorganizations and small slices.

The rest of this chapter is organized as follows. Section 5.1 introduces a service-orientedsoftware choreography example of buying a product from the online retailer and its mappingwith web services. Section 5.2 presents basic definitions relevant to our proposed algo-rithm and extensions to dynamic slicing technique. Our intermediate representation SOSDG

is discussed in Section 5.3. Section 5.4 presents our MBGDS (marking based global dy-namic slicing) algorithm for computing global dynamic slice of service-oriented software,its working, correctness proof and theoretical complexity analysis. Section 5.5 presents theimplementation and experimental result covering our tool SOSDS’s design, implementation,data sets and results obtained. Section 5.6 compares our work with some existing work. Andfinally, Section 5.7 concludes the chapter.

5.1 Service-Oriented Software Example: Online ShoppingSystem

Let’s take a real-world example to demonstrate service-oriented software. Buying a productfrom the online retailer is a good example of service-oriented software choreography. Gen-erally, a product seller registers its product with an online retailer. Other service providersmay also register for shipping and logistic service with retailer too. This registration ser-

103

vice interface is being provided by the online retailer. When a customer wants to buy aproduct, customer searches the product at online retailer. Thus, searching a product by cus-tomer represents a web service. Once the product is found, the customer goes for buyingit. The buying service is a composite service which first checks for user authenticationthrough login. Again this login service is being provided by the retailer for their registeredusers or users may signup or else use the third-party login service like www.facebook.com

or www.gmail.com. Once the customer successfully logged on, the customer can go to makepayment or add the product to shopping cart for later payment or can use the cash on delivery(COD) options. The payment service interface is being provided by various banks. The userselects the type of card, the bank and other information and proceeds for payment. Once thetransaction is successful, the order is being confirmed and the product is being sent to thecustomer address. This service-oriented software choreography is best described using theSoaML sequence diagram shown in Fig. 5.1

The product registration() service accepts product name, quantity, price, seller nameand contact address as input or arguments and returns successful or unsuccessful messagesdepending on the service computations. Similarly, the couriercompany registration() ser-vice accepts shipping company name, address and charges as input or arguments and returnssuccessful or unsuccessful messages depending on the service computations. These serviceproviders (product seller, courier company etc.) may register the products or services suc-cessfully at the begining so that their product can be found at an online retailer. Next, thelogin() service accepts the username and password and authenticate the user’s credential. Thesignup() service signs users with mobile no, username and password etc. The search() ser-vice accepts product name, pin code, and quantity and lists the results if the product is found.The search() service is a composed service which checks product availability at particularaddress using a pin code. The add to cart() service accepts product name and quantity andputs the product into user cart. The add to cart() needs prior execution of the services lo-

gin() or signup() or thirdparty login(). The make payment() service accepts card type, cardno, expiry date, PIN, OTP etc. for online payment through registered payment gateways.These payment gateways are being provided by banks for their registered customers whenrequested. Next, the make courier() service accepts the customer name, address, contact no,product name, and quantity, and send the product with assigned tracking ids.

In this service choreography, we can see that the product registration(), couriercom-

pany registration(), login(), signup(), search(), and add to cart() are the services being pro-vided by online retailer, while make payment(), make courier() and thirdparty login() ser-vices are being provided by other service providers or parties.

104

FIGURE 5.1: The SoaML sequence diagram for buying a product105

The successful registration of sellers or courier companies depends on service levelagreement (SLA) defined by mutual understanding between parties. This SLA defines inter-faces, choreography and any terms and conditions. The service level agreement (SLA), bindsboth the parties about how a service is to be provided and consumed. Customer works withSLA and contracts as well. Typically these are negotiated via human intervention betweenthe customer and the service provider. The expectations of the customer and the reputationof the service provider are key parts of those negotiations. The service contract needs to bedocumented to formalize the required processing resources by the individual party. Thesecontracts can be best modeled as SoaML service contract diagram as shown in Fig. 5.2.

FIGURE 5.2: A SoaML service contract diagram involving multiple parties

5.1.1 Mapping of Service Choreography Message With Web Service

By looking up the choreography messages one can carry out a generic mapping of servicechoreography messages with web services. Fig. 5.3 shows this mapping along with chore-ography message fragments. It maps the input message to the corresponding simple objectaccess protocol (SOAP) request message of web service and output messages with simpleobject access protocol (SOAP) response messages. A static analysis reveals that the mes-sage set {1, 1.1, 1.2} corresponds to the product registration() service, message set {2,3, 3.1} corresponds to the couriercompany registration() service, message set {4, 4.1, 4.2}corresponds to the login() service, message set {5, 5.1, 6, 6.1, 7.1} corresponds to the third-

party login() service, message set {8, 8.1, 8.1.1, 8.1.1.1, 8.1.1.2} corresponds to the signup()

service, message set {8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1, 8.1.1.2.1.1.1.1} corresponds to theadd to cart() service, message set {11, 12, 12.1, 12.1.1, 12.1.1.1, 14, 15, 15.1, 15.1.1, 16,17, 17.1, 18, 19, 20} corresponds to the make payment() service, and message set {25, 25.1,26, 26.1, 27, 27.1, 28, 29, 29.1} corresponds to the make courier() service. This mapping isuseful to run and analyze the web service with corresponding SOAP messages.

106

FIGURE 5.3: A static mapping of service choreography messages with web services107

5.2 Basic Definitions

Before presenting our global dynamic slicing algorithm, we introduce a few definitions thatwould be used in our algorithm. Also, we extend the definitions pertaining to compute dy-namic slice.

Definition 5.1: def(m)let m be a message node in service-oriented software choreography (SOSC). A node n is saidto be def(m) node if n defines(assigns) values to variables of message node m.

Consider the service-oriented software choreography (SOSC) of Fig. 5.1 and its service-

oriented software dependency graph (SOSDG) of Fig. 5.5. In the SOSDG of Fig. 5.5, node1 is the def(product name) node.

Definition 5.2: use(m)let m be a message node in SOSC. A node n is said to be use(m) node if n uses the values ofvariables assigned by message node m.

In the SOSDG of Fig. 5.5, nodes 1.1 and 1.2 are the use(product name) node.

Definition 5.3: recentDef(m)For each message m, recentDef(m) represents the node corresponding to the most recentdefinition of the message variable def(m) in particular service execution history (SEH).

In Fig. 5.5, recentDef(product name) is same at any message nodes, since there is nomessage node which changes the value of message variable product name. Hence, recent-

Def(m) is same as def(m).

Definition 5.4: Web Service Control Flow Graph (WSCFG)A web service control flow graph (WSCFG) of a service-oriented software choreography

SOSC is a directed graph (N, E, Start, Stop), where each node n ∈ N represents message ofservice choreography SOSC, while each edge e ∈ E represents control transfer among nodes.Nodes start and stop are two unique nodes representing entry and exit of the service-oriented

software choreography, respectively. There is a directed edge from node a to node b if con-trol may flow from node a to node b. The WSCFG of the service-oriented software given inFig. 5.1 (through a SoaML sequence diagram) is shown in Fig. 5.4.

Definition 5.5: Service Execution CaseA test case is a triplet [I,S,O] where I is the input to the system at state S and O is the

108

expected output. It consists of run-time input values read by the sequential program. Thisdefinition is insufficient for SOA-based software which gives various challenges due to itsinherent features like dynamic binding, agility and many others.

We define service execution case (SEC) as the set of information required to guaranteerepeatability. By repeatability, we mean that each service executes same message and exe-cution of each message sees the same values for each of the service variables.

Definition 5.6: Service Execution PointIn the sequential program, the execution point is a point in that flow of execution. An execu-tion point is defined for a process and for the occurrence of statement that has been executedby this process. Because of multiple flow of execution in service-oriented software (SOS)

we define a service execution point (SEP) by a pair (Sk,M ji ) where M j

i is the j th occurrenceof message Mi executed by the web service Sk.

This definition imposes that the service has already been executed that occurrence of themessage or currently executing it. It allows the same messages to be executed by variousservices.

Definition 5.7: Service Execution HistoryAn execution history is defined for specific execution case. A service execution history (SEH)

is the sequence of service execution points (SEPs) in the order in which they are executed bythe services.

Definition 5.8: Service Choreography Execution HistoryIt merges the service execution history (SEH) of each service into a single set. Sorting suchset is difficult due to distributed environment. But it is important to maintain the order inwhich one SEP has influenced the execution of another. It is possible to have more than oneservice choreography execution history (SCEH) for a given service execution case.

Definition 5.9: Slicing Criterion for Service-Oriented Software ChoreographyWe define the slicing criterion for service-oriented software choreography (SOSC) as thetriplet (var, (Sk,M j

i ), SEC) where var is the message variable used at m, and (Sk,M ji ) is the

service execution point (SEP) with input service execution case (SEC).

109

FIGURE 5.4: The WSCFG of the service choreography given in Fig. 5.1110

Now, we define some new dependencies like intra-service and inter-service dependencieswhich arise in case of service-oriented software. Then, we define local dynamic slice andglobal dynamic slice.

Definition 5.10: Intra-Service DependencyIn a sequential program, the occurrence of the statements on which the current statementis dependent has already been executed. This is not necessarily correct for service-oriented

software (SOS). Intra-Service Dependencies are used to indicate that the state of service atthat point depends on the execution of a message by another service. We define intra-service

dependence edge (ni,nj) as an edge denoting that:

1. the two nodes (ni,nj) are being executed by two distinct services, Si and Sj respec-tively; and

2. the state of service Si at node ni directly depends on the execution of the node nj byservice Sj .

3. These services Si and Sj are being provided by a single service provider.

Intra-service dependencies can also reflect data or control dependencies.

Definition 5.11: Inter-Service DependencyWe define inter-service dependence edge (ni,nj) as an edge denoting that:

1. the two nodes (ni,nj) are being executed by two distinct services Si and Sj respec-tively; and

2. the state of service Si at node ni directly depends on the execution of the node nj byservice Sj .

3. These services Si and Sj are being provided by more than one service provider.

Inter-service dependencies may also reflect data or control dependencies.

The global dynamic slice computation is based on all the types of dependencies that havebeen defined earlier. We define two types of dynamic slices global dynamic slice and local

dynamic slice.

Definition 5.12: Global Dynamic Slice of Service-Oriented Software ChoreographyWe define global dynamic slice of service-oriented software choreography (SOSC) with re-spect to the slicing criterion (var, (Sk,M j

i ), SEC) as the subset of service-oriented software

111

choreography (SOSC) messages whose execution really affected the value of message vari-able var, as observed at the service execution point (Sk,M j

i ), for the service execution caseSEC.

Definition 5.13: Local Dynamic Slice of Service-Oriented Software ChoreographyWe define local dynamic slice for a service Sl with respect to a slicing criterion (var, (Sk,M j

i ),

SEC) as the subset of service Sl messages whose execution really affect the value of the givenmessage variable var, as observed at the service execution point (Sk,M j

i ), for the service ex-ecution case SEC. It is a way to filter out messages other than executed by service Sl.

5.3 Service-Oriented Software Dependence Graph (SOSDG):Our Intermediate Representation of Service-OrientedSoftware

This section introduces a method for efficient representation of service-oriented softwarein SOA environment. This representation is later used to compute dynamic slices. Wenamed this representation service-oriented software dependence graph (SOSDG). Each mes-sage in a sequence diagram is represented as a node along with their number in SOSDG.This message node also maps with corresponding input or output message of web service.This SOSDG captures control dependencies from static analysis of sequence diagram. Italso captures data, intra-service and inter-service dependencies from run-time analysis ofcorresponding web service execution. The inter-service dependencies may cross organiza-tional boundaries. We also depict web service nodes for simplifying the SOSDG along withmapped numbers. The web service node may belong to more than one service provider. Fig.5.5 shows the SOSDG for Fig. 5.1.

Further, service-oriented software dependence graph (SOSDG) can be defined for a ser-

vice choreography execution history (SCEH). It is a tuple (S,G), where S is the set of servicenodes and G is the set of web service control flow graph (WSCFG). The web service con-

trol flow graph (WSCFG) is a tuple (M,A), where M is the set of message nodes and A isthe set of dependence edges that we defined earlier. The web service control flow graph

(WSCFG) shows the control dependencies of message occurrence within that graph. In ad-dition data, intra-service and inter-service dependence connect occurrence of messages ofdistinct graphs. This set of web service dependence graphs and the edges between themform the service-oriented software dependence graph (SOSDG). For any instance of ser-

vice choreography execution history (SCEH), it contains all the web services which haveexecuted at least one message in that SCEH. If a web service is contained in that set, its

112

web service control flow graph (WSCFG) is a subgraph of the service-oriented software de-

pendence graph (SOSDG). When a web service executes its first message, it is added to S

and this message forms the first node of its WSCFG. When a web service executes othermessages, its WSCFG is updated.

FIGURE 5.5: The SOSDG of the service choreography given in Fig. 5.1

113

5.4 Marking Based Global Dynamic Slicing (MBGDS) Al-gorithm

In this section, first, we briefly describe our MBGDS algorithm. Then, we present thepseudo-code of the algorithm. Subsequently, we discuss the complexity of our algorithm.

5.4.1 Overview of the MBGDS Algorithm

We first provide a brief overview of our global dynamic slicing algorithm. Before executionof a service-oriented software choreography (SOSC) and its services, WSCFG and SOSDGare constructed statically. We permanently mark the control dependence edges as they don’tchange during the execution of services. We consider all the data dependence edges, intra-service dependence edges and inter-service dependence edges for marking and unmarkingduring run-time. During execution of the SOSC and services, we mark an edge when itsassociated dependence exists, and unmark when its associated dependence ceases to exist.After each message m is executed, we unmark all incoming marked dependence edges ex-cluding the control dependence edges, associated with the service Si, corresponding to theprevious execution of the node m. Then, we mark the dependence edges corresponding tothe present execution of the node m.

During the execution of the service-oriented software choreography (SOSC), letGlobal Dynamic Slice(s,m) with respect to the slicing criterion (s,m) denotes the global dy-namic slice with respect to the most recent execution of the node m, for given SEC. Let{(z1,m), (z2,m), . . . , (zk,m)} be all the marked incoming dependence edges of m in theupdated SOSDG after the execution of message m. Then, it is clear that global dynamic slicewith respect to the present execution of the node m, for the service Si, with input SEC, isgiven by

Global Dynamic Slice(s,m) = {z1, z2, . . . , zk} ∪ Global Dynamic Slice(z1,m) ∪Global Dynamic Slice(z2,m) ∪ . . . ∪Global Dynamic Slice(zk,m)

Let {m1,m2, . . . ,mk} be all the message variables used or defined as node m. Then, wedefine global dynamic slice of the message m asGlobal Dynamic Slice(s,m) =Global Dynamic Slice(m1,m)∪Global Dynamic Slice(m2,m)

∪ . . . Global Dynamic Slice(mk,m)

114

Our slicing algorithm works in three main phases:Phase 1: Construction of the intermediate representation graph,

Phase 2: Managing the SOSDG at run-time, and

Phase 3: Computing and displaying the global dynamic slice.

In Phase 1 of our MBGDS algorithm, the WSCFG is constructed from a static analy-sis of the SOSC. Also at this stage, using the WSCFG the static SOSDG is constructed.The Phase 2 of the algorithm is responsible for maintaining the SOSDG during run-time.The maintenance of the SOSDG at run-time involves marking and unmarking the differentdependencies such as data dependencies, control dependencies, intra-service dependenciesand inter-service dependencies as they arise and ceases. Phase 3 is responsible for comput-ing the global dynamic slice for a given slicing criterion using updated SOSDG. It computesthe global dynamic slice through table look up. So, when a request for a slice is made, it isobtained immediately, as it is already available in a table. Thus, after statically construct-ing the SOSDG of a given service Si in a service-oriented software choreography (SOSC),our global dynamic slicing algorithm can compute global dynamic slice with respect to anygiven slicing criterion.

We now present our MBGDS algorithm for service-oriented software choreography (SOSC)in the form of pseudo-code.

Algorithm : Marking Based Global Dynamic Slicing (MBGDS) Algorithm.

Input : Service-Oriented Software Choreography (SOSC) and Slicing Criterion(var, (Sk,M

ji ), SEC) // Slicing criterion given during run-time

Output : Global Dynamic Slices // Global dynamic slices are extracted during run-time

Phase 1: Constructing Static Graphs WSCFG and SOSDG

1. WSCFG Construction

(a) Node Construction

i. Create two special nodes start and stop.

ii. For each message m of a service-oriented software choreography(SOSC) do the the followings:

115

A. create a node m.

B. Initialize the node with message variables used or defined.

(b) Add control flow edges

for each node ni do the following

for each node nj do the following

Add control flow edge (ni,nj) if control flow from node ni tonode nj.

2. SOSDG Construction

(a) Add control dependence edges

for each test(predicate) node ni do the following

for each node nj in the scope of ni do the following

Add control dependence edge (ni,nj) and mark it.

(b) Add data dependence edges

for each node ni do the following

for each message variable used at ni do the following

for each reaching definition nj of message variable do the fol-lowing

Add data dependence edge (ni,nj) and unmark it.

(c) Add intra-service dependence edges

for each node ni in service Si do the following

for each node nj in service Sj do the following

Add intra-service dependence edge (ni,nj) if edge is eitherdata or control dependence edge and the state of serviceSi at node ni directly depends on the execution of the nodenj by service Sj and both services are provided within orga-nization. Unmark it.

(d) Add inter-service dependence edges

for each node ni in service Si do the following

for each node nj in service Sj do the following

116

Add inter-service dependence edge (ni,nj) if edge is eitherdata or control dependence edge and the state of serviceSi at node ni directly depends on the execution of the nodenj by service Sj and both services are provided by morethan one service providers. Unmark it.

Phase 2: Managing SOSDG at run-time

1. Initialization: Do the following before execution of each message m of servicesSi of the service-oriented software choreography (SOSC), consisting of set(S1,S2,. . . ,Sk).

(a) Set Global Dynamic Slice(s,m) = φ for every message m used or definedat every node m of the SOSDG.

(b) Set recentDef(m) = NULL for each message variables in service Si.// end of initialization

2. Run-time Updation of SOSDG: Run the web services and carry out the followingafter each message m of the service corresponding to the SOSC s, and SECfor each Si of SOSC gets executed.

(a) Unmark all incoming marked dependence edges excluding the controldependence edges, if any, associated with message m of the service Si,corresponding to the previous execution of the node m.

(b) Update data dependencies: For every message variable used at node m,mark the incoming data dependence edge corresponding to the mostrecent definition recentDef(m) of the service Si in SEH .

(c) Update intra-service dependencies: If m is use(m) node, then mark the in-coming intra-service dependence edge, if any, corresponding the asso-ciated def(m) node which belongs to same party.

(d) Update inter-service dependencies: If m is use(m) node, then mark the in-coming inter-service dependence edge, if any, corresponding the asso-ciated def(m) node which belongs to other party.

(e) Update the global dynamic slice for different dependencies:

i. Handle data dependency: Let {(d1,m),. . . ,(dj,m)}be the set of markedincoming data dependencies to m. Then,

117

Global Dynamic Slice(m) ={d1, d2, . . . , dj}∪Global Dynamic Slice(d1)∪Global Dynamic Slice(d2) ∪ . . . ∪Global Dynamic Slice(dj),where d1, d2, . . . , dj are the initial nodes of the corresponding markedincoming edges of m.

ii. Handle control dependency: Let (c, m) be the marked control de-pendence edge. Then,Global Dynamic Slice(m) = Global Dynamic Slice(m) ∪ {c} ∪Global Dynamic Slice(c).

iii. Handle intra-service dependency: Let m be a use(m) node and(x,m) be the marked intra-service dependence edge associated withcorresponding def(m) node x within organization. Then,Global Dynamic Slice(m) = Global Dynamic Slice(m) ∪ {x} ∪Global Dynamic Slice(x).

iv. Handle inter-service dependency: Let m be a use(m) node and (y,m)be the marked inter-service dependence edge associated with cor-responding def(m) node y across an organization. Then,Global Dynamic Slice(m) = Global Dynamic Slice(m) ∪ {y} ∪Global Dynamic Slice(y).

Phase 3: Computing and displaying the global dynamic slice

1. Global Dynamic Slice Computation:

(a) For every message variable m used at node m do the following:Let (d, m) be a marked data dependence edge corresponding to the mostrecent definition of the message variable, (c,m) be the marked controldependence edge, (x,m) be the marked intra-service dependence edge,and (y,m) be the marked inter-service dependence edge. Then,Global Dynamic Slice(s, m) = {d, c, x, y} ∪ Global Dynamic Slice(d) ∪Global Dynamic Slice(c)∪Global Dynamic Slice(x)∪Global Dynamic Slice(y)

(b) For message variable defined at node m, doGlobal Dynamic Slice(s, m) = Global Dynamic Slice(m) ∪ {m}.

2. Global Dynamic Slice Look Up

(a) If a slicing command (s,m) is given for a service-oriented software chore-ography SOSC, SEC and for particular message variable var, carry outthe followings:

118

i. Look up Global Dynamic Slice(s, m) for the content of the slice.

ii. Display the resulting slice.

(b) If the services of SOSC has not terminated, go to Step 2 of Phase 2.

5.4.2 Working of MBGDS Algorithm

We are interested in computing the global dynamic slice of service-oriented software chore-ography shown in Fig. 5.1 with respect to the slicing criterion (order no, (S8,M111), {sellername= XY, contact address= China, product name=AB, quantity=1000, price=12999, username= YZ, password= temp 123456}). The updated SOSDG after applying Phase 2 of ouralgorithm is shown in Fig. 5.6. All the marked edges are shown in bold lines and the mes-sage nodes included in the dynamic slice are shown as red colored vertices in Fig. 5.6. Wewill explain how our algorithm for computing global dynamic slices of service-oriented soft-ware works. For the input given in SEC, our MBGDS algorithm executes the message nodes{1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1, 8.1.1.2.1.1.1.1, 9 , 9.1, 4, 4.1, 9.2, 11}.

Now, (Global Dynamic Slice(S8,M111) = Global Dynamic Slice(9.2) ∪ {11}. On eval-uating the expression recursively, we obtain the global dynamic slices as follows:

Global Dynamic Slice(9.2) ∪ {11} = {1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1, 9, 9.1, 4, 4.1, 9.2, 11}

Global Dynamic Slice(9.2) = Global Dynamic Slice(9.1)∪Global Dynamic Slice(9.2)∪{9.2} = {1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1, 9, 4 , 4.1, 9.2}

Global Dynamic Slice(4.1) = {4, 4.1}∪Global Dynamic Slice(9.1) = {1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1, 9, 4, 4.1}

Global Dynamic Slice(9.1) = Global Dynamic Slice(4.1)∪Global Dynamic Slice(9)∪{9} = {1, 1.1, 8.1.1.2.1 , 8.1.1.2.1.1, 8.1.1.2.1.1.1, 9}

Global Dynamic Slice(9) = {8.1.1.2.1.1.1} ∪Global Dynamic Slice(8.1.1.2.1.1.1) ∪Global Dynamic Slice(9) = {1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1}

Global Dynamic Slice(8.1.1.2.1.1.1) = {8.1.1.2.1.1}∪Global Dynamic Slice(8.1.1.2.1.1.1)= {1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1}

119

Global Dynamic Slice(8.1.1.2.1.1) = Global Dynamic Slice(8.1.1.2.1)∪{8.1.1.2.1} ={1, 1.1 , 8.1.1.2.1}

Global Dynamic Slice(8.1.1.2.1) = Global Dynamic Slice(1.1)∪Global Dynamic Slice(8.1.1.2.1)∪{1.1} = {1, 1.1, 8.1.1.2.1}

Global Dynamic Slice(1) = Global Dynamic Slice{1.2}∪Global Dynamic Slice{1}∪{φ} ={ 1, 1.1}

Thus, theGlobal Dynamic Slice(S8,M111) consists of the message node set {1, 1.1, 8.1.1.2.1, 8.1.1.2.1.1, 8.1.1.2.1.1.1, 8.1.1.2.1.1.1.1, 9, 9.1, 4, 4.1, 9.2, 11}.

FIGURE 5.6: The updated SOSDG of the service choreography given in Fig. 5.1

120

5.4.3 Correctness of MBGDS Algorithm

In this section, we sketch the proof of correctness of our MBGDS algorithm.

Theorem 5.1 MBGDS algorithm always finds a correct global dynamic slice with respect

to a given slicing criterion.

Proof. The proof is given through mathematical induction. Let S be a service-orientedsoftware choreography (SOSC) for which a global dynamic slice is to be computed usingMBGDS algorithm. For any given set of input values to S, the global dynamic slice withrespect to the first executed message is certainly correct, according to the definition. Fromthis, we can argue that, the global dynamic slice with respect to the second executed messageis also correct. During execution of the service-oriented software choreography (SOSC) S,assume that the algorithm has computed correct global dynamic slices prior to the executionof a message m. To complete the proof, we need only to show that the global dynamic slicecomputed after execution of the message m is correct. Note that the messages that affect theexecution of the message m must have been executed prior to this execution of the messagem. It is obvious that the global dynamic slice Global Dynamic Slice(s,m) contains all thosemessages which have affected the current value of the message variables var used at m,since our MBGDS algorithm has marked all the incoming edges to m only from those nodeson which node m is dependent. The Steps 2(b), 2(c) and 2(d) of Phase 2 of the MBGDSalgorithm ensure that the node m is dependent (with respect to its present execution) on anode n if and only if the edge (m, n) is marked in the SOSDG of the service-oriented softwarechoreography (SOSC) S. If a node has no effect on the value of the message variablesvar, then it will not be included in the global dynamic slice Global Dynamic Slice(s,m).So, Global Dynamic Slice(s,m) is a correct global dynamic slice. In other words, we cansay that the global dynamic slices computed prior to this execution of the message m arecorrect. Therefore, the Steps 2(e(i)), 2(e(ii)), 2(e(iii)), 2(e(iv)) of Phase 2 and Steps 1(a) and1(b) of Phase 3 of the MBGDS algorithm ensure that the global dynamic slices computedafter execution of the message m are correct. Further Step 2(b) of Phase 3 of the MBGDSalgorithm guarantees that the algorithm stops when execution of the program P terminates.This establishes the correctness of the algorithm.

5.4.4 Salient Features of MBGDS Algorithm

The important features of the MBGDS algorithm are listed below.

• It computes correct global dynamic slices with respect to any valid slicing criterion.

121

• It can traverse inter-service dependency, intra-service dependency and extracts com-posite service like buying service in Section 5.1 using MBGDS.

• No trace files are generated. All information are maintained and updated dynamicallyfor all services and are discarded at run-time of a SOSC on termination of services.

• It does not create any additional message nodes during run-time. This saves the ex-pensive message node creation steps.

• When a request for a slice is made, it is easily available through slicer service.

• No serialization of the events of the services are required due to slicing based on thesequence diagram.

• It can be easily extended to accommodate dynamic slices of cloud-based programs.

5.4.5 Complexity Analysis of MBGDS Algorithm

In the following section, we analyze the time and space complexities of our MBGDS algo-rithm.

Time complexity:To determine the time complexity of our MBGDS algorithm, we have considered barom-

eter instructions which significantly contributes for the computation of the slice. The firstinstruction is related to the time required for running web services and updation of SOSDG.The second instruction corresponds to the time required to look up the data structure to re-trieve the slice. Let n be the total number of messages of the web services. Then, O(n2)time is required to compute and update SOSDG. Let m be the length of service choreographyexecution history (SCEH) involved in SOSC. Then, the run-time complexity of the MBGDSalgorithm would be O(n2m). The algorithm takes constant amount of time i.e., O(1) for slicelook up, which is negligible.

Space complexityLet a service-oriented software choreography (SOSC) have n messages. The space complex-ity for step 1 of Phase 1 would be O(n2)+O(n)+O(3). The required space for step 2 of Phase2 would be O(n2)+O(n3)+O(n2).

For n messages in SOSC, the space required to store global dynamic slice would be O(n3)and O(n2) space is required to store the recentDef. So, the space complexity of our MBGDSalgorithm would be O(n3).

122

5.5 Implementation and Experimental Results

In this section, we present a tool for SOSDG construction and discuss the experimentalresults obtained using our tool.

5.5.1 SOSDS: An SOS Dynamic Slicing Tool

In this section, we present a brief description of a tool which we have developed to imple-ment our global dynamic slicing algorithm for service-oriented software (SOS). We havenamed our tool Service-Oriented Software Dynamic Slicer (SOSDS). Our tool can computethe global dynamic slice of a service-oriented software with respect to any given slicing cri-terion. Currently, the SOSDS supports inter-service communication and intra-service com-munication using WSDL. In the following, we briefly discuss the design, implementation,and working of our slicing tool.

5.5.2 Design of SOSDS

The high-level design of our implementation SOSDS has been depicted in Fig. 5.7. TheSOSDS takes a SoaML sequence diagram comprising the parties and their interactions, inXMI format as input. This is parsed by the DOM parser module, which gathers informationregarding parties participating in interactions along with the messages exchanged betweenthem. The DOM parser reads the entire input XMI file and creates a tree structure in memory.When the DOM parser encounters XML tags in the XMI, it parses the tag to describe whattype of tags were encountered. The information obtained using the DOM parser module isthen used to initialize all the data structures needed to construct the static WSCFG as statedin Phase 1 of our MBGDS algorithm.

Further, SOAP messages are generated during run-time execution of services and itsclients serve as input to our SOSDS. These inputs help the interceptor module to inter-cept SOAP messages exchanged among services during run-time. The intercepted SOAPmessages provide information like time-stamp, request encoding, request preamble, requestlength, response encoding, response preamble, response length and more importantly, SOAPmessage body along with HTTP headers. This runtime information helps in initializing thedata structure needed to construct dynamic SOSDG as stated in Phase 2 of our MBGDSalgorithm.

The GUI module constructs WSCFG and SOSDG of the SoaML model in consultation

123

with DOM parser and Interceptor module. The slicer service modules takes the slicing cri-terion as input from the slicer service client and outputs the computed global dynamic slice.The GUI module updates the graph to reflect the computed global dynamic slices.

FIGURE 5.7: Schematic design of SOSDS

124

5.5.3 Implementation

We have implemented our MBGDS algorithm for web services written in Java. Our dynamicslicing tool is coded in Java and uses interceptor module of WS monitor [236]. When theweb service and their clients are made to run our slicing tool SOSDS, first the interceptormodule intercepts the SOAP messages and stores the data in a hashmap called message info.Meanwhile, the DOM parser module analyzes the XML tags and construct the WSCFGfrom a SoaML sequence diagram (XMI representation) given as input. Using the WSCFGand the message info, the SOSDG is constructed statically. While constructing the SOSDG,we store the data in a hashmap called service info. Each of this service info contains infor-mation: time-stamp, request encoding, request preamble, request length, response encoding,

response preamble, response length, SOAP message body, HTTP headers. For construct-ing the SOSDG, we have used the following flags: data flow flag, control flow flag, intra-

service flag, inter-service flag etc. For storing the SOSDG we have used the hashmap: Mapsosdg = new HashMap();. If there is an edge from message node i to j, then executesosdg.put("i","j", 1).

After constructing the SOSDG statically, we run the services along with their clients. Af-ter execution of each message, we invoke the update global dynamic slice() method, whichmarks and unmarks the edges of SOSDG appropriately and updates the global dynamicslice. When the global dynamic slice of a message node and service is requested our slicerSOSDS provides the global dynamic slice for the given slicing criterion and also visualizesthe SOSDG. The visualization of both the graphs, WSCFG, and SOSDG was carried out byusing JGrpahT library [108].

5.5.4 Data Sets Used in Our Experiments

As per our knowledge there does not exist any benchmark data sets to validate service-oriented sofware (SOS). Due to non-availability of such benchmark models, we use exampleavailable from the assignment submissions of the service-oriented computing course of mydepartment. The case study was implemented in a laboratory. A batch of 20 students takinga laboratory assignment in their service-oriented computing course at VGEC, Chandkhedawere considered. They were first asked to carry out analysis and design a SoaML sequencediagram for a system description given in exercises of Chapter 6 of the software engineeringbook [194]. They were instructed to implement each of the systems as a service-orientedsoftware system and to use JAX-WS API to create web services. Even, we gave flexibility tochoose systems based on their own choice from any real-world examples. Such real-worldSOA examples have been described in Appendix-A. The SoaML sequence diagrams were

125

constructed using visual paradigm [230], and were exported in corresponding XMI files. Forthe experiment, we selected important SoaML sequence diagrams (XMI representations),web services along with associated clients submitted by them. The maximum XMI file sizewas up to 15708 lines of tag (LOT) involving 11 services in service choreography withmaximum up to 2145 lines of code (LOC). However, currently, SOSDS can handle onlyintra-service and inter-service dependencies. We will extend it to handle the compositionand exception handling dependencies, in our future work.

5.5.5 Experimental Results

We have tested the working of MBGDS algorithm using the case study examples as stated in[194] with inter-service and intra-service dependencies using SOSDG.

The system configuration used to run MBGDS algorithm is windows 7 professional ser-vice pack 1, intel(R) core(TM) i3-3240 CPU@ 3.40GHz running at 3.40 GHz, with 4.00 GBRAM. We studied the run-time requirements of our MBGDS algorithm for these case studiesand for several runs. All measured times reported in this section are overall times, includingparsing and building of the both WSCFG and SOSDG representation. Table 5.1 summarizesthe average run-time requirements of MBGDS algorithm. As we are not aware of the ex-istence of any algorithm for dynamic slicing of service-oriented programs, so we have notpresented any comparative results. We have presented only the results obtained from our ex-periments. Since we computed the global dynamic slices at different messages of a services,we have calculated the average run-time requirements of the MBGDS algorithm.

From the experimental results, it can be observed that the average run-time increasessublinearly as the number of services increase in a service choreography as shown in Fig. 5.8.Average run-time is linear after 1K LOC, also in Fig. 5.8 average run-time is linear afternumber of services reach 6. This is because of the hash table data structure we used forimplementation, and the program characteristics. Fig. 5.8 shows good response time forsmall no. of services and LOCs but for large no. of services and LOCs average run-timeincreases significantly. In Table 5.1, as the LOC increases the run-time increases linearly.Similarly, when the service and XMI (LOT) increase, average run-time increases linearly.The performance results of our implementation agree with the theoretical analysis.

126

TABLE 5.1: Average run-time of MBGDS algorithm

Sl. No. Name of Case-Study XMI # Services #LOC Average

(#LOT) Run-Time

(inSec)

1 Travel Reservation System (TRS)[Appendix-A]

20701 20 3122 54.42

2 Online Shopping System (OSS)[Section 5.1]

15708 11 2145 37.45

3 Bookshop Automation Software(BAS)

9150 6 1189 21.06

4 Library Information System (LIS) 9240 6 1190 21.09

5 Restaurant Automation System(RAS)

5789 5 986 15.01

6 Student’s Auditorium ManagementSoftware (SAMS)

5333 5 988 15.00

7 Municipality Garbage CollectionAutomation Software (MGCAS)[Appendix-A]

5278 5 989 15.00

8 Hotel Automation Software (HAS) 5712 4 795 13.90

9 Road Repair and Tracking System(RRTS)

5812 4 810 14.10

10 Judiciary Information System (JIS) 5101 4 790 13.80

11 Supermarket Automation Software(SAS)

5119 4 789 13.75

12 Medicine Shop Automation Soft-ware (MSAS)

5219 4 794 13.89

13 Railway Reservation Software(RRS) [Appendix-A]

5318 4 809 14.09

14 Software Component CataloguingSoftware (SCCS)

5400 3 589 13.01

15 Motor Parts Shop Software (MPSS) 5139 3 580 12.95

16 House Rental Software (HRS)[Appendix-A]

2411 2 397 11.80

127

(a) Average run-time of MBGDS algorithmw.r.t no. of services

(b) Average run-time of MBGDS algorithmw.r.t no. of statements

FIGURE 5.8: Average run-time of MBGDS algorithm

5.6 Comparison With Related Work

To the best of our knowledge, no algorithm for dynamic slicing of service-oriented softwarehas been proposed so far. We, therefore, compare the performance of our algorithm with theexisting algorithms for static or dynamic slicing of object-oriented software.

Static slicing of software architecture has drawn the attention of many researchers [92,100, 101]. Also, dynamic slicing of software architecture and UML models has been ad-dressed by many researchers [99, 131]. Zhao [101] was the first one to introduce the conceptof architectural slicing based on architectural description language (ADL) ACME. He de-fined component-connector dependency, connector component dependency, and additionaldependencies. He proposed a two-phase algorithm to compute architectural slice based onsoftware architectural dependency graph (SADG). He extended his previous work [100] byintroducing architectural information flow graph with information flow arcs like component-connector, connector-component, and internal flow arcs based on Wright ADL.

Kim et al. [217] introduced dynamic software architecture slicing (DSAS), in whichslices represented the run-time behavior of those parts of the software architecture that wereselected according to the particular slicing criterion (e.g., a set of resources and their values)provided by the software architect. They defined a slicing criterion for (ADLs) such asACME, RAPIDE, Aesop, UniCon, and Wright.

All these approaches [92, 100, 101] slices were computed in forward or backward man-ner. These approaches did not consider the static and dynamic aspects of systems. A short-coming of these approaches is being addressed by Lallchandani [99, 131]. Lallchandani etal. [99, 131] have used generic class diagram and generic sequence diagram and integrated

128

them to generate model dependency graph (MDG). They proposed an algorithm architec-

tural model slicing through MDG traversal (AMSMT) to produce the static and dynamicarchitectural model slices. The algorithm traversed the edges of model dependency graph

(MDG) according to the slicing criterion. They developed a tool which computed a dynamicslice from UML architectural models.

Mohapatra [55] computed dynamic slices for object-oriented programs using Java lan-guage. They defined dynamic slice Dynamic Slice(u; var) with respect to the slicing criterion< s; var> for the most recent execution of the statement s, where var is the variable definedor used at the statement s. They proposed a dynamic slicing algorithm which computedcorrect dynamic slices.

A comparison with the related work is presented in Table 5.2. In Table 5.2, the com-parisons are presented based on slicing entities, slice types and slice output. There is nodirect related work available using quantitative evaluation parameter. The only quantitativeevaluation parameter we found is the average run-time for computing the slices.

TABLE 5.2: Comparison with related work

Sl. No. Related Work Model/ Slicing Slice Type Slice

LanguageUsed

Entities Output

1 Zhao [101] WrightADL

SoftwareArchitec-ture

Static SlicedCom-po-nents

2 Kim et al. [217] ACME andRAPIDEADL

SoftwareArchitec-ture

Dynamic SlicedCom-po-nents

3 Mohapatra [55] Object-OrientedProgram

JavaProrgam

Dynamic Slicedobjects

4 Lallchandani et al. [131] UML Class andSequencediagram

Dynamic Slicedobjects

5 Our MBGDS Algo. SoaML Servicesand Se-quencediagram

Dynamic Slicedmes-sages

129

However, our MBGDS algorithm for global dynamic slicing of service-oriented softwareincorporates several new things as compared to other work reported in the literature. Onenew thing is the computation of a global dynamic slice based on both the sequence diagramand web services. The computed slice is based on the dependencies existing among differentservices that are distributed across the various sites. Slicing based on both model and ser-vices can efficiently correlate different services during run-time, and help to understand howchanging any one of the services will impact the rest of the service choreography.

5.7 Conclusion

In this chapter, we have proposed a novel algorithm for computing global dynamic slices ofservice-oriented programs. We have named our algorithm marking based global dynamic

slicing (MBGDS). We considered SoaML sequence diagram and services in our work. Ouralgorithm used service-oriented software dependence graph (SOSDG) as the intermediaterepresentation. The MBGDS algorithm is based on marking and unmarking the edges of theSOSDG as and when the dependencies arise and cease at run-time.

The main advantage of our algorithm is that it does not use any trace file to store theexecution history. Also, it does not create additional message nodes during run-time. Thissaves the expensive file I/O and node creation steps. Another advantage of our approach isthat when a request for a slice is made, it is easily available through a mere table lookup. Wehave developed a slicer to verify the proposed algorithm.

The unavailability of web service code is a major challenge for testing, as web servicesare just provided as interfaces to the users and systems. This constraint makes black-boxtesting the only viable solution for testing web services. Therefore, in the next chapter, weare going to carry out black-box testing of web services.

130

CHAPTER - 6

Black-box Testing of Service-OrientedSoftware

One major flaw of white-box testing approach for web services is that web services are as-sumed to be transparent, which means that the tester has knowledge about internal structure,source code etc. which is unrealistic in some cases. Therefore, in this chapter we are going totest web services with no knowledge of internal details i.e black-box testing and with partialknowledge of internal details, called gray-box testing. This chapter is organized as follows.Section 6.1 describes the black-box testing of web service using program slicing artifacts.Section 6.2 illustrates two approaches for model-based testing one using BPMN and secondusing SoaML service interface diagram.

6.1 Black-box Testing of Web Services Through ProgramSlicing Artifacts

Web services and service-oriented computing (SOC) paradigm have received significant at-tention due to its widespread adoption and promotion by major IT vendors. As more andmore service-oriented softwares are built today, testing of web services has become the cru-cial point. Web services are distributed over various sites, maintain loosely coupled relation-ship among them, discoverable through UDDI, hide internal logic (abstraction), minimizeretaining information (statelessness) and adhere to service level agreement (SLA). These in-herent characteristics impose great challenges to the tester. In this section, we try to imposesa hierarchical structure on web service description language (WSDL) in order to uncovermore and more errors through program slicing artifacts like dependence graph. Our workcarries out black-box testing based on web service description language (WSDL) and its de-pendencies induced within. Our approach impose a hierarchical structure on WSDL, intro-

131

duces data and control dependencies, and introduces web service description graph (WSDG)as semantic element which will be used for testing.

The world wide web consortium (W3C) [238] defines web service as “a software sys-tem designed to support interoperability between machine-to-machine interaction over anetwork”. It has an interface described in a machine-processable format, WSDL. Othersystems interact with the web service in a manner prescribed by its description using SOAPmessages, typically transported using HTTP with an XML serialization in connection withother web-related standards [239]. Web services use standard protocols such as web servicedescription language (WSDL) to describe service descriptions, universal description discov-ery and integration (UDDI) to publish WSDL, and simple object access protocol (SOAP) toexchange messages among services.

Web services are loosely coupled, which means that each of its components has littleknowledge of all the other components. When there are any changes in client interface of theweb service, there is no need to change server interface of the web service. In simple words,changes in the interface of web service do not stop the client from interacting with webservice. Web services are coarse-grained, which imply that they consist of a small number oflarge components. Web services can have both synchronous and asynchronous connectionbetween client and service execution. The asynchronous operations, when invoked, do notblock the client while service is completing its operation. The client will receive the resultfrom asynchronous operations later than from synchronous operations. Web services havingasynchronous capabilities are necessary to have loosely coupled systems.

Web services were designed to support interoperability between different heterogeneousmachines. Web services communicate via SOAP messages [240], allow them to communi-cate with any application, written in any language or designed for any platform, which canunderstand SOAP. However, like all software, such an application should be tested beforeit is delivered to the user. Web service is described by a web service description language(WSDL) document [241]. WSDL was established as a standard by the world wide web con-sortium (W3C) [238]. The WSDL document describes web service in terms of its interfaceswith operations, types of data the web service takes or returns. WSDL does not provide adescription of the internal operation of web service. Nevertheless, such a WSDL documentcan be the basis for testing the web services.

A typical web service interaction includes interaction among three standardized softwarecomponents: service provider, service registry and service consumer as shown in Fig. 6.1.The service provider design WSDL document and publishes in a service registry (UDDI)through technical Model (tModel), which stores references for WSDL document. The ser-vice consumer looks up the service registry (UDDI) for a possible match against business

132

requirements, finds the service endpoint (URL), and finally calls the matched web service byexchanging SOAP messages.

Service Registry

Service Consumer Service Provider

3. Invoke services

� find... � � save... �

1. Publish serviceinterface descriptions

2. Discover businessrequirements

SOAP messageSOAP message

SOAP messageWSDL

UDDI

FIGURE 6.1: A web service interaction

The rest of the Section is organized as follows. Section 6.1.1 describes the structure ofWSDL document. Section 6.1.2 describes greatest common divisor (GCD) web service ex-ample. Section 6.1.3 describes the inherent dependencies of WSDL document. Section 6.1.4presents black-box testing of web services using extended WSDL. Section 6.1.5 presents ourproposed extension, WSDG. Section 6.1.6 describes the experimental results. Section 6.1.7compares our work with some related work.

6.1.1 Structure of WSDL

Testing based on WSDL requires us to understand the structure and semantic of WSDLdocument. In this section, we have discussed two recommended specification standardsWSDL 1.1 and WSDL 2.0 in detail.

The newest version of WSDL is 2.0 which is recommended by W3C, however, WSDL1.1 is still quite common and many software support this version. We have used WSDL1.1 for our work. Fig. 6.2 illustrates the major differences between both versions. Sections<messages> and <portType> were combined to create new section <interface>.

WSDL 2.0 is divided into several sections as below:

• description: is a container, inside of which the remaining sections are located.

• types: describes the data types used by a web service.

133

WSDL 1.1

Abstract description

Concrete description

portTypeoperation

message

bindingportservice

WSDL 2.0

Abstract description

Concrete description

interfaceoperation

message

bindingendpointservice

definition descriptiontypestypes

FIGURE 6.2: Comparison of WSDL 1.1 and WSDL 2.0

• interface: describes the abstract functionality the web service provides (what mes-sages it sends and receives, and possible fault messages).

• binding: provides information how to access the service, and

• service: provides information where to access the service.

There are two optional sections in WSDL document. They are as follows:

• documentation: provides human-readable description of a web service, and

• import: is used to import other XML schemas.

The detailed description of each section of WSDL 2.0 is given as below:

• description: The description tag contains all other tags and is used for declaringnamespaces. Element targetNamespace, contain link to WSDL document describingthe service.

• types: The types tag contains data types that the web service uses. Types, to be de-clared, have to be supported by web service API. Each operation can have its own inputtype (request), output type (response) and fault (error). The types defined in types can

134

be a simple type such as string or int. Complex type such as response can consist ofmany elements, which can be built-in data types.

• interface: The interface tag is a set of operations representing the interaction be-tween the user and the web service. Each of these operations specifies the sequenceof messages exchange that service sends or receives and the type of a given message.Operations are similar to methods or functions in programming languages.

WSDL defines four types of operations:

– One-way: operation can receive a message.

– Request-response: operation can receive a request and will return a response.

– Solicit-response: operation can send a request and will wait for a response, and

– Notification: operation can send a message.

• binding: The binding tag is responsible for access to the web service; it describes theprotocol, which may be used. This is a way to bind web service with the protocol. Ifthere is defined binding for given interface, then bindings for all operations from thatinterface must be defined.

• service: The service tag contains a set of endpoints at which service is provided. Theendpoints are places at which the service is provided.

Similarly, WSDL 1.1 is divided into the same sections as defined for WSDL 2.0 specifi-cation as given below:

• definition: is a container, similar to description of WSDL 2.0 specification. It servesas the root or parent element of every WSDL document. It also houses all other partsof the service definition and the location in which the many namespaces used withinWSDL documents are established.

• types: The data types can be mapped to and from the types of conventional program-ming languages and is similar to types of WSDL 2.0 specification.

• portType: It represent collections of operations, similar to interface of WSDL 2.0specification.

• port: It describes an endpoint where operation resides defined by the network addressand binding. It contains the location information of web services.

135

• binding: It associates a port type to a protocol and data format. It provides informationhow to access the service.

• service: It is collection of ports. It provides information where to access the service.

WSDL enables loose coupling among web services. It contains an abstract description(portType or interface, operation, and message) and concrete description (binding, port, andservice). However, this information is not sufficient to test web services, the tester alsorequires code to determine possible errors, which is not possible with published web services.Due to unavailability of such code, the tester may opt for black-box testing where testerobserves SOAP input and output messages available from WSDL descriptions. However, oneshould mention that even after satisfactorily carrying out testing it is impossible to guaranteethat the software is error-free [194].

6.1.2 A Web Service Example: Greatest Common Divisor (GCD)

FIGURE 6.3: Generated XSD of compute gcd web service

To understand our proposal, we need to understand how a web service is developed andconsumed. This section describes how to create a web service, its related artifacts XSD andWSDL.

Let there is a business requirement to create a web service which computes greatest com-mon divisor of two input values of type integer and returns an integer as the result. Tofulfill this requirement, first, we create an XML schema definition (XSD) file. We generatedthis XSD file using NetBeans IDE [168] plugged with SOA and XML plugins as shown inFig. 6.3.The XSD file defines two complex types compute gcd and compute gcdResponse.The compute gcd type has two elements arg0 and arg1 of xs:int type, and the element

136

compute gcdResponse has an element return of type xs:int, which are equivalent to inte-ger data type. After that, we have created two elements namely compute gcd and com-

pute gcdResponse of type tns:compute gcd and tns:compute gcdResponse respectively.

FIGURE 6.4: WSDL of compute gcd web service

Then afterward, we generated a WSDL file shown in Fig. 6.4 conforming to the schema

137

defined earlier as in Fig. 6.3. It includes the XSD file with attribute schemaLocation anddefine elements like PortType, Operation, Messages, Port, Binding and Service. These ele-ments represent service/object, method, argument(s), endpoint, transport protocol and a setof endpoints respectively. These elements have already been discussed in the previous Sec-tion too. The numbers assigned on the left side of each element will be used to describeinherent dependencies and have been discussed in next subsection.

Next, we create a web service named compute gcd as shown in Fig. 6.5. The @Web-

Service() annotation describes the class CGCD as web service. The WSDL file should bepublished in the service registry (UDDI) since NetBeans IDE does not support UDDI, theservice client must acquire it manually. Then the client communicates with web service byexchanging SOAP messages. First, we clean, build and deploy the web service successfully.Next we tested CGCD web service using NetBeans tester service by inputting 6 and 12

shown in Fig. 6.6. By clicking the button computeGcd, we actually invoke the web serviceusing SOAP request message containing the input parameters and gets the SOAP responseas 6 which is shown in Fig. 6.7. Such type of testing is called black-box testing where atester observes the input and output without knowing the internal code or structure.

FIGURE 6.5: compute gcd web service

In order to test a web service before its final deployment, the only thing available to testeris WSDL. Unfortunately, WSDL contains information which is insufficient to test. To test

138

a web service based on WSDL, a tester needs to know the structure of web service i.e itscontrol and data dependencies through which tester can check the service for possible errors.In next section, we propose our extention to WSDL document to get web service tested.

FIGURE 6.6: NetBeans tester service to invoke compute gcd web service

FIGURE 6.7: SOAP response for compute gcd web service

139

6.1.3 Inherent Dependencies of WSDL

The WSDL possesses inherent dependencies due to its various predefined semantic elements.These dependencies can be statically analyzed and can be represented as the graph in Fig.6.8. It shows that when a Service Consumer invokes the service through WSDL, the service

element is first invoked. The service element further invokes port and its attribute bind-

ing. The port element invokes portType, operation and message elements recursively. Andfinally, service gets executed on these ports along with associated operations with input/out-put messages.

These dependencies do not help much in testing as these dependencies are static andnever change during the whole lifetime of service unless the service gets maintenance orbecome obsolete.

1 2 3 4

5

6

7

8 9 10 11

FIGURE 6.8: Inherent Dependencies of WSDL

140

6.1.4 Black-box Testing of Web Service Using Extended WSDL

Our proposed approach for black-box testing of web services using extended WSDL canbe visualized as shown in Fig. 6.9. We present our proposed approach as an algorithmicpseudo-code as shown below in Algorithm 1:

Algorithm 1 Black-box Testing of Web Service Using Extended WSDL1. Create extended XSD file and import it in WSDL though schemaLocation attribute.2. Validate extended WSDL and XSD using NetBeans IDE.3. Create web service.4. Create web service client.5. Finally, run the web service client, generate test cases, run the test cases and check the

results.

FIGURE 6.9: Our proposed approach for black-box testing using extended WSDL

141

6.1.5 Extensible Element Web Service Description Graph <WSDG>:Our Proposed Extension to WSDL Using XSD

An XML schema (XSD) is used to provide the syntactic rules for XML data and documentsthat must be obeyed. The XSD documents describe the elements and their attributes just likethe type of content that the elements can have, detail the order in which elements can appearor provide a choice of elements for a given context. One can think XSD as the metadata forthe XML document. Similarly, DTD also provides the basic structure of XML documents(limited to elements and attributes). An XSD is a newer format and can do everything a DTDcan, along with additional restriction and facets. The other advantage of XSD schema overDTDs is that they are XML based, because of that they are easier to parse and display in ahierarchical manner. Because of these advantages, we prefer to use XSD over DTD for ourproposed extension of WSDL.

A web service may contain a number of classes, and these classes may, in turn, containa number of methods, more precisely web methods. These web methods may contain dataand/or control dependence statements. The control or data dependence statements may beof sequence, selection and iteration constructs [194]. This observation can be made as a setof rules which can be expressed using an XSD. We describe these rules by defining an ex-tensible element Web Service Description Graph <WSDG> which serves as root and otherslike classes, methods, data dependencies and control dependencies will become subchild ofit. We explicitly describe these constructs as semantic elements in our extensions. The ex-tended XSD schema is shown in Fig. 6.10. It should be noted that the XSD schema is a treecontaining a single root along with leaf and non-leaf nodes.

The schema code has been shown in Fig. 6.11. It defines the WSDG which is essentialfor testing services as global elements of complex type wsdg in modified XSD document.The wsdg contains element class of complex type Class and an attribute Version of typeinteger. The class encloses element method of complex type Method and attributes Cname,CVisibility of type string and visibility respectively. The method encloses two elements cdgand ddg of complex types CDG and DDG in sequence respectively. It also contains attributeslike Mname, Argument and Visibility of types string, argument and visibility respectively.The cdg covers three elements Seq, Selection, Iteration of complex types seq, selection anditeration in a sequence respectively. Similarly, the ddg covers three elements seq, selection,iteration of complex types seq, selection and iteration in a sequence respectively. The seq,selection and iteration covers element statement of type integer. In short, this XSD fileimposes hierarchical structure on WSDL through XSD and sets structural information fortesting.

142

FIGURE 6.10: Extended XSD design

143

FIGURE 6.11: Extended XSD for compute gcd web service

144

FIGURE 6.12: The XML file and result of valid test case execution on extended schema

6.1.6 Implementation and Experimental Results

In the followings, we discuss the black-box testing of extended XSD, black-box testing ofextended WSDL, black-box testing of our compute gcd web service, an important feature ofour proposed extention, WSDL data sets, and experimental results.

6.1.6.1 Black-box Testing of Extended XSD

We black-box tested our extended XSD using NetBeans IDE. To test our proposed exten-tion (Fig. 6.11), we have created an XML file shown in Fig. 6.12. The XML file usesxsi:noNamespaceSchemaLocation attribute to refer the location of extended schema. Forblack-box testing, we used equivalence class partitioning method. Since the input domainof our compute gcd web service is a range of values, we devise three test cases; one validand two invalids. The valid test case is <statement>1</statement> and invalid test casesare <statement><statement>,<statement>ABC</statement>. Next, we tested the schemausing NetBeans validation feature. The result of valid test execution is shown in Fig. 6.12and invalid test case execution result is shown in Fig. 6.13. Testing any representative valuefrom an equivalence class is similar to test for all the values from it. So, we black-box testedthe web services using representative test cases which demonstrate the applicability of ourproposed extension.

145

FIGURE 6.13: Result of invalid test case execution on extended schema

6.1.6.2 Black-box Testing of Extended WSDL

FIGURE 6.14: Extended WSDL schema design

Next, we tested the extended WSDL with NetBeans IDE. We used WSDL editor to designschema as shown in Fig. 6.14. We included extended XSD file in WSDL using schemaLo-

cation attribute to point to its location/URI as shown in Fig. 6.15. The rounded rectangleportion highlights our extension to WSDL through XSD. It defines root element WSDG andsub- child’s cdg etc. in the form of loops (Iteration), choices (Selection). Every serviceprovider must accommodate its XSD and WSDL as shown in Fig. 6.11 and in Fig. 6.15 ac-cordingly and provide the required structural information. The result of executing valid testcases on this WSDL is shown in Fig. 6.16. Now onwards this WSDL will serve as standardtemplate or contract and service provider must follow it to get its service to be testable.

146

FIGURE 6.15: Extended WSDL for compute gcd web service147

FIGURE 6.16: Result of valid test execution on extended WSDL

6.1.6.3 Black-box Testing of compute gcd Web Service

At last, we tested compute gcd web service by creating service consumer program as shownin Fig. 6.17. We found that the extention that we proposed are correct with respect to theextentions that we applied in XSD and corresponding WSDL files.

FIGURE 6.17: Result of invoking service consumer for compute gcd web service

148

6.1.6.4 Important Features of Our Proposed Extention

The important features of our extention are listed below.

• It extends WSDL using XSD without compromising interoperability among services.

• Even, it does not affect loose coupling relationship of web services.

• It can handle structural dependencies introduced via semantic elements .

• Test-cases can be executed merely based on extended WSDL.

• It can be published with service registry UDDI.

6.1.6.5 WSDL Data Set Used in Experiments

As per our knowledge there does not exist any standardized benchmark WSDL data sets tovalidate our proposal. Due to non-availability of such benchmark models, we use some webservice example deployed over the internet [242]. For the experiment, we selected someimportant WSDLs to test our proposed approach. The maximum WSDL file size was up to901 Lines of Tag (LOT). However, currently, we carry out black-box testing based on staticstructural dependencies introduced through extended WSDL. We will further extend it toincorporate dynamic dependencies which arise during run-time invocation of web services.

6.1.6.6 Experimental Results

We have tested the working of our proposed approach using sample WSDLs stated in [242]with structural dependencies incorporated in WSDL. The system configuration used to carryout testing is windows 7 Professional service pack 1, intel(R) core(TM) i3-3240 [email protected] running at 3.40 GHz, with 4.00 GB RAM. We studied the run-time requirementsof our approach for these WSDL data sets and corresponding web services for several runs.All the measured times reported in this section are overall times, including building anddeploying of extended WSDL. Table 6.1 summarizes the average run-time of web services.As we are not aware of the existence of any algorithm for WSDL-based testing, we havenot presented any comparative results. We have presented only the results obtained fromour experiments. Since, we black-box tested different WSDLs using their respective webservice client and web services, we have calculated the average run-time requirements ofcorresponding web services. The performance results of our implementation are correct andsatisfactory. From the experimental results, it can be observed that the average run-time

149

increases sublinearly as the lines of tag (LOT) increase in an extended WSDL as shown inFig.6.18.

FIGURE 6.18: Average run-time of web services w.r.t line of tag

6.1.7 Comparison With Related Work

We compare the performance of our approach with the existing approaches or techniques orframeworks for WSDL-based testing.

Tsai et al. [243] have proposed an XML-based object-oriented testing framework namedcoyote to test web services rapidly. The framework coyote consists of two parts: test masterand test engine. The test master allows testers to specify test scenarios and test cases as wellas various analyses such as dependency analysis, completeness and consistency and convertsWSDL specifications into test scenarios. The test engine interacted with the web servicesunder test and provides tracing information.

Bai et al. [250] have presented technique to generate web service test cases automat-ically based on the web services specification language web services description language(WSDL). The WSDL file is first parsed and transformed into the structured DOM tree. Then,test cases were generated from two perspectives: test data generation and test operation gen-

150

TABLE 6.1: Average run-time of web services

Sl. No. Web Service Name XMI Average

(#LOT) Run-Time

(in Sec)

1 country 901 7.0

2 uszip 434 6.0

3 BibleWebService 412 5.0

4 airport 411 5.0

5 PeriodicTable 403 5.0

6 currency 315 4.0

7 GlobalWeather 238 3.0

8 MedicareSupplier 226 3.0

9 length 183 2.0

10 whois 162 2.0

11 creditcard 155 2.0

13 braile 154 2.0

14 isbn 153 2.0

15 RSSReader 152 2.0

16 Search [Section 5.1] 60 2.0

17 ProductRegistration [Section 5.1] 59 2.0

18 Login [Section 5.1] 58 2.0

19 CGCD (our example) 55 2.0

151

eration. Test data were generated by analyzing the message data types according to standardXML schema syntax. Operation flows are generated based on the operation dependency anal-ysis. Three types of dependencies are defined: input dependency, output dependency, andinput/output dependency. Finally, the generated test cases are documented in XML-basedtest files called service test specification.

Tsai et al. [237] have proposed extension to WSDL by introducing dependencies likeinput-output dependency, invocation sequence, hierarchical functional description and con-

current sequence specifications. Bartolini et al. [33, 34] automated WSDL-based testing,which combined the coverage of web service operations with data-driven test case genera-tion. They defined a framework of a test environment that basically integrates two existingtools: soapUI [207], and TAXI [34]. The test suite generation is driven by basic coveragecriteria and some heuristics.

TABLE 6.2: Comparison with related work

Sl. No. Related Work Standard/ Technique/ Dependency Tool Output

/Approach/ FrameworkUsed

Used

1 Tsai et al. [243] object-oriented testingframework

- - Testcases

2 Bai et al. [250] WSDL input, out-put andinuput-output

- Servicetestcasespec-ifica-tion

3 Tsai et al. [237] extended WSDL input, out-put andinuput-output

- Testcases

4 Bartolini et al.[33]

WSDL and XSD - soapUI andTAXI

Testcases

5 Bartolini et al.[34]

WS-TAXI framework - WS-TAXI Testcases

6 Our approach extended WSDL control anddata

NetBeansIDE

SOAPre-sponse

152

A comparison between our work and some related work is presented in Table 6.2. Ourapproach for black-box testing of web services based on extended WSDL incorporates sev-eral new things as compared to other work reported in the literature. One new thing is thatour testing approach is based on both data and control dependencies which is being reportedin extended WSDL. Testing based on both these dependencies efficiently correlate differentelements of WSDL during run-time of services.

6.2 Model-based Testing of Service-Oriented Software

Nowadays, many organizations are looking forward to increase the adaptability of their sys-tems to react quickly to changes occurring in their environments. This requirement of sys-tem adaptability is best addressed by service-oriented architecture (SOA), as it facilitates theavailability of environmental services provided by the third parties. This feature of SOArapidly increases the adoption of SOA by different organizations. Hence, service-orientedarchitecture (SOA) is being used in design, development, deployment and management ofdifferent business services. These business services in SOA can also be used by other com-posite applications through publishing and binding interfaces. SOA integrates heterogeneousservices and enables them for effectively exchanging information among member enterprisesto process remote orders, inquiries, payroll, billing, HR and information delivery etc.

Due to the dynamic nature of SOA, its testing frequency is high. This results in an expen-sive process of test path construction and generation of test cases, each time an SOA-basedsoftware is tested. While testing SOA-based software, we have to generate test paths and testdata values for each of the services involved in the business workflow. The assignment oftest data values uses six different assertion types such as existing data value from the sameinterface, a constant value, a set of alternate values, a value range, a concatenated value and acomputed value [210]. To enhance the efficiency of testing, wrong/faulty data plays a greaterrole. The use of faulty data in testing SOA-based software increases the fault tolerance ofSOA-based software. In SOA, faulty data can be categorized into two sets with two differ-ent perspectives such as (i) to test the services in isolation and (ii) to test the service as acomponent in the system environment [264].

In this scenario, generation, and identification of test paths and test cases have becomechallenging factors as the raw code for web services and the associated test scripts are pro-prietary to the service providers and invisible to the tester. This situation can be avoided, ifwe generate test paths and test cases from the models describing SOA-based software.

153

6.2.1 Approach 1: Testing of Service-Oriented Software Using BPMNDiagram

In this section, we propose a model-based approach for testing SOA-based software usingBPMN diagram. The business process modeling notation (BPMN) is a graphical notationthat depicts the steps in a business process. It also depicts the end to end flow of a businessprocess. The notation has been specifically designed to coordinate the sequence of businessprocesses or services and the messages that flow between different processes or servicespresent in a related set of activities [178]. The main advantages of using a BPMN model fortesting of service-oriented software are as follows:

• It describes the services efficiently in order to analyze, and understand the SOA-basedsoftware.

• It also identifies which test paths need to be run to execute a particular business flow.

This BPMN model is usually designed and created in the early stage of software developmentlife cycle. However, test case data generation can be made parallel to software developmentin order to reduce time and effort. Thus, testers will have time to pay attention to test thesoftware before delivery.

A BPMN diagram contains four basic element categories (i) flow objects: these are theevents, activities and gateways (ii) connecting objects: these are the sequence flow, messageflow and association (iii) swim lanes: these are the pools and lanes (iv) artifacts: theseare the data objects, group and annotations. These four categories enable the creation ofsimple business process diagrams (BPDs). Even BPDs also permit making new types offlow objects or artifacts, to make the diagram more understandable. This specification alsoincludes semantic information related to SOA-based software. In this Section, we propose amethod to test SOA-based software using BPMN diagram.

BPMN diagram is widely used in business process modeling (BPM). BPM is the ac-tivity of representing the enterprise processes so that, the current process may be analyzedand improved. BPMN model consists of simple diagrams constructed from a limited set ofgraphical elements such as flow objects, connecting objects, swimlanes, and artifacts. WhileBPMN shows the flow of data (messages), and the association of data artifacts to activities,it is not a data flow diagram. The BPMN diagram can also be used to test service-orientedsoftware.

154

Our proposal for testing can be visualized as shown in Fig. 6.19. Below, we present ourproposed approach as an algorithmic pseudo-code.

1. Model the Process

Control Flow Graph

Test Cases

Test Paths3. Generate

4. Execute

2. Generate

FIGURE 6.19: Proposed testing approach

Algorithm 2 Testing of Service-Oriented Software Using BPMN Diagram (TSOSBD)1. Model the Process: design the BPMN diagram of the service-oriented software.2. Generate Control Flow Graph (CFG): assign version number to BPMN and unique

node number to each service or task of BPMN. Then, generate the control flow graphof the BPMN model.

3. Generate Test Paths: apply depth first search (DFS) method for generating the testpaths.

4. Execute Test Cases: apply test cases on generated test paths.

Let us follow the steps (represented by circles) one by one. The first step portrayedis model the process. This is an external task, in which a general task process, like travelreservation, shopping item etc. is being modeled using business process modeling notation(BPMN). Then, we export the BPMN file in .bpmn format. The XML DOM parser readsit and transforms it’s relevant data into a directed graph, this stage is called, as Generate

Control Flow Graph. Then, the test paths are generated from CFG using depth first dearch(DFS) method. Finally, the test cases are executed on the generated test paths.

6.2.1.1 Model the Process

The service call specific control flow, leads us to choose a graph-based modeling approachfor the business process. Each service or service call request in our model will be representedas an individual node. In the case of service-oriented software, where a service may call other

155

services can be represented as another node and an edge represents the control flow from oneservice node to another service node. This inherent nature of service-oriented software leadsus to choose a graph-based modeling approach to represent the business processes. This alsohas to do with the increased usage of business process modeling languages such as BPMN[178] and WS-BPEL [179].

Most companies have already modeled their business processes with any one of thesetwo languages, which makes easy the model generation, often reduces execution costs andeffectively communicates the business processes in a standard manner. A BPMN definesa business process diagram (BPD), based on a flowcharting technique tailored for creatinggraphical models of business processes. The web service business process execution lan-guage (WS-BPEL) [179], is an OASIS’s standard executable language for specifying actionswithin business processes with web services. A business process model does not necessarilyhave to be implemented as an automated business process in a process execution language.Even by design, there are some limitations on the process topologies that can be describedin WS-BPEL, so it is possible to represent processes in BPMN that cannot be mapped toWS-BPEL. Moreover, there are concepts, such as ad-hoc sub-proceses, that BPMN can rep-resent that may not be implemented with any technology [178]. Since there is a seriousadvantage of BPMN and as it supports convenient graph-based modeling, we decided to useBPMN with the help of Bizagi Modeler, a freeware tool [31]. The bizagi modeler is a model-ing tool much like Microsoft Visio Professional [155] or Sparxsystems Enterprise Architect12.1 [211], but more targeted towards the creation of BPMN models. It supports BPMNmodel exchange through export or import with .bpmn format.

6.2.1.2 A BPMN Example: Online Shopping System (OSS)

The online shopping system (OSS) described in Section 5.1 can be represented as a set ofbusiness services in a BPMN diagram as shown in Fig. 6.20. We have used Bizagi Mod-eler tool [31] to design OSS. It shows various service tasks such as product registration,courier company registration, login, sign up, third-party login, search product, add to cart,make payment and make courier. These service tasks are being provided by a pool or moreprecisely entities such as customer, payment gateway provider, online retailer, third-party lo-

gin provider, product seller, shipping and courier company. Other tasks are product registra-

tion request, courier company registration request, login request, sign up request, third-party

login request, search product request, make payment request and make courier request. Theinformation seen on the edges might represent one of the following two different things de-pending on it’s source. If it is a service or task, it represents it’s output data, on the otherhand if it is a gateway, it contains the condition that makes the control flow in that direction.

156

FIGURE 6.20: A BPMN diagram for “online shopping system (OSS)”

157

Once the business process modeling is completed, it is exported in .bpmn format as shownin Fig. 6.21.

FIGURE 6.21: Exporting BPMN with bizagi modeler

6.2.1.3 Generate Control Flow Graph (CFG)

First, we briefly describe our CFG generation algorithm. Then, we present the pseudo-codeof the algorithm. Subsequently, we discuss the complexity of our algorithm.

6.2.1.4 Overview of the CFG Generation Algorithm

Before execution of a business process, the CFG of a business process is constructed stati-cally. It describes the sequence in which different tasks or service tasks of a business processget executed. Stating, in other words, a control flow graph (CFG) describes how the controlflows through the business processes. Before presenting our proposed algorithm, few moredefinitions that would be used in our algorithm are introduced in this section.

Definition 6.1 Unique Node Number Assignment:A unique node number is an incremental assignment of numeric numbers to each task ofBPMN diagram.

Definition 6.2 BPMN Version (V):Version (V) of a BPMN diagram comes into picture if an evolution happens in the BPMNdiagram causing a change in the business flow of the system. This evolution may take ef-

158

fect due to the changes in the business service specification or the changes to the customerrequirements. Once the changes have been incorporated, then the corresponding task of theBPMN diagram are updated and the BPMN diagram is redrawn resulting in a new version(say V1 to V2). For simplification of the proposed approach, we assume that the BPMN hasinitial version V1.

In the algorithm, we first create two special nodes start and stop corresponding to nodesstartEvent and endEvent of BPMN model to define the start and end of business flow. Thenafter, we extract the root node process and it’s subchild nodes task or serviceTask and createnodes in CFG and assign them unique node numbers and attributes. We add a control flowedge if textnode value of outgoing element of subchild ni equals textnode value of incoming

element of subchild nj . We now present our CFG generation algorithm for our businessprocess in the form of pseudo-code as below:

Algorithm : Control Flow Graph (CFG) Generation Algorithm.

Input : A BPMN model // in .bpmn format

Output : Control Flow Graph

1. Node Construction

(a) Create two special nodes start and stop corresponding to nodes startEventand endEvent

(b) For each root node process do the followings

For each subchild node task or serviceTask node do the following

i. Create node ni

ii. Assign the node ni with unique node number.

2. Add control flow edges

(a) For each root node process, do the following

For each subchild node task or serviceTask node do the following

i. Add control flow edge from node (ni,nj), if textnode value ofoutgoing element of subchild ni equals textnode value of in-coming element of subchild nj.

159

start

stop

1

2

3

4

5

6

7

8

9

10

11

12

13 14

15

16

17

FIGURE 6.22: Control flow graph of “Online Shopping System (OSS)”

Fig. 6.22 shows the control flow graph of Fig. 6.20. The different numbered tasks serveas the nodes of the control flow graph. An edge from one node to another exists if the execu-tion of the task representing the first node can result in the transfer of control to another node.

160

6.2.1.5 Complexity Analysis of CFG Generation Algorithm

Time complexityTo compute the time complexity of our CFG generation algorithm, we consider each stepof the algorithm. Step 1(a) requires O(1) constant time. Step 1(b)i requires O(1) constanttime, Step 1(b)ii requires O(n2) time and finally the Step 2(a)i requires O(n2) time. Hencethe time complexity of our algorithm is O(n2), where n is the input size.Space complexityThe space complexity of our CFG generation algorithm would be O(n), since XML DOMparser maintains a hash table for CFG, and the space complexity of every reasonable hashtable is O(n), where n is the input size.

6.2.1.6 Implementation of CFG Generation Algorithm

As we said in the previous section, Bizagi Modeler exports a file with all the information weneed to create a control flow graph. The XML DOM parser extracts and stores the BPMNelements in a data structure in such a way that it facilitates control flow graph generation,graph searches, and further test case generation. A BPMN file fragment is shown in Fig.6.23. In order to search a service used in the BPMN diagram, the XML DOM parser traversesthe DOM tree to find serviceTask element node. While traversing the services or tasks it alsostores the attribute values of id, name and other elements such as incoming, outgoing, whichare the element nodes needed for generating CFG. Fig. 6.24 shows the internal data structuremaintained by XML DOM parser. The unique node number is assigned by the parser. Theparser compares each outgoing element with incoming element to determine the possiblecontrol flows among the services or tasks. To easily describe the control flow from outgoing

to incoming elements, we highlight the common ids with same color. The parser uses theseelements and builds the CFG.

FIGURE 6.23: A BPMN file fragment

161

FIGURE 6.24: Internal data structure of XML DOM parser

6.2.1.7 Generate Test Paths

Once we have generated the CFG, it is the time to generate test paths. Test paths can begenerated by applying depth first search (DFS) method or breadth first search (BFS) method.In DFS, the path is generated by starting with the root node and exploring as far as possiblealong each branch before backtracking. In BFS, the path is generated by exploring all thenodes at one level completely and then moving into the next level and so on. The limitationof BFS is that it can lead to generate an exponential number of test paths which will increasethe time complexity. The paths to be tested are coming out in exponential, out of which veryfew are useful,even there is a need of testing only basic paths. With this problem, and con-sidering the efficiency of DFS method to generate test path, we use DFS method to generatetest paths from BPMN diagram. By using this approach, the useless test paths are eliminatedwhich in turn reduces the time complexity. The generated test paths for the CFG given inFig. 6.22 using DFS are given below:

1. start→1→ 2→ stop.

2. start→3→ 4→ 13→15→ 16→ 17→ stop.

3. start→7→ 8→ 13→15→ 16→ 17→ stop.

4. start→9→ 10→ 13→15→ 16→ 17→ stop.

5. start→11→ 12→ 13→15→ 16→ 17→ stop.

162

6. start→5→ 6→ stop.

7. start→3→ 4→ 13→15→ 14→15→ 16→ 17→ stop.

8. start→7→ 8→ 13→15→ 14→15→ 16→ 17→ stop.

9. start→9→ 10→ 13→15→ 14→15→ 16→ 17→ stop.

10. start→11→ 12→ 13→15→ 14→15→ 16→ 17→ stop.

6.2.1.8 Execute Test Cases

The main goal of this step is to generate test case data, and execute the test cases for eachbusiness process based on the generated test paths.

We choose a path coverage-based test case generation strategy where test cases are de-signed such that all linearly independent paths in the business process are executed at leastonce. A linearly independent path is any path through the program that introduces at leastone new edge that is not included in any other linearly independent path [194].

Our goal is to provide semi-automatically input values which will exercise each linearlyindependent path previously created. To test a specific path, a number of service tasks ortasks need to be executed. In regular cases, most service tasks or tasks require some typeof input data. The only way to do it is by whitening up a bit for testing. In other terms, theservice providers will have to give a description of what are the possible inputs and outputsof a service tasks or tasks. Let the service provider declares inputs, data types and restrictionsfor each of the service or task as shown in Table 6.3. When we have sufficient information oftasks or service tasks, we can discover what inputs will fit, i.e, what input data will produceresults matching those restrictions and corresponding test paths.

Once we have such information as provided in Table 6.3 we can supply test cases in sucha way that each identified test path is covered. For example, we can exercise test path 1 bysupplying test case set {product name=mi3, quantity=1, price=12000, seller name=xiaomi,

contact address=china} as input, and observe the test case status as valid. This test pathcovers the unique node numbers 1 and 2 of CFG. Similarly, we can test all the test pathsby executing appropriate test cases and check the output. These test cases along with theirstatus are shown in Table 6.4.

163

TABLE 6.3: Inputs, data types and restrictions of service or task

Unique Element Data XSD XSD

Node Name Type Constraints Constraints

Number Value

1 & 2 product name xs:string minOccurs 1

1 & 2 quantity xs:int minOccurs 1

1 & 2 price xs:int minOccurs 1

1 & 2 seller name xs:string minOccurs 1

1 & 2 contact address xs:string minOccurs 1


3 & 4 pincode xs:int minOccurs 1

3 & 4 quantity xs:int minOccurs 1

5 & 6 shipping company name xs:string minOccurs 1

5 & 6 address xs:string minOccurs 1

5 & 6 charges xs:int minOccurs 1

7 & 8 username xs:string minOccurs 1

7 & 8 password xs:string minOccurs 1

9 & 10 mobile no xs:int minOccurs 1

11 & 12 tusername xs:string minOccurs 1

11 & 12 tpassword xs:string minOccurs 1

13 product name xs:string minOccurs 1

13 quantity xs:int minOccurs 1

13 customer name xs:string minOccurs 1

13 address xs:string minOccurs 1

13 contact no xs:int minOccurs 1

14 & 15 card type xs:string minOccurs 1

14 & 15 card no xs:int minOccurs 1

14 & 15 expiry date xs:date minOccurs 1

14 & 15 PIN xs:int minOccurs 1

14 & 15 OTP xs:int minOccurs 1

16 & 17 customer name xs:string minOccurs 1

16 & 17 address xs:string minOccurs 1


16 & 17 contact no xs:int minOccurs 1164

TABLE 6.4: Test cases with output for the example “online shopping system (OSS)”

Unique Element Data XSD XSD Input Test

Node Name Type Constraints Constraints Case

Number Value Status

1 & 2 productname

xs:string minOccurs 1 mi3 Valid

1 & 2 quantity xs:int minOccurs 1 mi3 Invalid

1 & 2 price xs:int minOccurs 1 12000 Valid

1 & 2 seller name xs:string minOccurs 1 1 Invalid

1 & 2 contact ad-dress

xs:string minOccurs 1 china Valid

3 & 4 productname

xs:string minOccurs 1 1 Invalid

3 & 4 pincode xs:int minOccurs 1 384001 Valid

3 & 4 quantity xs:int minOccurs 1 xiaomi Invalid

5 & 6 shippingcompanyname

xs:string minOccurs 1 DHL Valid

5 & 6 address xs:string minOccurs 1 1 Invalid

5 & 6 charges xs:int minOccurs 1 5000 Valid

7 & 8 username xs:string minOccurs 1 ABC Valid

7 & 8 password xs:string minOccurs 1 123 Valid

9 & 10 mobile no xs:int minOccurs 1 9725577940 Valid

11 & 12 tusername xs:string minOccurs 1 XYZ Valid

11 & 12 tpassword xs:string minOccurs 1 test123 Valid

13 productname


13 quantity xs:int minOccurs 1 1 Valid

13 customername

xs:string minOccurs 1 KKR Valid

13 address xs:string minOccurs 1 india Valid

13 contact no xs:int minOccurs 1 9726677988 Valid

14 & 15 card type xs:string minOccurs 1 CREDIT Valid

14 & 15 card no xs:int minOccurs 1 112233 Valid

14 & 15 expiry date xs:date minOccurs 1 2020-05-05 Valid

14 & 15 PIN xs:int minOccurs 1 112233 Valid

14 & 15 OTP xs:int minOccurs 1 1334 Valid

16 & 17 customername

xs:string minOccurs 1 KKR Valid

16 & 17 address xs:string minOccurs 1 india Valid

16 & 17 productname


16 & 17 contact no xs:int minOccurs 1 9726677988 Valid165

6.2.2 Approach 2: Testing of Service-Oriented Software Using SoaMLService Interface Diagram

This section also proposes an approach to test service-oriented software. Our proposed test-ing approach uses SoaML service interface diagram. To illustrate our proposed approach, weconsider the service-oriented software case study “online shopping system (OSS)” describedin Section 5.1. The detailed steps of our proposed testing approach is given below:

Algorithm 3 Testing of Service-Oriented Software Using SoaML Service Interface Diagram(TSOSSID)

1. Design SoaML service interface diagram for the given service-oriented software.2. Convert the SoaML service interface diagram into its equivalent XML schema.3. Generate XML instances of each service interface present in the XML schema.4. Apply various XML schema definition (XSD) constraints to the generated instances to

test the service-oriented software.

6.2.2.1 Design of SoaML service interface diagram and generation of XML Schema

The first step of our approach is to design the service interface diagram. For this purpose,we use the tool, Visual Paradigm [230]. The service interface diagram for “online shoppingsystem (OSS)”is shown in Fig. 6.25. Using the same tool, Visual Paradigm, we also performthe second step of our approach which generates the equivalent XML schema for the servicesdescribed in the service interface diagram as shown in Fig. 6.26.

FIGURE 6.25: SoaML service interface diagram for “online shopping system (OSS)”

166

FIGURE 6.26: XML schema or instant generation for “online shopping system (OSS)”

The generated XML schema for the SoaML service interface diagram is shown in Fig.6.27.

FIGURE 6.27: Generated XML schema for “online shopping system (OSS)”

167

6.2.2.2 Generating Instances in XML schema

After generating the equivalent XML schema from the service interface diagram, we gen-erate an instance for each service interface present in the XML schema. The XML schemahas mainly two service interfaces consumer and provider which are represented in the ser-vice interface diagram. To generate an instance of each of this interface we insert an XMLelement instance as of type online shopping service, which is a global type as shown in Fig.6.28 in red colour.

FIGURE 6.28: Instance generation in XML schema

This schema instance or subschema gives a simplified view of the attributes (data) and

168

operations of the service interfaces. It also enables the tester to test relations among the ser-vice interfaces by including the XML elements. For example, the XML schema of consumer

and provider under the parent element online shopping service gives information that thereis a relation between the consumer and provider interfaces.

The XML instance will now become a part of the WSDL document. When this sub-schema is passed through Altova XMLSpy [13], it generates a representative test case forXML instance as shown in Fig. 6.29.

FIGURE 6.29: A sample test case for XML schema instance

Fig. 6.29 shows the sample test cases in the required form. In Fig. 6.28, the XML ele-ment <xs:element name=”seller name” type=”xs:string” minOccurs=”0” maxOccurs=”1”>shows the type of data that is generated or required to be generated. When the code shownin Fig. 6.28 is passed through Altova XMLSpy, the final XML file is generated, which hasautomatically generated test cases as shown in Fig. 6.29. After generating the test cases forXML instances now we are able to build a test case data set. These test case data sets can beused in the generated XML instance of the service interface diagram to further generate testcases by applying XSD constraints.

169

6.2.2.3 Executing Test Cases by Applying XML Schema Constraints

In SOA-based software, the XSD can be used to express a set of rules to which a WSDL orXML document must confirm in order to be considered “valid” according to that schema.However, unlike most other schema languages, XSD was designed with the intent that de-termination of a document’s validity would produce a collection of information adhering tospecific data types [255].

The XML schema datatype may be simple datatype, complex datatype or built-in datatype.Simple datatype is defined with tag < xs : simpleType.. >. Complex datatype is definedwith tag < xs : complexType..>. Complex datatype includes sequence, choice or all sub-elements. The sequence sub-element displays in same order i.e child elements can onlyappear in the sequence of order that is already mentioned, here no randomization is allowed.In XSD all we can have all the child elements in the order we may like. These schema datatypes once defined along with XSD constraints, their values appear in the XML instances.We can find these links by considering Fig. 6.27 and Fig. 6.28 respectively. The choice sub-element indicates that there is only one sub-element to appear. If the sub-element appearsunder all category, then it may be presented in any order. However, the built-in datatype isdefined in the XML schema. We can use various XSD constraints in the XML instances tocustomize our test cases.

We can use various XSD constraints in the XML instances to customize our test cases.maxLength, minLength, maxExclusive, minInclusive, whitespace, and enumeration etc. aresome examples of XSD constraints. For example, maxLength is used to specify the maxi-mum number of characters for char. Similarly, minLength specifies the minimum number ofcharacters. The maxInclusive specifies the upper bound whereas minInclusive specifies thelower bound. whitespace can be used to handle spaces, tab and line feed. Enumeration con-straint defines the acceptable value list. We can customize our test cases by applying variousXSD constraints in XML instances. XML schema defines various built-in data types, such asxs:int, xs:float, xs:double, xs:decimal, xs:date, xs:time, xs:long, xs:short, etc. We can changethe identity of the data type to generate various test cases. For example, we can change thexs:string data type into xs:int to generate the minValue and maxValue of the XML schema.Here, we generate the test cases for the service interfaces consumer and provider. The XMLschema and the instance for OSS are shown in Fig. 6.27 and Fig. 6.28. By putting differenttest case data, we generate different test cases for our example online shopping system (OSS).Some of the valid and invalid test cases, which we have obtained for our case study OSS, areshown in Table 6.5. To demonstrate the working of our approach, test inputs like xiaomi, mi,12, 12345 etc. are quantitative evaluation parameters which are executed and test results arerecorded.

170

TABLE 6.5: Test case execution results for “online shopping system (OSS) ” using SoaMLservice interface diagram

Test Element Data Input XSD XSD Expected Actual

Case Name Type Constraints Constraints Test Case Test Case

ID Value Result Result

1 seller name xs:string xiaomi minOccurs 0 Invalid Invalid

2 seller name xs:string xiaomi minOccurs 1 Valid Valid

3 seller name xs:string 12 minOccurs 1 Invalid Invalid

4 product name xs:string mi minOccurs 0 Invalid Invalid

5 product name xs:string mi minOccurs 1 Valid Valid

6 product name xs:string 12345 minOccurs 1 Invalid Invalid

7 quantity xs:int 12345 minOccurs 0 Invalid Invalid

8 quantity xs:int 12345 minOccurs 1 Valid Valid

9 quantity xs:int ABC minOccurs 1 Invalid Invalid

10 contact address xs:string China minOccurs 0 Invalid Invalid

11 contact address xs:string China minOccurs 1 Valid Valid

12 contact address xs:string 123 minOccurs 1 Invalid Invalid

13 price xs:int 12000 minOccurs 0 Invalid Invalid

14 price xs:int 12000 minOccurs 1 Valid Valid

15 price xs:int XYZ minOccurs 1 Invalid Invalid

16 shipping company name xs:string DHL minOccurs 0 Invalid Invalid

17 shipping company name xs:string DHL minOccurs 1 Valid Valid

19 address xs:string DEF minOccurs 1 Valid Valid

20 tusername xs:string test minOccurs 1 Valid Valid

21 tpassword xs:string test123 minOccurs 1 Valid Valid

22 username xs:string test1 minOccurs 1 Valid Valid

23 password xs:string test123456 minOccurs 1 Valid Valid

24 pincode xs:int 4 minOccurs 1 Valid Valid

25 card type xs:string MAESTRO minOccurs 1 Valid Valid

26 card no xs:int 123456789 minOccurs 1 Valid Valid

27 expiry date xs:date 2016-05-24 minOccurs 1 Valid Valid

28 PIN xs:int 4554 minOccurs 1 Valid Valid

29 OTP xs:int 4664 minOccurs 1 Valid Valid171

6.2.3 Comparison With Related Work

In this section, we compare our work with the existing work based on models.

Nonchot et al. [46] have focused on test case generation using business process modelingnotation (BPMN), business process execution language (BPEL), and XSD schema (XSD),while our Approach 1 uses BPMN, and XSD constraints and Approach 2 uses SoaML ser-vice interface diagram which is a domain specific model for SOA interfaces, and uses XSDconstraints to generate test cases. They [46] merged BPMN diagram and BPEL diagram andshowed the manually generated control flow graph (CFG) while our Approach 1 producesautomatically the intermediate representation, a control flow graph (CFG) using our CFGgeneration algorithm and our Approach 2 automatically generates XSD instances using Vi-sual Paradigm [230]. Further, we demonstrated working of our Approach 1 using AltovaXMLSpy [13], which automatically generated sample test cases from XSD schema, whilethey [46] did not.

Kumar et al. [21] have presented an automatic test data generation algorithm for webservices through XML schema (XSD) and using TAXI [34]. They converted XML schema(XSD) into tree table of XML schema (XSD) to make it suitable for TAXI [34] to generatetest data, while in our Approach 1 we used BPMN, XSD constraints, CFG, and a tool AltovaXMLSpy [13] for test case execution. Further, the tool Altova XMLSpy [13] does not havesuch stringent requirement of input such as TAXI [34] has, it accepts XSD schema (XSD)and generates sample test cases. Even our Approach 2 does not require such transformationof inputs.

Hou et al. [213] have converted business process execution language (BPEL) processesto an intermediate representation, message sequence graph (MSG) to generate test cases,while our Approach 1 generates efficient intermediate representation, a control flow graph(CFG) of a BPMN model through our own algorithm. Our Approach 2 did not use suchintermediate forms and used SoaML service interface model. Further, they [213] carried outa BPEL testing, more concretely a white box testing, while our both approaches are modelbased.

Mao [44] have computed static slices of a business process execution language (BPEL)programs for understanding and debugging purpose. While our Approach 1 tests the businessprocess using BPMN model and Approach 2 did testing with the help of SoaML serviceinterface model and XSD constraints. They [44] proposed a new intermediate presentationcalled BPDG, by identifying data, control, and synchronized dependencies in a businessprocess execution language (BPEL) programs through static analysis, we generated a controlflow graph (CFG) in our Approach 1 through BPMN model analysis and an instance of

172

XSD through SoaML service interface model. They [44] have presented a static (backward/ forward) slicing algorithm which computes forward and backward slices for debuggingBPEL program, while we apply XSD constraint in both approaches to generate test cases.Similarly, Endo et al. [17] have proposed a new graph called as parallel control flow graph(PCFG) which represents multiple CFGs of service composition and interactions amongthese CFGs.

Yee [45] have presented a test case generation tool for business process execution lan-guage (BPEL) using XPath expression and Type definitions of WSDL document, while inour Approach 1, we have used BPMN model, CFG and XSD to execute test cases and inApproach 2, we have used SoaML service interface model, and XSD. Our both approachestest web services based on the model, while they developed a testing tool for service compo-sitions using business process execution language (BPEL) process.

Yuan et al. [258], have manually generated test cases from business process executionlanguage (BPEL) code by converting it into an intermediate form named as business flowgraph (BFG), while we used BPMN model and SoML service interface diagram in our Ap-proach 1 and Approach 2 respectively. Their approaches [258] used service composition i.eBPEL, while we unit tested web services based on models only.

Linzhang et al. [248] have used UML activity diagram to derive test scenarios and testingpaths while in our Approach 1, we used BPMN, control flow graph (CFG), path coverageand XSD to test all the scenarios and in Approach 2 we have used SoaML service interfacediagram, instance generation, and XSD constraints to test all the testing paths.

Gupta [124] has automatically generated test scenarios using UML activity diagram anddepth search (DFS) method, while we used BPMN and SoaML service interface diagramin our approaches. He [124] has generated intermediated forms such as activity flow graph(AFG) and activity dependency table (ADT) automatically for each activity diagram while inour Approach 1 we have developed an efficient intermediate representation which we namedas control flow graph (CFG) for web services.

Bhattacharjee et al. [82] have generated test cases based on UML activity diagram andtabu search algorithm to prioritize the test paths, while we developed our own algorithm forcontrol flow graph (CFG) generation in our Approach 1, which further facilitated the testingprocess. Kaur et al. [186] have used UML statechart diagrams, a testing tool TestOptimal,chinese postman and prefix-based algorithms to automatically and manually derive test pathsusing graph coverage techniques, while we have used BPMN model, XSD, Altova XMLSpy[13], and path coverage to test web services in our Approach 1 and SoaML service interfacemodel and Visual Paradigm [230] to test web services in our Approach 2. A comparison ofour work and some related work is presented in Table 6.6.

173

TABLE 6.6: Comparison with some related work

Sl.No.

Related Work Model/ Intermediate Testing Tool Degree of

Language Representation Based Support Automation

Used Used On

1 Nonchot et al.[46]

BPEL, BPMN - XSD - Fully

2 Kumar et al. [21] XSD XML Tree Ta-ble

XSD TAXI[34]

Fully

3 Hou et al. [213] BPEL MessageSequenceGraph

- - Manual

4 Mao [44] BPEL ExtendedControl FlowGraph

- - Fully

5 Endo et al. [17] BPEL Parallel Con-trol FlowGraph

- - Semi

6 Yee [45] BPEL - - WSDL Manual

7 Yuan et al. [258] BPEL Business FlowGraph

- - Manual

8 Linzhang et al.[248]

UML ActivityDiagram

- - UMLTGF Manual

9 Gupta et al. [124] UML ActivityDiagram

Activity CFG,Activity De-pendencyTable

PathCover-age

- Semi

10 Bhattacharjee etal. [82]

UML ActivityDiagram

- TabuSearchAlgo-rithm

- Manual

11 Kaur et al. [186] UML StatechartDiagram

- Node,Edge,Edgepair,PrimePathCover-age

TestOptimalFully

12 Our Approach 1 BPMN CFG XSD,PathCover-age

AltovaXMLSpy[13]

Semi

13 Our Approach 2 SoaML Ser-vice InterfaceDiagram

XML In-stances

XSD VisualParadigm[230]

Semi

174

6.2.4 Conclusion

In this chapter, we have successfully applied black-box testing strategy to test web services.The novelty of our approach is in imposing a hierarchical structure on WSDL, getting de-pendency information in the form of extensible elements. We have successfully tested ourapproach. Our testing approach of extension to WSDL can further be improved by gettingrun-time information to carry out white-box testing.

This chapter also illustrated the testing approaches for SOA-based software using BPMNand SoaML diagrams. First, we described our testing algorithm for service-oriented softwareusing BPMN diagram. In that we presented a CFG generation algorithm and its implemen-tation. Next, we tested the test paths of CFG by applying various test cases. Secondly, wepresented another algorithm for testing service-oriented software using SoaML service inter-face diagram. In that context, we generated XML schema and its instance. Finally, we testedthe XML schema instance.

175

CHAPTER - 7

Conclusions

The primary aim of our work was to test SOA-based software through program slicing tech-nique during design, testing and maintenance phases of software development lifecycle. Inthe following, we summarize the important achievements and contributions of our work.Finally, some suggestions for future work are given.

7.1 Achievements

Our work mainly focuses on proposing appropriate slicing techniques for testing SOA-basedsoftwares during design, testing and maintenance phases of software development lifecycle.

SOA Tester

IntermediateRepresentation

SoaMLModelSlicing

Extended

Static Model Slicing

using SSSIM

Dynamic Model Slicingusing MBGDS

NetBeans IDE 8.1

SOSSS

SOSDS

Prototype Tool

ExperimentalStudies

<<implements>>

<<implements>>

<<implements>>

Technique

Implementation

Black-box Testing

WSDL

CFGXSD

SchemaInstance

Model-based Testing

GenerationAlgorithm Generation

Altova XML Spy

FIGURE 7.1: Use case diagram for our achievements

176

A use case diagram for our achievements is shown in Fig. 7.1. The use case modelcomprises two subsystems viz., Technique and Implementation. The Technique subsystemconsists of our different static and dynamic slicing algorithms. In the use case model of Fig.7.1, the use cases have been labelled similar to the names given to each of our proposedalgorithms. On the other hand, the Implementation subsystem deals with the prototype im-plementation of the algorithms proposed in the former subsystem, and its use in carryingout our experimental studies on slicing and testing. The implementation of our proposedalgorithms involves development of two prototype tools namely, SOSSS for static slicingof service interface model and SOSDS for dynamic slicing of service choreography modelrespectively. It also consist open source tools like NetBeans and Altova XML Spy to demon-strate black-box and model-based testing approaches. Each of these use cases have beenassociated with one of our proposed algorithms in the corresponding Technique subsystemusing a stereotype <<implements>> . The use case model depicts an actor which is shownto be a SOA Tester. It shows that an SOA tester can take a SoaML model, SOA artifacts, andSOA technologies to compute slices using our algorithms and respective slicing criterion.

• Achievement of Objectives 1 and 2:At design phase, we developed a technique to compute static slices from SoaML ser-vice interface diagram. In this technique, we first converted a service interface modelinto an intermediate representation which we named SIDG (service interface depen-dency graph) using SoaML service interface diagram. This SIDG identifies service calldependency and composite dependency from SoaML service interface diagram. Giv-ing a slicing criterion as input, our SSSIM (static slicing of service interface model)algorithm traverses the SIDG and identifies the affected service interface nodes.

Further, we devised another technique to compute dynamic slices based on SoaML se-quence diagram. In our technique, we first mapped each message in sequence diagramwith corresponding web service input and output messages. This mapping is static.After that we constructed an intermediate representation of SoaML sequence diagramwhich we named SOSDG (service-oriented software dependence graph), which wasan intermediate representation needed to be stored and traversed to get dynamic slicesas and when web services get executed. This was followed by our slicing algorithmMBGDS (marking based global dynamic slice).The SOSDG identifies data, control,intra and inter service dependencies from SoaML sequence diagram and from web ser-vice execution. For a given slicing criterion, the MBGDS algorithm computes globaldynamic slice from SOSDG and identifies the affected services. The novelty of ourwork lies in computation of global dynamic slice based on SOSDG and its dependen-cies induced within and across organizations and small slices comprising less numberof messages.

177

• Achievement of Objectives 3 and 4:At testing phase, we have developed a new black box testing strategy. In this contextwe applied program slicing artifacts for testing of service-oriented software based onWSDL document. In this strategy, we imposed hierarchical structure on WSDL (webservice description language). The structuring of WSDL is carried out by introduc-ing WSDG (web service dependence graph) and both data and control dependenciesin XSD (XML schema definition). This WSDG identifies both data and control de-pendencies in WSDL. By giving test cases as input to this extended XSD using opensource testing tool, a tester will be able to carry out black-box testing.

We have successfully carried out testing of SOA-based software using BPMN andSoaML service interface diagrams. These techniques defines CFG generation, testpaths generation, XSD schema generation, XSD schema instance generation, and testcases execution respectively for each models.

We have also developed prototype tools to implement our proposed algorithms andperformed experimental studies aligning with Objectives 5 and 6.

7.2 Contributions

In this section, we summarize the important contributions of our work. There are threeimportant contributions, Static Slicing of Service-Oriented Software, Dynamic Slicing of

Service-Oriented Software, and Black-box Testing of Service-Oriented Software.

7.2.1 Static Slicing of Service-Oriented Software

We first developed an intermediate representation for representing simple service-orientedsoftware with higher level abstraction. We have named this intermediate representation Ser-

vice Interface Dependence Graph (SIDG). We statically constructed the SIDG. Then, we pre-sented static slicing of service interface model (SSSIM) algorithm to compute static slices.Such slice can be used for change impact analysis, testing and understanding distributedarchitectures such as SOA. We have shown that the space complexity of our algorithms isO(n2), where n is the number of service interface nodes. The time complexity of SSSIMalgorithm is O(n). Further, we have proved that our algorithm computes correct static slicesfor any given slicing criterion. We have implemented our algorithm to demonstrate it’s cor-

rectness experimentally. We have named our slicing tool SOS static slicing (SOSSS).

178

7.2.2 Dynamic Slicing of Service-Oriented Software

Due to the presence of inter-service and intra-service communications, some control anddata flows occurring among the web services, are interdependent. To be able to capturethis aspect, we extend our intermediate representation, SIDG to represent the inter-serviceand intra-service communications. We have named this modified intermediate representa-tion service-oriented software dependence graph (SOSDG). Having introduced SOSDG asan intermediate representation for service-oriented software, we presented a dynamic slic-ing algorithm for service-oriented software. We named this algorithm marking based global

dynamic slicing (MBGDS) algorithm for service-oriented software. The MBGDS algorithmuses SOSDG as the intermediate representation and is based on marking and unmarkingthe edges of the SOSDG as and when the dependencies arise and cease during run-time. Wehave shown that the space complexity of MBGDS algorithm isO(n3), where n is the numberof statements in the program, and the time complexity is O(n2m), where m is the length ofservice choreography execution history (SCEH) involved in service-oriented software chore-ography (SOSC). We have shown that MBGDS algorithm computes correct dynamic sliceswith respect to any given slicing criterion. We have developed a slicing tool to verify thecorrectness and preciseness of our MBGDS algorithm. We have named our slicing tool SOS

dynamic slicing (SOSDS). The results obtained from this tool are in line with the presentedtheoretical analysis results.

An important advantage of our algorithm is that it does not use trace files. Also, it doesnot create any additional message nodes at run-time. This saves the expensive file I/Ooperations and message node creation steps. Another advantage of our algorithms is thatwhenever a request for a slice is made, it is already available in the corresponding datastructure. This results in substantial reduction in the response time for slice extraction.

7.2.3 Black-box Testing of Service-Oriented Software

We have successfully applied black-box testing strategy to test web services. Our approachimposed a hierarchical structure on WSDL through web service dependence graph (WSDG)to get dependency information in the form of extensible elements. We have successfullytested our approach using open source tool Netbeans IDE. Our results obtained from thistool Netbeans IDE are in line with the presented technique or approach.

Also, we successfully tested SOA-based software using BPMN and SoaML models.First, we have presented our testing algorithm for service-oriented software using BPMNdiagram, in which we presented a CFG generation algorithm and its implementation. Next,

179

we tested the test paths of CFG by applying various test cases. We have executed the testcases using open source tool Altova XML Spy. Secondly, we presented another algorithm fortesting service-oriented software using SoaML service interface diagram. In that, we gen-erated XML schema and its instance using Visual Paradigm Professional Edition software.Finally, we tested XML schema instance on Altova XML Spy. Results obtained for thesetechniques prove that both these techniques are complementary to each other.

7.2.4 Implementation

We have implemented our proposed algorithms and techniques to experimentally verify theircorrectness. We have tested each slicing tool on a large number of SOA-based software withseveral executions and slicing criteria. We have observed that our slicers/slicing tools com-puted correct static or dynamic slices for all input slicing criteria. This experimentally vali-dated the correctness of our proposed algorithms or techniques. We have also implementedour testing algorithms with a number of SOA-based software. We have generated some testcases for different SOA-based software. Finally, we have executed the test cases with theSOA-based software to know whether they are working perfectly or not.

7.3 Future Work

Below, we briefly outline the following possible extensions to our work.

• While computing static slices of service-oriented software (SOS), we have not con-sidered other SoaML static diagrams like service participant diagram, service contractdiagram etc. Our work can be extended by merging theses static diagrams, and creat-ing a unified intermediate representation suitable for slicing.

• While computing dynamic slices, we considered service-oriented software (SOS). Ourwork can be extended to slice cloud-based software.

• Our intermediate representation SOSDG can be extended to handle composition andexception handling dependencies.

• The WSDG extension proposed for WSDL can be incorporated in UDDI registry.

• The test case generation process using BPMN and SoaML service interface diagram ismanual to some extent, which can be fully automated.

180

• The slicers can be used to develop efficient debuggers and test drivers for large-scalecloud-based software.

• The proposed algorithms can be used for the development of cloud-based softwaremetrics, and test case generation for cloud-based software etc.

181

Publication List

Slicing of Service-Oriented Software [Chapter # 3, 4, 5]

1. Kirit Modi, Harshad Modi, and Kaushik Rana, “Web Service Discovery: Con-cepts, Approaches, Challenges”, In National Conference on Distributed Comput-

ing (NCDC09), Osmanabad, India, 2009.

2. Kaushik Rana, Kiran Amin, “Dynamic Slicing of Remote Procedure Call (RPC)Program for Debugging Purpose”, In Recent Trends in Software Testing Workshop

(RTST09), NIT Rourkela, India, 2009.

3. Kaushik Rana, Harshal Shah, and Durga Prasad Mohapatra, “A Novel Tech-nique For Static Slicing of SoaML Service Interface Diagram”, In 2014 Annual

IEEE India Conference (INDICON), Pune, India, 2014.

Testing of Service-Oriented Software [Chapter # 6]

4. Harkishan Rathod, Kaushik Rana, “Testing Web Services by Applying Pro-gram Slicing”, In International Journal of Advance Research in Computer Science

and Management Studies, ISSN (PRINT):2321-7782(online), Volume 2, Issue 1, Jan-uary 2014.

5. Kaushik Rana, “Black-box Testing of Web Service”, In International Journal of

Computer Science & Informatics (IJCSI), Volume 3, No. 2, 2013.

182

List of References

[1] A.V. K. Shanthi and G. Mohan Kumar, “Automated Test Cases Generation From UMLSequence Diagram”, In International Conference on Software and Computer Appli-

cations (ICSCA 2012), Volume 41, 2012.

[2] Antonia Bertolino and Andrea Polini, “SOA Test Governance: Enabling Service Inte-gration Testing Across Organization and Technology Borders”, In IEEE International

Conference on Software Testing Verification and Validation Workshop, 2009.

[3] Ashalatha Nayak and Debasis Samanta, “Automatic Test Data Synthesis Using UMLSequence Diagrams ”, Journal of Object Technology, Volume 9, No. 2, March-April2010.

[4] Ashish Seth, Himanshu Agrawal, and Shim Raj Singla, “Testing and Evaluationof Service Oriented Systems, [online]. Available: www.arxiv.org, [accessed on18/03/2014].

[5] Anca Daniela Ionita, Mariana Mocanu, and Sorin N. Ciolofan, “Modelling withSoaML Applied for Warning and Water Management Services”, In Nineteenth In-

ternational Conference on Control Systems and Computer Science, 2013.

[6] Apache JMeter Tool, [online]. Available: http://jmeter.apache.org/, [accessed on18/03/2014].

[7] Anca Daniela Ionita, Mariana Mocanu, and Sorin N. Ciolofan, “Modelling withSoaML Applied for Warning and Water Management Services”, In Nineteenth In-

ternational Conference on Control Systems and Computer Science, Pages 624-627,2013.

[8] Abdelaziz El Fazziki, Hamza Lakhirissi, Kokou Yetognon, and Mohamed Sadgal, “AService Oriented Information System: A Model Driven Approach”, In Eighth IEEE

International Conference on Signal Image Technology and Internet Based System,2012.

183

[9] Aho, A. V., Sethi, R., and Ullman, J. D, “Compilers: Principles, Techniques andTools”, Addison-Wesley, 1986.

[10] Aart J. C. Bik and Dennis Gannon, “Automatically Exploiting Implicit Parallelismin Java”, Concurrency - Practice and Experience, Volume 9, No. 6, Pages 579-619,1997.

[11] Aditya Rajeev Kulkarni and S. Ramesh, “Static Slicing of Reactive Programs”, In

Third IEEE International Workshop on Source Code Analysis and Manipulation

(SCAM 2003), Amsterdam, The Netherlands, Pages 98-107, 2003.

[12] Arsanjani Ali, “Service-oriented Modeling and Architecture”, [online]. Avail-able: http://www.ibm.com/developerworks/library/ws-soa-design1/ , [accessed on18/03/2014].

[13] Altova XMLSpy, [online]. Available: http://www.altova.com/xmlspy , [accessed on18/03/2014].

[14] Agrawal, H., Horgan, J. R., Krauser, E. W.,and London, S., “Incremental RegressionTesting”, In ICSM (1993), Volume 93, Pages 348-357, 1993.

[15] A. Bertolino, J. Gao, E. Marchetti, and A. Polini, “Automatic test data generationfor XML Schema Based Partition Testing”, In Proceedings of Second International

Workshop on Automation of Software Test, Pages 4-4, May 2007.

[16] A. Sinha and A. Paradkar, “Model-based Functional Conformance Testing of WebServices Operating on Persistent Data”, In Proceedings of Workshop on Testing, Anal-

ysis, and Verification of Web Services and Applications, Pages 17-22, 2006.

[17] A. T. Endo, A. S. Simo, S. R. S. Souza, and P. S. L. Souza, “Web Services CompositionTesting: A Strategy Based on Structural Testing of Parallel Programs”, In Proceedings

of Testing: Academic & Industrial Conference - Practice and Research Techniques,Pages 3-12, Aug. 2008.

[18] Ashu Mishra, “Generation and Prioritization of Test Sequences Using UML Activ-ity Diagram”, Bachelor Thesis, Department of Computer Science and Engineering,National Institute of Technology, Rourkela, May 2014.

[19] A. Paradkar, A. Sinha, C. Williams, R. Johnson, S. Outterson, C. Shriver, and C.Liang, “Automated Functional Conformance Test Generation for Semantic Web Ser-vices”, In Proceedings of IEEE International Conference on Web Services, Pages 110-117, July 2007.

[20] Abhishek Kumar, “A Novel Testing Model for SOA Based Services”, I.J. Modern

Education and Computer Science, Pages 31-37, 2015.

184

[21] Abhishek Kumar, Akhilesh Kumar Pandey, and Farahnaz Rezaeian Zade , “AutomaticTest Data Generation of Web Services through XML Schema ”, Asian Journal of

Convergence in Technology, Volume 2, No. 2, 2015.

[22] Agrawal, H., and Horgan, J., “Dynamic Program Slicing”, In Proceedings of ACM

Conference on Programmimg Lanuages Design and Implementation, Volume 25,Pages 246-256, 1990.

[23] Agrawal, H., DeMillo, R. A., and Spafford, E. H, “Dynamic Slicing in the Presenceof Unconstrained Pointers”, In Proceedings of ACM Symposium on Testing, Analysis

and Verification, Pages 60-73, 1991.

[24] Bart van Teeseling, “Testing Service-oriented Architecture using a simulation”, Mas-

ter Thesis, University of Groningen, 2010.

[25] Bogdan Korel, Inderdeep Singh, Luay Tahat, and Boris Vaysburg, “Slicing of StateBased Models”, In Proceedings of International Conference of Software Maintenance,Pages 34-43, 2003.

[26] Ball, T, “The Use of Control Flow and Control Dependence in Software Tools”,Ph.D.

Thesis, Computer Science Department, University of Wisconsin-Madison, 1993.

[27] Bieman, J. M., and Ott, L. M. “Measuring Functional Cohesion”, IEEE Transactions

on Software Engineering , Pages 644-657, 1994.

[28] Beck, J., and Eichman, D., “Program and Interface Slicing for Reverse Engineering”,In Proceedings of IEEE/ACM Fifteenth International Conference on Software Engi-

neering, Pages 509-518, 1993.

[29] Bogdan Korel and J. Laski, “Dynamic Program Slicing”, Information Processing Let-

ters, Pages 155-163, 1988.

[30] Bieberstein Norbert, Jones Keith, Laird Robert G., and Mitra Tilak, “Ex-ecuting SOA: A Methodology for Service Modeling and Design”, [online].Available: http://www.informit.com/articles/article.aspx?p=1194198 , [accessed on18/03/2014].

[31] Bizagi Modeler Tool, [online]. Available: http://www.bizagi.com , [accessed on18/03/2014].

[32] Cesere Bartolini, Antonia Bertolini, Sebastian Elbaum, and Eda Marchetti, “Whiten-ing SOA Testing”, In Proceedings of ESEC/FSE, Pages 161-170, 2009.

185

[33] Cesare Bartolini, Antonia Bertolino, Eda Marchetti, and Andrea Polini, “Towards Au-tomated WSDL-Based Testing of Web Services”, In Sixth International Conference

on Service Oriented Computing, December 1-5, 2008, University of Technology, Syd-

ney, Ultimo City Campus, LNCS 5364, Springer-Verlag Berlin Heidelberg 2008, Pages524-529, 2008.

[34] Cesare Bartolini, Antonia Bertolino, Eda Marchetti, and Andrea Polini, “WS-TAXI: aWSDL-based testing tool for Web Services”, In International Conference on Software

Testing Verification and Validation, Pages 326-335, 2009.

[35] Charles Abrams and Roy W.Shulte, “Service-Oriented Architec-ture Overview and Guide to SOA Research”, [online]. Available:http://www.download.microsft.com/documents/australia/soa/gartner.pdf, [accessedon 18/03/2014].

[36] Chen, Z., Xu, B., and Yang, H. “Test Coverage Analysis Based on Program Slicing”,In Proceedings of IRI, Pages 559-565, 2003.

[37] Chen, Z., Zhou, Y., Xu, B., Zhao, J., and Yang, H., “A Novel Approach for Measur-ing Class Cohesion Based on Dependence Analysis”, In Proceedings of International

Conference on Software Maintenance, IEEE Press, Pages 377-384, 2002.

[38] Canfora, G., Cimitile, A., and De Lucia, A., “Conditioned Program Slicing”, Infor-

mation and Software Technology Special Issue on Program Slicing, Volume 40, Pages595-607, 1998.

[39] Chauhan, N., Software Testing Principles and Practices, Oxford University Press,New Delhi, India, Chapter 8, Pages 255-273, 2010.

[40] C. Ma, C. Du, T. Zhang, F. Hu, and X. Cai, “WSDL-based automated test data gen-eration for web service”, In Proceedings of International Conference on Computer

Science and Software Engineering, Pages 731-737, Dec. 2008.

[41] C. Lenz, J. Chimiak-Opoka, and R. Breu, “Model Driven Testing of SOAbased Soft-ware”, In Proceedings of Workshop on Software Engineering Methods for Service-

oriented Architecture, Pages 99-110, May 2007.

[42] C. Smythe, “Initial Investigations Into Interoperability Testing of Web Services FromTheir Specification Using the Unified Modeling Language”, In Proceedings of Inter-

national Workshop on Web Services Modeling and Testing, Pages 95-119, June 2006.

[43] Chun Ouyang, Eric Verbeek, Wil M.P. van der Aalst, Stephan Breutel, Marlon Dumas,and Arthur H.M. ter Hofstede, “WofBPEL: A Tool for Automated Analysis of BPEL

186

Processes”, In Service-Oriented Computing (ICSOC), Lecture Notes in Computer Sci-

ence, Volume 3826, Pages 484-489, 2005.

[44] Chengying Mao, “Slicing Web Service-based Software”, In IEEE International Con-

ference on Service-Oriented Computing and Applications (SOCA), Pages 1-8, Jan.2009.

[45] Choy Kho Yee, “Design and Implementation of Test Case Generation Tool for BPELUnit Testing”, Master Thesis, Department of Computer Science, Software Engineer-ing Laboratory, Osaka University Graduate School of Information Science and Tech-nology, February 2008.

[46] Chaithep Nonchot and Taratip Suwannasart, “A Tool for Generating Test Case fromBPMN Diagram with a BPEL Diagram”, In Proceedings of International Multicon-

ference of Engineers and Computer Scientists, Volume 1, March 2016.

[47] C. Ma, J. Wu, T. Zhang, Y. Zhang, and X. Cai, “Testing BPEL with Stream X-Machine”, In Proceedings of International Symposium on Information Science and

Engineering, Pages 578-582, Dec. 2008.

[48] C. Ouyang, E. Verbeek, W. M. P. van der Aalst, S. Breutel, M. Dumas, and A. H.M. ter Hofstede, “Formal Semantics and Analysis of Control Flow in WS-BPEL”,Science Computer Programing, Volume 67, No. 2-3, Pages 162-198, 2007.

[49] Cesare Bartolini, Antonia Bertolino, and Eda Marchetti, “Introducing Service-oriented Coverage Testing”, In IEEE/ACM International Conference on Automated

Software Engineering - Workshops, Pages 57-64, 2008.

[50] David S. Linthicum and David Bressler, “Key Strategies for SOA Testing”, Progresssoftware, [online]. Available: www.progress.com, [accessed on 18/03/2014].

[51] Debashree Patnaik, Arup Abhinna Acharya, and Durga Prasad Mohapatra, “Genera-tion of Test Cases Using UML Sequence Diagram in a System With CommunicationDeadlock”, International Journal of Computer Science and Information Technologies,Volume 2(3) , 2011.

[52] Debasish Kundu and Debasis Samanta, “A Novel Approach to Generate Test CasesFrom UML Activity Diagrams”, Journal of Object Technology, Volume 8, No. 3,May-June 2009.

[53] Deepak Kumar Meena, “Test Case Generation From UML Interaction Overview Dia-gram and Sequence Diagram”, Master Thesis, Department of Computer Science andEngineering, National Institute of Technology Rourkela, June 2013.

187

[54] Department of Homeland Security, “National valunerabilty database”, [online]. Avail-able: http://www.nvd.nist.gov/, [accessed on 18/03/2014].

[55] Durga Prasad Mohapatra, “Dynamic Slicing of Object-Oriented Programs”, [Ph.D.Thesis], IIT Kharagpur, May 2005.

[56] David Binkley and K. B. Gallagher, [online]. Available: http://www.cs.loyola.edu/

kbg/survey.ps, Academic Press, Volume 43, 1996, [accessed on 18/03/2014].

[57] David Binkley, and Gallagher, K. B., “Program Slicing”, Advances in Computers,Academic Press, San Diego, CA, Volume 43, 1996.

[58] David Binkley, “Using Semantic Differencing to Reduce the Cost of Regression Test-ing”, In Proceedings of IEEE Conference on Software Maintenance, Pages 41-50,1992.

[59] David Binkley, “The Application of Program Slicing to Regression Testing”, Infor-

mation and Software Technology, Special Issue on Program Slicing, Pages 583-594,1998.

[60] David Binkley, Horwitz, S., and Reps, T.,“Program Integration for Languages WithProcedure Calls”, In ACM Transactions on Software Engineering and Methodology,Pages 3-31, 1995.

[61] D. Lubke, “BPEL Unit”, 2006. [online]. Available: http://bpelunit.github.com , [ac-cessed on 18/03/2014].

[62] Dessislava Petrova-Antonova, Sylvia Ilieva, and Vera Stoyanova, “ TESSI: A WebService Testing Tool: Demonstration paper ”, In IEEE Seventh International Confer-

ence on Research Challenges in Information Science , Pages 1-2, May 2013.

[63] Dishant Munjal, Jagannath Singh, Subhrakanta Panda, and Durga Prasad Mohapatra,“Automated Slicing of Aspect-Oriented Programs Using Bytecode Analysis”, IEEE

39th Annual Computer Software and Applications Conference (COMPSAC), Pages191-199, 2015.

[64] Ed Morris, William Anderson, Sriram Bala, David Carney, John Morley, PatrickPlace, and Soumya Simanta, “Testing in Service-Oriented Environments”, A tech-nical report CMUSEI-2010-TR-011 ESC-TR-2010-011 March 2010, [online]. Avail-able: www.sei.cmu.edu. , [accessed on 18/03/2014].

[65] E. Duesterwald, R Gupta, and M. Soffa, “Distributed Slicing and Partial Re-executionfor Distributed Programs”, In Proceedings of Fifth Workshop on Languages and Com-

pilers for Parallel Computing, New Haven. Connecticut USA., Pages 497-511, August1992.

188

[66] Esubalew Alemneh, Abdul Azim Abd Ghani, and Rodziah Atan, “SAT4BSC: A StaticAnalysis Tool for BPEL Source Codes”, In International Journal of Computer Science

and Mobile Computing, Volume 3, Issue 2, Pages 659-665, February- 2014.

[67] Ebrahim Shamsoddin-Motlagh, “A Survey of Service Oriented Architecture SystemsTesting”, International Journal of Software Engineering & Applications (IJSEA), Vol-ume 3, No. 6, November 2012.

[68] Foster, H., Uchitel, S., Magee, J., and Kramer, J, “Model-based Verification of WebService Compositions”, In Proceedings of Eighteenth IEEE International Conference

on Automated Software Engineering, Pages 152-161, 2003.

[69] Frank Tip, “A Survey of Program Slicing Techniques”, Journal of Programming Lan-

guages ,Volume 3, Pages 121-189, 1995.

[70] Ferrante, J., Ottenstein, K., and Warren, J, “The Program Dependence Graph and it’sUse in Optimization”, ACM Transactions on Programming Languages and Systems 9,Pages 319-349, 1987.

[71] Frank Tip, Choi, J. D., Field, J., and Ramalingam, G, “Slicing Class Hierarchies inC++”, In Conference on Object-Oriented Programming Systems, Languages and Ap-

plications, Pages 179-197, 1996.

[72] Forgacs, I., and Bertolino, A., “Feasible Test Path Selection by Principal Slicing”, In

Proceedings of Sixth Euoropean Software Engineering Conference, 1997.

[73] Forrester Research, Enterprise and SMB Software Survey, North America and Europe,Q4 2008, 2009.

[74] Gaurish Hattangadi, “A Practitioners guide to Modern SOA Testing”, White Paper,Infosys, July 2011.

[75] Gerardo Canfora, Massimilliano Di Penta, “SOA: Testing and Self-Checking”, Inter-

national Workshop on Web Services Modeling and Testing (WS-MaTe2006), 2006.

[76] Gerardo Canfora and Massimilliano Di Penta, “Testing Services and Service-CentricSystems: Challenges and Opportunities”, IT Pro IEEE, March-April 2006.

[77] Gomez-Gutierrez, J., and Rivera-Vega, P., “A Framework for Smooth Composition ofChoreographies of Web Services”, In Proceedings of IEEE International Conference

on Web Services, Pages 1156-1157, 2007.

[78] Gallagher, K., and Lyle, J, “Using Program Slicing in Software Maintenance”, IEEE

Transactions on Software Engineering SE-17 , Pages 751-761, 1991.

189

[79] Gupta, R., Harrold, M. J., and Soffa, M. L,“Program Slicing-Based Regression TestingTechniques”, Journal of Software Testing, Verification and Reliability, 1996.

[80] G. A. Venkatesh, “The Semantic Approach to Program Slicing”, In Proceedings of

ACM SIGPLAN91 Conference on Programming Language Design and Implementa-

tion, Toronto, Canada, Pages 107-119, June 1991.

[81] G. Dai, X. Bai, Y. Wang, and F. Dai, “Contract-based testing for web services”, In

Proceedings of Thirty First Annual International Computer Software and Applications

Conference, Volume 1, Pages 517-526, July 2007.

[82] Gargi Bhattacharjee and Priya Pati, “A Novel Approach for Test Path Gener-ation and Prioritization of UML Activity Diagrams Using Tabu Search Algo-rithm”,International Journal of Scientific & Engineering Research, Volume 5, No.2, February 2014.

[83] Gerardo Canfora and Massimiliano Di Penta, “Testing Services and Service-CentricSystems: Challenges and Opportunities”, IT Pro, April 2006.

[84] Gerardo Canfora and Massimiliano Di Penta, “Service Oriented Architectures Test-ing: A Survey”, Springer-Verlog, LNCS 5413, Berlin, Heidelberg, Pages 78-105,2009.

[85] G. J. Holzmann, “The SPIN Model Checker: Primer and Reference Manual”,Addison-Wesley, Boston, Massachusetts, 2003.

[86] Hiralal Agrawal, R. A. DeMillo, and E. H. Spafford, “Dynamic Slicing in the Presenceof Pointers, Arrays and Records”, In Proceedings of Fourth Symposium on Testing,

Analysing and verification, Pages 60-73, ACM/IEEE-CS, October 1991.

[87] Hiralal Agrawal, “Towards Automatic Debugging of Computer Programs”, Ph.D.

Thesis, Purdue University, August 1991.

[88] Hong Zhu, “A Framework for Service-Oriented Testing of Web Services”, In Pro-

ceedings of Thirtyth Annual International Computer Software and Applications Con-

ferences, 2006.

[89] HP QuickTest Professional Tool, [online]. Available: http://www.hp.com/, [accessedon 18/03/2014].

[90] Horwitz, S., Reps, T., and Binkley, D, “Interprocedural Slicing Using DependenceGraphs”, ACM Transactions on Programming Languages and Systems, Pages 26-61,1990.

190

[91] Harman, M. and Danicic, S, “Using Program Slicing to Simplify Testing”, Journal of

Software Testing, Verification and Reliability, 1995.

[92] Huzefa Kagdi, Jonathan I. Maletic, and Andrew Sutton, “Context-free Slicing of UMLClass Models”, In Proceedings of Twenty First IEEE International Conference on

Software Maintenance, Pages 635-638, Washington, DC, USA, 2005.

[93] Horwitz, S., Prins, J., and Reps, T., “Integrating Noninterfering Versions of Pro-grams”, ACM Transactions on Programming Languages and Systems, Pages 345-387,1989.

[94] Hamlet, D, “Foundations of Software Testing: Dependability Theory”, ACM SIG-

SOFT Software Engineering Notes, Pages 128-139, 1994.

[95] International Data Corporation(IDC), [online], Available: http://www.idc.com/, [ac-cessed on 18/03/2014].

[96] Iriana Todoran, Zuheb Hussain, and Niina Gromove, “SOA Integration Modeling:An Evaluation of How SoaML Completes UML Modeling”,15th IEEE International

Enterprise Distributed Object Computing Conference Workshops, 2011.

[97] Ina Schieferdecker and Bernard Stepien, “Automated Testing of XML/SOAP BasedWeb Services”, [online]. Available: ”http://www.site.uottawa.ca/ bernard”, [accessedon 18/03/2014].

[98] J. Tretmans, “Testing Concurrent Systems: A Formal Approach”, In 10th Interna-

tional Conference on Concurrency Theory (CONCUR99), No. 1664 in LNCS, Pages46-65, Springer-Verlag, 1999.

[99] Jaiprakash T. Lallchandani and R. Mall, “Static Slicing of UML Architectural Mod-els”, Journal of Object Technology, Volume 8, No. 1, Pages 159-188, 2009.

[100] Jianjun Zhao, “Applying Slicing Technique to Software Architectures”, In Fourth

IEEE International Conference on Engineering of Complex Computer Systems, Pages87-98, 1998.

[101] Jianjun Zhao, “Slicing Software Architecture”, A Technical Report of Information

Processing Society of Japan,97-SE-117, Pages 85-92, Nov 1997.

[102] Jurijs Grigorjevs, “Model-Driven Testing Approach Based on UML Sequence Dia-gram”, Scientific Journal of Riga Technical University Computer Science. Applied

Computer Systems, Volume 47, 2011.

191

[103] Ke, Z., Zongyan, Q., and Hongli, Y., “Generating Scenarios From Web ServiceChoreography”, In Proceedings of IEEE Asia-Pacific Services Computing Conference,Pages 290-297, 2011.

[104] Kunihiro Noda, Takashi Kobayashi, Kiyoshi Agusa, and Shinichiro Yamamoto, “Se-quence Diagram Slicing”, 16th IEEE Asia-Pacific Software Engineering 2009 Con-

ference, 2009.

[105] Karner, C., Falk, J., and Nguyen, H. Q, Testing Computer Software Second Edition,Dreamtech Press, 2000.

[106] K. Kaschner and N. Lohmann, “Automatic Test Case Generation for Interacting Ser-vices”, In Service-Oriented Computing - ICSOC 2008 Workshops, Lecture Notes in

Computer Science, Volume 5472, Pages 66-78, April 2009.

[107] K. Sen and G. Agha, “Cute and Jcute: Concolic Unit Testing and Explicit Path Model-checking Tools”, In CAV. Springer, Pages 419-423, 2006.

[108] JGraphT Library, [online]. Available: jgrapht.org, [accessed on 18/03/2014].

[109] JGraph Library, [online]. Available: http://www.jgraph.com, [accessed on18/03/2014].

[110] Jaiprakash T Lallchandani and R Mall, “Slicing UML Architectural Models”, ACM

SIGSOFT Software Engineering Notes, Volume 33, No. 3, Page 1, May 2008.

[111] J.-D. Choi, B. P. Miller, and R H. B. Netzer, “Techniques for Debugging ParallelPrograms With Flowback Analysis”, ACM Transactions on Programming Languages

and Systems, Pages 491-530, October 1991.

[112] J. Field and F. Tip, “Dynamic Dependence in Term Rewriting Systems and Its Ap-plication to Program Slicing”, In Proceedings of Sixth International Symposium on

Programming Languages Implementation and Logic Programming, Pages 379-392,1994.

[113] J. Q. Ning, A.Engberts, and W. Kozaczynski, “Automated Support for Legacy CodeUnderstanding”, CACM, Pages 50-57, 1994.

[114] J.F. Bergeretti and B. A. Carre, “Information-Flow and Data-Flow Analysis of while-Programs”, ACM Transactions on Programming Languages and Systems, Pages 37-61, January 1985.

[115] J. Krinke, [online]. Available: http://www.cs.tubs.de/ krinke/Slicing/slicing.htlm, [ac-cessed on 18/03/2014].

192

[116] Jianjun Zhao, “Slicing Concurrent Java Programs”, In Seventh International Work-

shop on Program Comprehension, Pages 126-133, 1999.

[117] Jianjun Zhao, “Slicing Aspect-Oriented Software”, In Proceedings of Tenth Interna-

tional Workshop on Program Comprehension, 2002.

[118] Jaiprakash T Lallchandani, “Slicing UML Models”, Ph.D. Thesis, Computer Science& Engineering Department, IIT Kharagpur, 2010.

[119] J. Lyle. [online]. Available: http://hissa.ncsl.nist.gov/ jimmy/refs.html, [accessed on18/03/2014].

[120] J. Offutt and W. Xu, “Generating Test Cases for Web Services Using Data Perturba-tion”, In ACM SIGSOFT Software Engineering Notes, Volume 29, No. 5, Pages 1-10,2004.

[121] J. O. Wuzhi Xu and J. Luo, “Testing Web Services by XML Perturbation”, In Proceed-

ings of Sixteenth IEEE International Symposium on Software Reliability Engineering,Pages 257-266, 2001.

[122] Jos Garca-Fanjul, Javier Tuya, and Claudio de la Riva, “Generating Test Cases Specifi-cations for Compositions of Web Services”, In Proceedings of International Workshop

on Web Services Modeling and Testing, Pages 83-94, June 2006.

[123] J. Yan, Z. Li, Y. Yuan, W. Sun, and J. Zhang, “BPEL4WS Unit Testing: Test CaseGeneration Using a Concurrent Path Analysis Approach”, In Proceedings of Seven-

teenth International Symposium on Software Reliability Engineering, Pages 75-84,Nov. 2006.

[124] Jeena Gupta, “An Investigation of Test Cases Generation From Activity Diagram”,Master Thesis, Computer Science and Engineering Department, Thapar University,Patiala, June 2014.

[125] Joao Filipe Garrett Paixao Florencio, “Test Accelerator for Service Oriented Archi-tectures (SOA-Test Accelerator)”, Master Thesis, Computer Engineering Department,Tecnico Lisbao, October 2015.

[126] Jagannath Singh, Subhrakanta Panda, Pabitra Mohan Khilar, and Durga Prasad Mo-hapatra, “A Graph-Based Dynamic Slicing of Distributed Aspect-Oriented Software”,ACM SIGSOFT Software Engineering Notes 41(2): 1-8 (2016), 2016.

[127] Lyle, J. R., and Weiser, M. D., “Automatic Program Bug Location By Program Slic-ing”, In Proceedings of Second International Conference on Computers and Applica-

tions, Peking, China, Pages 877-882, 1987.

193

[128] Lucia, A. D., “Program Slicing: Methods and Applications”, In Proceedings of IEEE

International Workshop on Source Code Analysis and Manipulation , Pages 142-149,2001.

[129] Lanchezar Ribarov, Ilina Manova, and Sylvia Ilieva, “Testing in a Service-OrientedWorld”, In Proceedings of International Technologies, Bulgaria. Volume 1, September21-23, 2007.

[130] Lijun Mei, “A context-aware orchestrating and choreographic test framework forservice-oriented applications ”, ICSE Companion, Pages 371-374, 2009.

[131] Lallchandani and R. Mall, “A Dynamic Slicing Technique for UML ArchitecturalModels, IEEE Transaction on Software Engineering, Volume 37, No. 6, 2011.

[132] Larson, L. D., and Harrold, M. J, “Slicing Object-Oriented Software”, In Proceedings

of Eighteenth International Conference on Software Engineering, March 1996.

[133] Lanubile, F., and Visaggio, G., “Extracting Reusable Functions by Flow Graph-basedProgram Slicing”, IEEE Transactions on Software Engineering, Pages 246-259, 1997.

[134] Leung, H., and White, L,“Insights into Regression Testing Selection”, In Proceedings

of Conference on Software Maintenance, Pages 60-69, 1989.

[135] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Marti-Oliet, J. Meseguer, and C. Talcott,“Maude Manual (Version 2.1.1)”, SRI International, Menlo Park, Apr. 2005.

[136] M. Prasanna and K.R. Chandran, “Automatic Test Case Generation for UML Ob-ject Diagrams Using Genetic Algorithm”, International Journal of Advance Software

Computer Application”, Volume 1, No. 1, July 2009.

[137] Manpreet Kaur and Rupinder Singh, “Generation of Test Cases From Sliced SequenceDiagram”, International Journal of Computer Applications, Volume 97, No. 5, July2014.

[138] Marcos Palacios, Jose Garcia-Fanjul, and Javier Tuya, “Testing in Service OrientedArchitectures with Dynamic Binding: A Mapping Study”, Information and Software

Technology’, Volume 53, Issue 3, Pages 171-189, March 2011.

[139] Mangala Gowri Nanda and S. Ramesh, “Interprocedural Slicing of Multithreaded Pro-grams With Applications to Java”, ACM Transaction Programming Language System,Volume 28, No. 6, Pages 1088-1144, 2006.

[140] Mark Weiser, “Programmers Use Slices When Debugging”, j-CACM, Volume 25, No.7, Pages 446-452, 1982.

194

[141] Mark Weiser and J. R. Lyle, “Experiments on Slicing Based Debugging Aids”, In

Empirical Studies of Programmers, Pages 187-197, 1986.

[142] Mass Soldal Lund and Ketil Stlen, “Deriving Tests From UML 2.0 Sequence Dia-grams With neg and assert”, AST06, Shanghai, China, May 23 2006.

[143] Mathew Heusser, “Testing Service-Oriented Architecture: A Primer for the RealWorld”, July 31, 2008.

[144] Monalisa Sharma and Rajib Mall, “Automatic Test Case Generation From UML Mod-els, 10th International Conference on Information Technology, Pages.196-201, 2007.

[145] Michael Gebhart, Marc Baumgartner, and Sebastian Abeck, “Supporting Service De-sign Decisions”, In 5th International Conference on Software Engineering Advances,IEEE computer society, 2010.

[146] Mark Harman, [online]. Available: http://www.unl.ac.uk/ mark/slicing.html, [ac-cessed on 18/03/2014].

[147] M. Kamkar, “An Overview and Comparative Classification of Program Slicing Tech-niques”, In Journal of Systems and Software, Pages 197-214, 1995.

[148] M. Kamkar, “Inter Procedural Dynamic Slicing with Applications to Debugging andTesting”, Ph.D. Thesis, Linkoping University, Sweden, 1993.

[149] Mark Weiser, “Reconstructing Sequential Behavior From Parallel Behavior Projec-tions”, Information Processing Letters, Pages 129-135, 1983.

[150] Mark Harman, “Conditioned Slicing Supports Partition Testing”, Journal of Software

Testing, Verification and Reliability 12 (2002), Pages 23-28, 2002.

[151] Mark Weiser, “Program Slicing”, IEEE Transactions on Software Engineering, Pages352-357, 1984.

[152] M. Kamkar, P. Fritzson, and N. Shahmehri, “Three Approaches to InterproceduralDynamic Slicing”, Microprocessing and Microprogramming, Pages 625-636, 1993.

[153] M. Harman and S. Danicic, “A New Approach to Program Slicing”, In Proceedings

of Seventh International Quality Week, San Francisco, USA, May 1994.

[154] Microsoft Service Oriented Architecture (SOA), [online]. Available:https://msdn.microsoft.com/en-us/library/bb833022.aspx, [accessed on 18/03/2014].

[155] Microsoft Visio Professional 2016, [online]. Available:https://www.microsoft.com/en-in/evalcenter/evaluate-visio-professional-2016,[accessed on 18/03/2014].

195

[156] Min Aung, Susan Horwitz, Rich Joiner, and Thomas Reps, “Executable Slicing viaProcedure Specialization”, A Technical Report TR1711, University of Wisconsin,March 2012.

[157] Mark Harman and Sebastian Danicic, “Amorphous Program Slicing*”, In Proceed-

ings the Fifth International Workshop on Program Comprehension IWPC’97 , Pages70-79, 1997.

[158] Manna, Z., and R, W., “The Logic of Complete Programming”, IEEE Transactions on

Software Engineering, Pages 199-229, 1978.

[159] Morell, L. J, “A Theory of Fault-Based Testing”, IEEE Transactions on Software En-

gineering, 844-857, 1990.

[160] M. Lallali, F. Zaidi, and A. Cavalli, “Timed Modeling of Web Services Compositionfor Automatic Testing”, In Proceedings of International IEEE Conference on Signal-

Image Technologies and Internet-Based System, Pages 417-426, Dec. 2007.

[161] M. Lallali, F. Zaidi, A. Cavalli, and I. Hwang, “Automatic Timed Test Case Generationfor Web Services Composition”, In Proceedings of Sixth European Conference on Web

Services, Pages 53-62, Nov. 2008.

[162] M. B. Juric, “A Hands-on Introduction to BPEL”, [online]. Available:http://www.oracle.com/technology/pub/articles/ matjaz bpel1.html, [accessed on20/09/2015].

[163] M. Berkelaar, “Lp Solve, A Public Domain Mixed Integer Linear Program Solver”,http://groups.yahoo.com/group/lp solve/, [accessed on 20/09/2015].

[164] Madhusmita Sahu and Durga Prasad Mohapatra, “MM-path Approach for IntegrationTesting of Aspect-Oriented Programs”, In International Conference on Information

Technology (ICIT), 2015.

[165] Neil Davidson, “Learn how Lufthansa cargo achieved a problem rate of less than .2%while reducing testing efforts by 20%”, White Paper, [online]. Available: www.red-

gate.com, [accessed on 18/03/2014].

[166] Nicha Kosindrdecha and Jirapun Daengdej, “A Test Generation Method Based onState Diagram”, Journal of Theoretical and Applied Information Technology, 2010.

[167] Nicolas Gold and Andrew Mohan, Claire Knight, Malcolm Munro, “UnderstandingService-Oriented Software”, IEEE Software, 2004.

[168] NetBeans IDE, [online]. Available: https://netbeans.org, [accessed on 18/03/2014].

196

[169] Nour Ali, Fei Chen, and Carlos Solis, “Modelling Suport for Mobile Ambients in Ser-vice Oriented Architecture”,IEEE First International Conference on Mobile Services,2012.

[170] Nestor Catano, “Slicing Event Spaces: Towards a Java Programs Checking Frame-work”, Electronic Notes Theoretical Computer Science, Volume 80, Pages 59-74,2003.

[171] Ngo, M. N., and Tan, H. B. K., “Heuristics-Based Infeasible Path Detection for Dy-namic Test Data Generation”, Information and Software Technology 50, Pages 641-655, 2008.

[172] Naik, K., and Tripathy, P, Software Testing and Quality Assurance: Theory and Prac-

tice, John Wiley & Sons, 2011.

[173] N. Tillmann and J. de Halleux, “Pex - White Box Test Generation for .Net”, In Pro-

ceedings of Tests and Proofs, LNCS, Volume 4966, Prato, Italy:Springer Verlag, Pages134-153, 2008.

[174] Nik Looker, Malcolm Munro, and Jie Xu, “Testing Web Services”, [online].Available: www.comp.leeds.ac.uk/edemand/publications/looker04c.pdf, [accessed on18/03/2014].

[175] OMG, Service oriented architecture Modelling Language(SoaML) Specification,v1.0.1, May 2012, [online]. Available: https://www.omg.org, [accessed on18/03/2014].

[176] Organization for the Advancement of Structured Information Standards (OASIS), [on-line]. Available: https://www.oasis-open.org, [accessed on 18/03/2014].

[177] Ottenstein, K., and Ottenstein, L, “The Program Dependence Graph in Software De-velopment Environment”, In Proceedings of ACM SIGSOFT/SIGPLAN Software En-

gineering Symposium on Practical Software Develop Environments, SIGPLAN No-

tices, Volume 19, Pages 177-184, 1984.

[178] Object Management Group (OMG) Business Process Model and Notation (BPMN),[online]. Available: http://www.bpmn.org/, [accessed on 18/03/2014].

[179] OASIS Web Services Business Process Execution Language (WS-BPEL), [online].Available: https://www.oasis-open.org/, [accessed on 18/03/2014].

[180] Peltz, C., “Web Services Orchestration and Choreography”, ”Computer 36, 10

(2003)”, Pages 46-52, 2003.

197

[181] Parasoft SOAtest Tool, [online]. Available: http://www.parasoft.com/, [accessed on18/03/2014].

[182] PushToTest Testmaker Tool, [online]. Available: http://www.pushtotest.com/, [ac-cessed on 18/03/2014].

[183] Prachet Bhuyan, Asima Das, and Durga Prasad Mohapatra, “A Self Analysing andReliable SOA Model”, In IJCSET, Volume 1, issue 5, Pages 227-233, June 2011.

[184] Philip Bianco, Grace A. Lewis, Paulo Merson, and Soumya Simanta, “ArchitectingService-Oriented Systems”, a technical report CMU/SEI-2011-TN-008 August 2011,[online]. Available: www.sei.cmu.edu., [accessed on 18/03/2014].

[185] P. Mayer and D. Lbke, “Towards a BPEL Unit Testing Framework”, In Proceedings

of Workshop on Testing, Analysis, and Verification of Web Services and Applications,Pages 33-42, 2006.

[186] Parampreet Kaur, and Gaurav Gupta, “Automated Model-Based Test Path GenerationFrom UML Diagrams via Graph Coverage Techniques”, IJCSMC, Volume 2, Issue 7,Pages 302-311, July 2013.

[187] Poonkavithai Kalamegam and Zayaraz Godandapani, “A Survey on Testing SOA BuiltUsing Web Services”, International Journal of Software Engineering and Its Applica-

tions, Volume 6, No. 4, October 2012.

[188] P. Godefroid, N. Klarlund, and K. Sen, “Dart: Directed Automated Random Testing”,In Proceedings of Programming Language Design and Implementation, 2005.

[189] Qi, X., and Xu, B., “Dependence Analysis of Concurrent Programs Based on Reach-ability Graph and Its Applications”, In Proceedings of International Conference on

Computational Science, Pages 405-408, 2004.

[190] Philip Samuel, Rajib Mall and Sandeep Sahoo, “UML Sequence Diagram Based Test-ing Using Slicing”, IEEE Indicon 2005 Conference, Chennai, India, 11-13 Dec.2005.

[191] Philip Samuel, Rajib Mall, and Pratyush Kanth, “Automatic Test Case GenerationFrom UML Communication Diagram”, Information and Software Technology(49),

Elsevier, 158-171, 2007.

[192] Ranjita Kumari Swain, Vikas Panthi, and Prafulla Kumar Behera, “Test Case DesignUsing Slicing of UML Interaction Diagram”, In Second International Conference on

Communication, Computing and Security (ICCCS-2012),Elsevier, 2012.

198

[193] Rebai, S., Kacem, H., and Kacem, A., “Position paper: An Integration Approach ofService Composition Models: From Choreography to Orchestration”, In Proceedings

of IEEE Twenty First International Workshop on Enabling Technologies: Infrastruc-

ture for Collaborative Enterprises, Pages 423-425, 2012.

[194] Rajib Mall, Fundamentals of Software Engineering, PHI Learning Private Limited,second edition, February 2009.

[195] Reps, T., and Rosay, G., “Precise Interprocedural Chopping”, In Proceedings of Third

ACM Symposium on the Foundations of Software Engineering, Pages 41-52, 1995.

[196] Richard Gerber and Seongsoo Hong, “Slicing Real-Time Programs for EnhancedSchedulability”, ACM Transactions on Programming Languages and Systems, Vol-ume 19, Pages 19-3, 1995.

[197] Rothermel, G., and Harrold, M. J, “A Safe, Efficient Regression Rest Selection Tech-nique”, ACM Transactions on Software Engineering and Methodology (TOSEM),Pages 173-210, 1997.

[198] Rothermel, G., Untch, R. H., Chu, C., and Harrold, M. J, “Test Case Prioritization:An Empirical Study”, In Proceedings of IEEE International Conference on Software

Maintenance, Pages 179-188, 1999.

[199] S. Shanmuga Priya and P. D. Sheba Keizia Malarchelvi, “Test Path Generation UsingUml Sequence Diagram”, International Journal of Advanced Research in Computer

Science and Software Engineering, Volume 3, Issue 4, April 2013.

[200] Santosh Kumar Swain, Durga Prasad Mohapatra, and Rajib, “Test Case GenerationBased on Use Case and Sequence Diagram”, International Journal of Software Engi-

neering , Volume 3, Issue 2,Pages 21-52, July 2010.

[201] Scharam Dustdar and Stephan Haslinger, “Testing of Service Oriented Architectures-A practical approach”, springer LNCS, 27-30, September 2004.

[202] Service-Oriented Architecture Overview and Guide to SOA Research, [online]. Avail-able: www.gartner.com, [accessed on 18/03/2014].

[203] SOA Testing Technique, [online]. Available: http://www.blog.soatetsting.com, [ac-cessed on 18/03/2014].

[204] Srikant Inaganti and Sriram Arvamudan, “Testing SOA Application”, BPTrends,April 2008, [online]. Available: www.bptrends.com., [accessed on 18/03/2014].

199

[205] Sun, J., Liu, Y., Dong, J. S., Pu, G., and Tan, T. H, “Model-based Methods for LinkingWeb Service Choreography and Orchestration”, In Proceedings of Seventeenth Asia

Pacific Software Engineering Conference, Pages 166-175, 2010.

[206] SOA testing tool survey, [online]. Available:“http://soatestingresearch.blogspot.in/2008/10/soa-testing-tool-survey.html”, [ac-cessed on 18/03/2014].

[207] SoapUI Tool, [online]. Available: https://www.soapui.org, [accessed on 18/03/2014].

[208] SOAPSonar Tool, [online]. Available: http://www.crosschecknet.com/, [accessed on18/03/2014].

[209] “Service Oriented Architecture : What Is SOA?”, [online]. Available:http://www.opengroup.org/soa/source-book/soa/soa.htm, [accessed on 18/03/2014].

[210] Sneed, H. M., and Huang, S., “WsdlTest- A Tool for Testing Web Services”, In Pro-

ceedings of Eighth International Symposium on Web Site Evolution, 2006.

[211] Sparxsystems Enterprise Architect 12.1, [online]. Available:http://www.sparxsystems.com/products/ea/12.1/index.html, [accessed on 18/03/2014].

[212] S. Hanna and M. Munro, “Fault-based web services testing”, In 5th International

Conference on Information Technology: New Generations (ITNG 2008), Pages 471-476, April 2008.

[213] S. S. Hou, L. Zhang, Q. Lan, H. Mei, and J. S. Sun, “Generating Effective Test Se-quences for BPEL Testing”, In Proceedings of Ninth International Conference on

Quality Software, August 2009.

[214] Seema Jehan, Ingo Pill and Franz Wotawa, “SOA Grey Box Testing a Constraint-based Approach”, In Fifth International Workshop on Constraints in Software Testing,

Verification and Analysis, Pages 232-237, 2013.

[215] Subhrakanta Panda, Dishant Munjal, and Durga Prasad Mohapatra, “A Slice-BasedChange Impact Analysis for Regression Test Case Prioritization of Object-OrientedPrograms”, Advances in Software Engineering, New York, United States, Volume2016, Article No 1, May 2016.

[216] Subhrakanta Panda and Durga Prasad Mohapatra, “A Framework to Measure Cou-pling Using Static Change Impact Analysis”, International Journal of Business Infor-

mation Systems, Volume 23, No 3, Pages 353-387, 2016.

200

[217] Taeho Kim, Yeong-Tae Song, Lawrence Chung, and Dung T. Huynh, “Dynamic Soft-ware Architecture Slicing”, 23rd International Computer Software and Applications

Conference, COMPSAC ’99, Pages 61-66, Washington, DC, USA, 1999.

[218] Tarhini, A., Ismail, Z., and Mansour, N. , “Regression Testing Web Applications”, In

Proceedings of International Conference on Advanced Computer Theory and Engi-

neering, Pages 902-906, 2008.

[219] Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”,Prentice Hall PTR, ISBN: 0-13-185858-0, 2005.

[220] Testing New-age Application Built on Service Oriented Architecture, White Paper.[online]. Available: www.cognizent.com, [accessed on 18/03/2014].

[221] Testing Service-Oriented Architecture (SOA) Applications and Services, White Paper,[online]. Available: www.hp.com/go/software, [accessed on 18/03/2014].

[222] Torry Harris, “SOA Test Methodology”,[online]. Available: http://www.thbs.com/soa,[accessed on 18/03/2014].

[223] T. Reps and T. Bricker, “Illustrating Interference in Interfering Versions of Programs”,In Proceedings of Second International Workshop on Software Configuration Man-

agement, Princeton, Pages 46-55, 1989.

[224] Thomas Erl, “SOA: Principles of Service Design”, Prentice Hall, ISBN: 0-13-234482-3, 2008.

[225] Tip, F., “Infeasible Paths in Object-Oriented Programs”, Science of Computer Pro-

gramming, Pages 91-97, 2015.

[226] Tien-Dung Cao, Richard Castanet, Patrick Felix and Gerardo Morales, “Testing ofWeb Services: Tools and Experiments”, In IEEE Asia-Pacific Services Computing

Conference, Pages 78-85, 2011.

[227] V.Mary Sumalatha and G.S.V. P Raju, “UML Based Automated Test Case GenerationTechnique Using Activity-Sequence Diagram”, The International Journal of Com-

puter Science and Applications (TIJCSA), Volume 1, No. 9, November 2012.

[228] Vikash Panthi and Durga Prasad Mohapatra, “Automatic Test Case Generation UsingSequence Diagram”, In Proceedings of ICAdc, AISC 174, Springer India, Pages 277-284, 2013.

[229] Vikash Panthi and Durga Prasad Mohapatra, “Automatic Test Case Generation UsingSequence Diagram”, International Journal of Applied Information System (IJAIS),Volume 2, No. 4, May 2012.

201

[230] Visual Paradigm for UML Enterprise Edition, [online]. Available: http://www.visual-

paradigm.com, [accessed on 18/03/2014].

[231] Vinod R Patil, “Introduction to Testing Web Services”, [online]. Avail-able: http://www.qaielearning.com/KnowledgePapers/Introduction-to-Testing-

Webservices.pdf, [accessed on 18/03/2014].

[232] W.K.Chan, S.C. Cheung, Karl R.P.H, and Tsing Yi, “A Metamorphic Testing Ap-proach for Online Testing of service-Oriented Software Applications”, International

Journal of Web Services Research, Volume x, No. x, 200x.

[233] W.T.Tsai, Jerry Gao, Xiao Wei, and Yinong Chen, “Testability of Software in Service-Oriented Architecture”, ’In Proceedings of Thirtyth annual International Computer

Software and Applications Conference, Pages 163-168, 2006.

[234] Web Service Glossary, [online]. Available: http://www.w3.org,[accessed on18/03/2014].

[235] Wieczork, S., Roth, A., Stefanescu, A., Kozyura, V., Charfi, A., Kraft, F., andSchieferdecker, I, “Viewpoints for Modeling Choreographies in Service Oriented Ar-chitectures, In Proceedings of European Conference on Software Architecture and

Joint Working IEEE/IFIP Conference on Software Architecture, Pages 11-20, 2009.

[236] WS Monitor Tool, [online]. Available: https://java.net/projects/wsmonitor, [accessedon 18/03/2014].

[237] W.T.Tsai, Ray Paul,Yamin Wang, Chun Fan, and Dong Wangl, “Extending WSDLto Facilitate Web Services Testing”, In Proceedings of Seventh IEEE International

Symposium on High Assurance Systems Engineering, Pages 171-172, 2002.

[238] World Wide Web Consortium (W3C), [online]. Available: http://http://www.w3.org/,[accessed on 18/03/2014].

[239] W3C documentation, [online]. Available: http://www.w3.org/TR/ws-arch/, [accessedon 18/03/2014].

[240] World Wide Web Consortium (W3C ), “SOAP Simple Object Access Protocol”, [on-line]. Available: http://www.w3.org/TR/soap/, [accessed on 18/03/2014].

[241] World Wide Web Consortium (W3C ), “WSDL Web Services Description Language”,[online]. Available: http://www.w3.org/TR/wsdl, [accessed on 18/03/2014].

[242] Web Service WSDL data sets, [online]. Available: http://webservicex.net/, [accessedon 18/03/2014].

202

[243] W. T. Tsai, Ray Paul, Weiwei Song, and Zhibin Cao, “Coyote: An XML-BasedFramework for Web Services Testing”, In Proceedings of Seventh IEEE International

Symposium on High Assurance Systems Engineering, 2002.

[244] WS-I Testing Tool, [online]. Available: https://www.ws-i.org, [accessed on18/03/2014].

[245] WebInject Testing Tool, [online]. Available: http://www.webinject.org/, [accessed on18/03/2014].

[246] W. T. Tsai, X. Wei, Y. Chen, R. Paul, and B. Xiao, “Swiss Cheese Test Case Gener-ation for Web Services Testing”, In IEICE-Transactions on Information and Systems,Volume E88-D, No. 12, Pages 2691-2698, 2005.

[247] W. Dong and H. YU, “Web Service Testing Method Based on Fault-coverage”,In Tenth IEEE International Enterprise Distributed Object Computing Conference,Pages 43-43, Oct. 2006.

[248] Wang Linzhang, Yuan Jiesong, Yu Xiaofeng, Hu Jun, Li Xuandong and Zheng Guo-liang, “Generating Test Cases From UML Activity Diagram Based on Gray-BoxMethod”, In Proceedings of Eleventh Asia-Pacific Software Engineering Conference,2004.

[249] W. Dong, “Test Case Generation Method for BPEL-based Testing, In International

Conference on Computational Intelligence and Natural Computing, Volume 2, Pages467-470, June 2009.

[250] Xiaoying Bai, Wenli Dongl, Wei-Tek Tsai, and Yinong Chen, “WSDL-Based Auto-matic Test Case Generation for Web Services Testing”, In Proceedings of IEEE Inter-

national Workshop on Service-Oriented System Engineering, Pages 207-212, 2005.

[251] XSL Transformation Document, [online]. Available: http://www.w3.org/TR/xslt/, [ac-cessed on 18/03/2014].

[252] Xu, L., Xu, B., Chen, Z., Jiang, J., Chen, H., and Yang, H., “Regression Testing forWeb Applications Based on Slicing”, In Proceedings of Twenty Eighth IEEE Annual

International Computer Software and Applications Conference, IEEE CS Press, Pages652-656, 2003.

[253] X. Bai, S. Lee, W. T. Tsai, and Y. Chen, “Ontology-based Test Modeling and PartitionTesting of Web Services”, In Proceedings of 2008 IEEE International Conference on

Web Services, Pages 465-472, Sept. 2008.

203

[254] Xiang Fu, Tevfik Bultan, and Jianwen Su, “WSAT: A Tool for Formal Analysis ofWeb Services”, Computer Aided Verification, Springer LNCS, Volume 3114, Pages510-514, 2004.

[255] XML Schema (w3c) , [online]. Available: https://en.wikipedia.org/wiki/XML Schema (W3C),[accessed on 18/03/2014].

[256] Young, M. and Taylor, R. N, “Rethinking the Taxonomy of Fault Detection Tech-niques”, In Proceedings of Eleventh International Conference on Software Engineer-

ing, ACM, Pages 53-62, 1989.

[257] Y. Wang, X. Bai, J. Li, and R. Huang, “Ontology-based Test Case Generation forTesting Web Services”, In Proceedings of Eighth International Symposium on Au-

tonomous Decentralized Systems, Pages 43-50, March 2007.

[258] Yuan Yuan, Zhongjie Li, and Wei Sun, “A Graph-search Based Approach toBPEL4WS Test Generation ”, In Proceedings of International Conference on Soft-

ware Engineering Advances, 2006.

[259] Y. Yang, Q. Tan, and Y. Xiao, “Verifying Web Services Composition Based on Hierar-chical Colored Petri Nets, In Proceedings of First International Workshop on Interop-

erability of Heterogeneous Information Systems, New York, USA:ACM, Pages 47-54,2005.

[260] Zhao, C., Duan Z., and Zhang, M. , “A Model-driven Approach for Dynamic Web Ser-vice Composition”, In Proceedings of WRI World Congress on Software Engineering,Volume 4, Pages 273-277, 2009.

[261] Zhao, J., and Li, B., “Dependence Based Representation for Concurrent Java Pro-grams and Its Application to Slicing”, In Proceedings of ISFST, Pages 105-112, 2004.

[262] Zeng, J., Soviani, C., and Edwards, S. A., “Generating Fast Code From ConcurrentProgram Dependence Graph”, In Proceedings of ACM LCTES, Pages 175-181, 2004.

[263] Zhao, J., Cheng, J., and Ushijima, K., “A Dependence Based Representation for Con-current Object-Oriented Software Maintenance”, In Proceedings of Second Euromicro

Conference on Software Maintenance and Reengineering, Pages 60-66, 1998.

[264] Zhang, J., and Qiu, R., “Fault Injection-based Test Case Generation for SOA-orientedSoftware”, In Proceedings of IEEE International Conference on Service Operations

and Logistics, and Informatics, Pages 1070-1078, 2006.

[265] Zhu, H., Hall, P. A., and May, J. H, “Software Unit Test Coverage and Adequacy”,ACM computing surveys, Pages 366-427, 1997.

204

[266] Z. J. Li, J. Zhu, L.-J. Zhang, and N. Mitsumori, “Towards a Practical and EffectiveMethod for Web Services Test Case Generation”, In Proceedings of ICSE Workshop

on Automation of Software Test, Pages 106-114, May 2009.

[267] Z. Li, W. Sun, Z. B. Jiang, and X. Zhang, “BPEL4WS Unit Testing: Framework andImplementation”, In Proceedings of IEEE International Conference on Web Services,Volume 1, Pages 103-110, July 2005.

[268] Z. Guangquan, R. Mei, and Z. Jun, “A Business Process of Web Services TestingMethod Based on UML 2.0 Activity Diagram”, In Proceedings of Workshop on Intel-

ligent Information Technology Application, Pages 59-65, Dec. 2007.

[269] Zhao, J., “Multithreaded Dependence Graphs for Cuncurrent Java Programs”, In Pro-

ceedings of International Symposium on Software Engineering for Parallel and Dis-

tributed Systems, 1999.

205

Appendices

206

Appendix-A

This appendix contains supplementary information of case studies that we have been consid-ered for our work.

• Railway Reservation Software (RRS)The RRS concerns automating the activities of a passenger of the railway. The detailedrequirement is as follows:

1. Passenger query is based on train number, source, destination, date of journey,etc.

2. Various details regarding customer such as his name, age, address, identificationnumber, etc. are entered at the time customer books ticket, and on successfulbooking a unique ticket number should be assigned.

3. Passenger can cancel the booked tickets based on ticket number.

4. Passenger may signup to view history of tickets.

• Municipality Garbage Collection Automation Software (MGCAS)The mayor of a municipality wants to automate the activities of garbage collectionprocess for various wards of the city. The detailed requirement is as follows:

1. Citizens raise garbage collection request by giving name, address, location ofgarbage, type of garbage i.e solid, liquid, hazardous, organic, recyclable andapproximate quantity.

2. Ward supervisors visit the garbage, studies garbage and possibly approve therequest by determining the type of garbage trucks, priority and possible routesfor garbage pickup and nearest dumping sites etc.

3. Garbage collection manager schedules the request based on the availability ofmanpower and trucks.

207

4. Mayer may see the various garbage collection statistics such as the number andcollection outstanding at some point of time.

• House Rental Software (HRS)The HRS allows the property owner to offer his rental request using the name, theaddress of rentable property, contact address, contact number, rent amount, area, typeof utility facility i.e gas line, electricity, etc. The customer searches the rentable prop-erties based on the address, amount etc.

• Travel Reservation System (TRS)The TRS offers the followings:

1. People to book complete vacation packages including plane/train/bus/cruise tick-ets, hotels, car rental etc.

2. Credit card companies are providing services to guarantee payments made bycustomers.

3. Visa companies are providing services to guarantee availability of visa for cus-tomers.

4. Insurance companies are providing insurance services to customers.

5. Customers may login/signup to view history of tickets.

6. Customers can cancel the booked tickets.

7. Customers can check the status of refunds.

8. Customers can check the status of flights.

208

SLICING OF SOA-BASED SOFTWARE AND ITS APPLICATION TO … · SLICING OF SOA-BASED SOFTWARE AND ITS...

Documents

Transcript of SLICING OF SOA-BASED SOFTWARE AND ITS APPLICATION TO … · SLICING OF SOA-BASED SOFTWARE AND ITS...