Please use this identifier to cite or link to this item:
Full metadata record
DC FieldValueLanguage
dc.contributor.authorHierons, RM-
dc.contributor.authorMerayo, MG-
dc.contributor.authorNunez, M-
dc.identifier.citationSoftware: Practice and Experience, 41(10): 999 - 1026, Sep 2011en_US
dc.descriptionCopyright @ 2011 John Wiley & Sonsen_US
dc.description.abstractDistributed systems are usually composed of several distributed components that communicate with their environment through specific ports. When testing such a system we separately observe sequences of inputs and outputs at each port rather than a global sequence and potentially cannot reconstruct the global sequence that occurred. Typically, the users of such a system cannot synchronise their actions during use or testing. However, the use of the system might correspond to a sequence of scenarios, where each scenario involves a sequence of interactions with the system that, for example, achieves a particular objective. When this is the case there is the potential for there to be a significant delay between two scenarios and this effectively allows the users of the system to synchronise between scenarios. If we represent the specification of the global system by using a state-based notation, we say that a scenario is any sequence of events that happens between two of these operations. We can encode scenarios in two different ways. The first approach consists of marking some of the states of the specification to denote these synchronisation points. It transpires that there are two ways to interpret such models and these lead to two implementation relations. The second approach consists of adding a set of traces to the specification to represent the traces that correspond to scenarios. We show that these two approaches have similar expressive power by providing an encoding from marked states to sets of traces. In order to assess the appropriateness of our new framework, we show that it represents a conservative extension of previous implementation relations defined in the context of the distributed test architecture: if we onsider that all the states are marked then we simply obtain ioco (the classical relation for single-port systems) while if no state is marked then we obtain dioco (our previous relation for multi-port systems). Finally, we concentrate on the study of controllable test cases, that is, test cases such that each local tester knows exactly when to apply inputs. We give two notions of controllable test cases, define an implementation relation for each of these notions, and relate them. We also show how we can decide whether a test case satisfies these conditions.en_US
dc.description.sponsorshipResearch partially supported by the Spanish MEC project TESIS (TIN2009-14312-C02-01), the UK EPSRC project Testing of Probabilistic and Stochastic Systems (EP/G032572/1), and the UCM-BSCH programme to fund research groups (GR58/08 - group number 910606).en_US
dc.publisherJohn Wiley & Sonsen_US
dc.subjectFormal testingen_US
dc.subjectSystems with distributed portsen_US
dc.subjectImplementation relationsen_US
dc.subjectControllable testingen_US
dc.titleScenarios-based testing of systems with distributed portsen_US
pubs.organisational-data/Brunel/Brunel (Active)-
pubs.organisational-data/Brunel/Brunel (Active)/School of Info. Systems, Comp & Maths-
pubs.organisational-data/Brunel/Research Centres (RG)-
pubs.organisational-data/Brunel/Research Centres (RG)/CIKM-
pubs.organisational-data/Brunel/School of Information Systems, Computing and Mathematics (RG)-
pubs.organisational-data/Brunel/School of Information Systems, Computing and Mathematics (RG)/CIKM-
Appears in Collections:Publications
Computer Science
Dept of Computer Science Research Papers

Files in This Item:
File Description SizeFormat 
dioco_ext_scenarios3.pdf457.53 kBUnknownView/Open

Items in BURA are protected by copyright, with all rights reserved, unless otherwise indicated.