1 / 40

Input-output conformance testing for channel-based connectors

This paper discusses input-output conformance testing for channel-based connectors using Reo, automata, process algebra, and ioco theory. Tools, related work, and future work are also covered.

lcarnes
Download Presentation

Input-output conformance testing for channel-based connectors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Input-output conformance testing for channel-based connectors Natallia Kokash (Accepted for PACO’2011) ACG, 31/05/2011 1

  2. Agenda • Introduction • Reo • Semantics of Reo • Automata-based • Process algebra-based • Input-output conformance (ioco) theory • Using ioco to test Reo • Tool support • Related work • Conclusions and future work ACG, 31/05/2011

  3. 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-defined • Nodes implement a fixed routing policy ACG, 31/05/2011

  4. 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/2011

  5. Basic Reo channels and nodes ACG, 31/05/2011

  6. Constraint automata for basic channels and nodes ACG, 31/05/2011

  7. 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 (actiona happens at time t) • Summation:∑d∈Da(d) (a(d1) + a(d2) + a(d3)…) • Parallel composition:a||b (interleavings a.b + b.a + a|b) • Renaming:ρR(a) where Ris 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/2011

  8. From CA to mCRL2 Data flow observed at a channel end = mCRL2 action ACG, 31/05/2011

  9. Correctness ACG, 31/05/2011

  10. Correctness ACG, 31/05/2011

  11. Why do we need testing for Reo? • Circuit design is error-prone • It is not a trivial task to design a Reo connector with a certain behavior • Model-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? ACG, 31/05/2011

  12. Specification: Reo ACG, 31/05/2011

  13. Implementation: extension of BPEL • <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/2011

  14. Examples of wrong connector implementations ACG, 31/05/2011

  15. Input-output conformance theory • 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 ACG, 31/05/2011

  16. Labelled transition systems ACG, 31/05/2011

  17. Language with LTS as operational semantics ACG, 31/05/2011

  18. Sequences of observable actions ACG, 31/05/2011

  19. Some definitions: tau-abstracted sequence of observable actions ACG, 31/05/2011

  20. Some useful definitions ACG, 31/05/2011

  21. LTL with Inputs/Outputs and Input-Output Transition Systems (IOTS) ACG, 31/05/2011

  22. Input-output transition systems 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. ACG, 31/05/2011

  23. Quiescent and suspension traces Extend traces with observations of quiescence: Traces that can contain the quiescence action are called suspension traces: ACG, 31/05/2011

  24. Quiescence The occurrence of θ in a test indicates the detectionof quiescence δ ACG, 31/05/2011

  25. Test case A tester should not offer more than one input at a time: ACG, 31/05/2011

  26. Examples of test cases ACG, 31/05/2011

  27. The iocorelation ACG, 31/05/2011

  28. Example ACG, 31/05/2011

  29. Compositional testing ACG, 31/05/2011

  30. Example ACG, 31/05/2011

  31. Test execution ACG, 31/05/2011

  32. Test generation ACG, 31/05/2011

  33. Application of ioco to testing Reo • Reo is a language with LTS semantics • We 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 actions • Is Reo implementation input enabled? • Specification: CA, implementation: Reo • Specification: Reo, implementation: Reo • Specification: Reo, implementation: BPEL, Java, etc. ACG, 31/05/2011

  34. CA with Inputs and Outputs Encoding for boundary nodes: ACG, 31/05/2011

  35. Input/Output CA • Every boundary node A has associated Input and Output actions: • A circuit cannot accept?A through its input port A without observing!A • An environment cannot observe !B on the circuit output port B before ?B • What happens with pending requests if the circuit cannot process them? We can apply angelic completion to a CA with I/O without changing the functional behavior of the circuit it specifies ACG, 31/05/2011

  36. Compositional testing for Reo ACG, 31/05/2011

  37. Tool support specification (s) Implementation (i) ACG, 31/05/2011

  38. Test case simulation ACG, 31/05/2011

  39. Related work • 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 designs • A prototype tool for test case generation developed in Maude • “An approach basedon 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.” ACG, 31/05/2011

  40. Future work • Testing Java code generation for Reo • Testing 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. ACG, 31/05/2011

More Related