Natallia Kokash(Accepted for PACO’2011)

ACG, 31/05/20111

Input-output conformance testing for channel-based connectors

1

Agenda

ACG, 31/05/20112

IntroductionReoSemantics of Reo

Automata-basedProcess algebra-based

Input-output conformance (ioco) theoryUsing ioco to test ReoTool support

Related workConclusions and future work

ACG, 31/05/20113

Introduction

Reo is a channel-based coordination language

Components or services are coordinated by Reo connectors

Primitive connectors with just two ends are called channels

Connectors can be composed to form more complex connectors

Channels are user-definedNodes implement a fixed routing policy

ACG, 31/05/20114

Constraint automata

Constraint automaton A = (S, N , →, s0) consists of a set of states S, a set of port names N , a transition relation → ⊆ S × 2N × DC × S, where

DC is the set of data constraints over a finite data domain Data,

an initial state s0 ∈ S.

Two operators on CA are defined: product and port hiding

A CA for a Reo connector can be computed as product of CA for individual channels.

ACG, 31/05/20115

Basic Reo channels and nodes

ACG, 31/05/20116

Constraint automata for basic channels and nodes

ACG, 31/05/20117

Process algebra mCRL2 Actions are atomic events Processes are the active entities defined as expressions over actions and other processes

Multiaction: a|b (synchronized actions) Alternative composition: a + b (nondeterministic choice) Sequential composition: a.b (b started after a) Conditional: exp → a ◊ b (if-then-else) At operator: act (action a happens at time t) Summation: ∑d∈D a(d) (a(d1) + a(d2) + a(d3)…)

Parallel composition: a||b (interleavings a.b + b.a + a|b) Renaming: ρR(a) where R is a set of renamings of the form b → c, meaning

that every occurrence of b in a is replaced by c Hiding: τH(a) renames all actions of H in a to τ

Restriction (allow): ∇R(a) where R specifies which actions are allowed to occur in a

Blocking: ∂B(a) where B is a set of actions that is not allowed to occur in a

Communication: ΓC(p), where C is a set of allowed communications of the form a0|...|an→ c, n ≥1 which means that every group of actions a0|...|an within a multiaction is replaced by an action c

ACG, 31/05/20118

From CA to mCRL2Data flow observed at a channel end = mCRL2 action

ACG, 31/05/20119

Correctness

ACG, 31/05/201110

Correctness

Why do we need testing for Reo?

ACG, 31/05/201111

Circuit design is error-proneIt is not a trivial task to design a Reo

connector with a certain behaviorModel-checking is not always feasible (e.g.,

data-aware models with infinite domains)When Reo is used for workflow and

dataflow design, how do we assure the quality of workflow/dataflow implementations?

Specification: Reo

ACG, 31/05/201112

Implementation: extension of BPEL

ACG, 31/05/201113

<bpws:process exitOnStandardFault="yes" name="separation_of_duty_V_001“ suppressJoinFailure="yes"

targetNamespace=http://www.iaas.uni-stuttgart.de/pf/separation_of_duty … <bpws:variables> <bpws:variable name=“Clerk1"/> <bpws:variable name=“Clerk2"/> <bpws:variable name=“ProcessRequest"/> <bpws:variable name=“Authorize"/> </bpws:variables> <bpws:sequence name="Process Fragement: Separation of duty"> <bpws:scope name="Scope"> <bpws:flow name="Flow"> <bpws:links> <bpws:link name="link1"/> <bpws:link name="link2"/> <bpws:link name="link3"/>

<bpws:link name="link4"/> </bpws:links> <bpws:sources> <bpws:source linkName="link1"/> </bpws:sources> <bpws:invoke name=“Task1"> <bpws:targets> <bpws:target linkName="link1"/> </bpws:targets> <bpws:sources> <bpws:source linkName="link2"/> </bpws:sources> </bpws:invoke> … <bpws:invoke name=“Task2“> <bpws:targets> <bpws:target linkName="link3"/> </bpws:targets> <bpws:sources> <bpws:source linkName="link4"/> </bpws:sources> </bpws:invoke> </bpws:flow> </bpws:scope> </bpws:sequence> </bpws:process>

ACG, 31/05/201114

Examples of wrong connector implementations

Input-output conformance theory

ACG, 31/05/201115

Model-based testing aims at automatically generating test suits from software models

J. Tretmans (2008): Model Based Testing with Labelled Transition Systems. In: Formal Methods and Testing, LNCS 4949, Springer, pp. 1–38.

Formal, specification-based active, black-box, functionality testing

Labelled transition systems

ACG, 31/05/201116

Language with LTS as operational semantics

ACG, 31/05/201117

Sequences of observable actions

ACG, 31/05/201118

Some definitions: tau-abstracted sequence of observable actions

ACG, 31/05/201119

Some useful definitions

ACG, 31/05/201120

LTL with Inputs/Outputs and Input-Output Transition Systems (IOTS)

ACG, 31/05/201121

Input-output transition systems

ACG, 31/05/201122

Two ways to convert LTL with I/O to IOTS:1. Angelic completion: add self-loops to every

reachable state

2. Demonic completion: add a chaos state χ such that all non-specified inputs lead to χ, once in χ any behavior is possible.

Quiescent and suspension traces

ACG, 31/05/201123

Extend traces with observations of quiescence:

Traces that can contain the quiescence action are called suspension traces:

Quiescence

ACG, 31/05/201124

The occurrence of θ in a test indicates the detection of quiescence δ

Test case

ACG, 31/05/201125

A tester should not offer more than one input at a time:

Examples of test cases

ACG, 31/05/201126

The ioco relation

ACG, 31/05/201127

Example

ACG, 31/05/201128

Compositional testing

ACG, 31/05/201129

Example

ACG, 31/05/201130

Test execution

ACG, 31/05/201131

Test generation

ACG, 31/05/201132

Application of ioco to testing ReoReo is a language with LTS semanticsWe can associate mCRL2 processes with

each state of a Reo circuit{A,B,C}→ A|B|C – a unique action (can be

renamed e.g., to ABC)

Extend CA/LTS with Input/Output actionsIs Reo implementation input enabled?

Specification: CA, implementation: ReoSpecification: Reo, implementation: ReoSpecification: Reo, implementation: BPEL,

Java, etc.ACG, 31/05/201133

ACG, 31/05/201134

CA with Inputs and Outputs

Encoding for boundary nodes:

Input/Output CA

ACG, 31/05/201135

We can apply angelic completion to a CA with I/O without changing the functional behavior of the circuit it specifies

Every boundary node A has associated Input and Output actions: A circuit cannot accept ?A through its input port A without observing !AAn environment cannot observe !B on the circuit output port B before ?B

What happens with pending requests if the circuit cannot process them?

ACG, 31/05/201136

Compositional testing for Reo

Tool support

ACG, 31/05/201137

specification (s)

Implementation (i)

ACG, 31/05/201138

Test case simulation

Related work

ACG, 31/05/201139

B. K. Aichernig, F. Arbab, L. Astefanoaei, F. S. de Boer, M. Sun & J. Rutten: Fault-Based Test Case Generation for Component Connectors. In: Third IEEE International Symposium on Theoretical Aspects of Software Engineering, (2009), pp. 147–154.

S. Meng, F. Arbab, B. K. Aichernig, L. Aştefănoaei, Frank S. de Boer, J. Rutten, “Connectors as designs: Modeling, refinement and test case generation,Science of Computer Programming, (2011).

Considers connectors as designsA prototype tool for test case generation developed in

Maude

“An approach based on I/O FSM is not appropriate for generating test cases for connectors, since it assumes that a pair of input and output constitutes an atomic action of a system, in other words, that the system cannot accept the next input before producing the output in reaction to the previous input. In Reo, such assumptions do not hold.”

Future work

ACG, 31/05/201140

Testing Java code generation for ReoTesting data-aware Reo:

J. Tretmans L. Frantzen & T. A.C. Willemse (2005): Test Generation Based on Symbolic Specifications. In J. Grabowski & B. Nielsen, editors: Proc. FATES 2004, LNCS 3395, Springer, pp. 1–15.

Testing timed Reo:Brinksma E. Brandan Briones, L. (2005): A Test

Generation Framework for quiescent Real-Time Systems. In J. Grabowski & B. Nielsen, editors: Proc. FATES 2004, LNCS 3395, Springer, pp. 64–78.