Symbolic test case generation for testing orchestrators in context

HAL Id: tel-00625319

https://tel.archives-ouvertes.fr/tel-00625319

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Symbolic test case generation for testing orchestrators

in context

José Pablo Escobedo del Cid

To cite this version:

José Pablo Escobedo del Cid. Symbolic test case generation for testing orchestrators in context. Other [cs.OH]. Institut National des Télécommunications, 2010. English. �NNT : 2010TELE0027�. �tel-00625319�

Symbolic Test Case Generation for

Testing Orchestrators in Context

(Génération Symbolique des Cas de Test pour Tester d’Orchestrateurs en Contexte)

Résumé de la thèse de José Pablo Escobedo Telecom SudParis Supervisé par: Ana Cavalli et Pascale Le Gall

L

machines à travers l’Internet. Les services Web sont basés sur l’Architecture Orientée Services (SOA, pour son nom en anglais). Ils peuvent être invoqués en utilisant des standards pour le Web (normalement, SOAP [GHM+_{07], UDDI [CHvRR04],} XML[BPSM+_{08], HTTP [FGM}+_{99], WSDL [CCMW01]). Dans les dernières années,} l’utilisation des services Web a augmenté à cause de la flexibilité qu’ils offrent, ainsi comme de l’intégration des systèmes hétérogènes. En plus, SOA ajoute de la valeur dans le sens où les services peuvent être réutilisés et partagés; cela fait les systèmes plus flexibles et adaptables en cas où il y a des changements dans les processus des en-treprises, et améliore l’intégration des systèmes [HS05]. Aussi, des nouvelles façons d’utiliser les services Web se sont développées, en combinant pour créer des services plus complets et complexes. Le processus de réutiliser les services Web pour en créer des nouveaux s’appelle composition des services Web, et son but principal est de per-mettre la réutilisation des fonctionnalités proposées par les services Web. C’est pour cette raison que l’architecture SOA a été bien acceptée par les entreprises partout dans le monde: elle aide à réduire le coût et le temps qu’il faut pour créer des solutions, et c’est la composition des services Web que nous étudions dans cette thèse. Plus spé-cifiquement, on veut assurer leur correct comportement en utilisant des techniques du test pour détecter des possibles erreurs.

Parmi les différents façons de créer des compositions des services Web, les deux qui sont les plus utilisées sont ( [Pel03]):

• Chorégraphies des services Web [MKB09], où chaque service Web dans la position interagis au même niveau, en connaissant quand et comment se com-muniquer avec le reste des services Web.

• Orchestrations des services Web [GJW04], où il y a un composant central qui guide le processus, en prenant des décisions selon les réponses des services Web. Il y a aussi une autre façon de faire des compositions des services Web, qui est basée sur la Web sémantique, et qui n’est pas une orchestration mais plutôt une chorégraphie. Parmi les trois types de faire des compositions mentionnés, les orchestrations sont les plus utilisés (au moment de l’écriture de ce document). Une des raisons est ce que la façon la plus utilisée de créer des orchestrations est en utilisant le standard WS-BPEL (pour Web Services Business Process Execution Language), qui a été développée par OASIS1_{(qui est un consortium qui guide le développement et l’adoption des standards} pour la communauté global informaticienne). En plus, WS-BPEL est basé sur XLANG (Microsoft, 2001) et WSFL (IBM, 2001), et plusieurs entreprises connues ont participé lors de ça création (Microsoft, IBM, SAP, Oracle, Adobe Systems, parmi autres).

Dû à la grande acceptation de cet nouvelle technique de combiner des services Web pour créer des nouveaux, plus complètes et complexes, des nouvelles façons d’assurer leur correct comportement ont été aussi développées [vBK06]. En plus, les orchestra-tions ont des caractéristiques spéciales qui n’ont pas présentes dans des autres types des systèmes (comme les systèmes unitaires), et les approches du test habituels (i.e., techniques du test unitaire utilisées avec des systèmes isolés) ne les prennent pas en compte. Dans cet thèse, on s’intéresse à cet problème pour finalement apporter un nouvel approche (boîte noire) du test pour aider avec la validation et vérification des orchestrations.

On va parler maintenant un peu plus sur les caractéristiques des orchestrations. Leur composant central qui guide tout le processus s’appelle l’orchestrateur. Tous les ser-vices Web involucrés dans l’orchestration interagissent que avec l’orchestrateur et ja-mais entre eux. De la même façon, tout utilisateur de l’orchestration (qui normale-ment le fait à travers d’une application Web) interagisse avec l’orchestration que à travers l’orchestrateur. C’est pour ce raisons que l’orchestrateur joue une rôle très important dans l’orchestration, parce qu’il prend des décisions selon les réponses du Web services et les entrées de l’utilisateur. On considère les orchestrations comme un type particulier des systèmes à base des composants, où il y a un composant

tral (l’orchestrateur) qui interagisse avec l’environnement (l’utilisateur) et joue le rôle d’interface du système.

Contexte de Notre Travail

L

mais d’un point de vue particulier: en le testant dans son situation d’usage. Tester un système veut dire de l’exécuter pour trouver des erreurs. Cet ac-tivité exige une grande quantité du temps dans les entreprises (50-70%) [NS08], et cela provoque des délais dans les projets. Pourtant, l’activité du test doit être le plus automatique possible pour réduire le temps utilisé pour la faire. En plus, cela doit être fait de façon que cela assure, le plus possible, que le système après avoir être testé, fonctionne correctement (même si, comme l’on discute plus loin, on ne peut pas être sûr qu’il n’y aura pas des erreurs). Pour des systèmes où il ne peut pas y avoir des erreurs (comme c’est les cas pour les systèmes dans les trains, avions, etc.), on utilise l’aide des approches formels. Or, des modèles mathématiques sont utilisés pour représenter la spécification des systèmes (à la place des langages avec des ambiguïtés, comme par exemple, le français) et des techniques formelles sont utilisées pour tester l’implémentation de la spécification d’un système (le système mis au test, que dans notre cas est l’orchestrateur de l’orchestration). Cet façon de tester des systèmes en utilisant des modèles est connu comme test à base des modèles.

Une activité en relation directe avec le test à base de modèles est connue comme con-trôle des modèles.

Dans quelques mots, le contrôle des modèles est une activité automatique qui, donné le modèle d’un système et une propriété donnée dans une formalisme logique (en pra-tique, une variation de la logique temporelle), systématiquement vérifie si le modèle donné satisfait la propriété [Kat99]. Dans cet thèse, on ne fait pas des contrôle des modèles avec les modèles qu’on utilise. On suppose que les modèles sont correctes mais, dans le contexte d’un processus de validation et vérification complète, faire du contrôle des modèles est une activité complémentaire que doit être fait avec le travail présenté dans cet document.

En ce qui concerne le formalisme choisit pour représenter les spécifications, il y a plusieurs parmi lesquels ont peut choisir [LVD09], chacun en offrant différents avan-tages et désavanavan-tages. On peut mentionner quelques différents types des modèles

qui on été utilisées pour faire du test, comme les modèles à base des états (comme JML [L+_{99]), les modèles à base des transitions (comme FSM [LZCC07], LTS [Tre08]),} les modèles opérationnels (comme Petri Nets [YJC10]), parmi autres. Le modèle choisit dépends des caractéristiques du système qu’on veut capturer, aussi comme la familiarité qu’on a avec le modèle.

Tester un système veut dire d’interagir avec lui (selon les objectifs du test) pour dé-tecter des erreurs par rapport à sa spécification. Donc, à partir des modèles des sys-tèmes, on peut extraire ces objectifs de test qui le système soumis au test (SUT) doit respecter. Ceci est fait parce que c’est impossible de tester tous les comportements qui sont décrits par les modèles qui représentent les spécifications des systèmes (sauf pour des exemples triviales). Cet processus peut être très lent, même infini. Pour cela, les objectifs du test prennent en compte qu’un sous ensemble de tous les comportements possibles du système, et pourtant, l’activité du test ne peut pas être complète: peut importe l’approche utilisé, l’activité du test peut que détecter les erreurs, mais pas leur absence [Dij79].

Les objectifs du test sont sélectionnés pour tester des aspects spécifiques du système, selon le type du test qu’on veut réaliser. Parmi les types du test, on peut mentionner:

• Tester la vitesse du système (test de performance).

• Tester la réaction du système lorsque le nombre de requettes augment (test du stress).

• Tester la réaction du système lors des entrées erronées (test de robustesse). • Tester combien du temps on peut compter avec le correct comportement du

sys-tème (test du dépendance).

Dans ce document, on s’intéresse à tester si le SUT fait ce qu’il doit faire. Ce type du test est connu comme test de conformité et, plus spécifiquement, a comme bût de déterminer si le comportement d’un SUT est correcte par rapport à son spécification (qui est donnée sous la forme d’un modèle). La spécification sur laquelle on parle est une spécification des comportements du système, i.e., elle décrit le comportement du système en fonction des opérations qu’il peut effectuer. Dans le reste de ce document, lorsqu’on parle sur la spécification d’un système, on parle de son spécification des comportements.

pas connue, i.e., depuis le point de vue du testeur, le système est une boîte noire. Cela veut dire que, vu qu’on teste des systèmes d’information, le testeur n’a pas accès au code du SUT.

Pour le cas où le testeur a accès, l’activité du test est connue comme test au boîte blanche, et normalement a comme objectif d’assurer la couverture de différentes par-ties du code. Dans le test au boîte noire, lest tests sont obtenus entièrement à partir de la spécification du système (dans la pratique, en utilisant des objectifs du test) qui décrit les comportements attendus de la boîte noire [UL07].

Finalement, un système peut être testé à différent niveaux : • isolé (test unitaire),

• chaque composant est testé séparément (test de composants),

• le système est testé de manière que ses différents composants interagissent cor-rectement (test d’intégration),

• le système est testé lorsqu’il interagisse avec des autres systèmes (qui lui enfer-ment ou contient) (test en contexte),

• ou bien le système peut être testé dans sa totalité (test de systèmes).

Notre approche consiste donc à faire du test en contexte des orchestrateurs. Lors de tester des systèmes en contexte [Kho04], le (sous)système qu’on veut tester est encas-trédans le système en sa totalité et en train d’interagir avec des autres composants, qui constituent son contexte: le système dans sa totalité est composé du SUT et du reste des composants. Par rapport à ce contexte, il y a plusieurs hypothèses qui son faites. Las plus connues sont que les composants dans le contexte du SUT se comportent correctement, i.e., ils n’ont pas des erreurs parce qu’ils conforment par rapport à leur spécifications (qui sont supposées d’être disponibles), et que la communication parmi les composants marche correctement. En plus, normalement le SUT est testé que à travers son contexte [ACJY03].

Notre Approche

M

con-texte (des boîtes noires) pour déterminer si un orchestrateur se comporte cor-rectement selon sa spécification. Comme on a dit avant, les orchestrations

sont des types de systèmes avec des caractéristiques spéciales, où l’orchestrateur guide le processus. Ainsi, le système qui est soumis au test est composé de l’orchestrateur et les services Web (ou composants) qui interagissent avec lui. Ces services Web con-stituent le contexte de l’orchestrateur, et on a comme objectif de assurer la conformité de l’orchestrateur par rapport à son spécification lorsqu’il interagisse avec son con-texte. Pourtant, pour pouvoir appliquer un approche classique du test pour ce type de systèmes, on devrait prendre en compte la spécification de l’orchestrateur et de tous les services Web avec celui-ci interagisse.

En faisant cela, on peut obtenir une représentation formel de tout le système. Dû à qu’on utilise des modèles mathématiques pour représenter chaque spécification (de l’orchestrateur et de chaque service Web), la spécification de tout le système peut être obtenue en utilisant des manipulations mathématiques avec les modèles (comme le produit cartésien, etc.). Par contre, il peut y avoir deux problèmes en faisant cela: le premier est que la spécification de tous les composants (l’orchestrateur ou services Web) ne son pas toujours disponibles (et en plus dans une notation mathématique). Cela peut se produire, par exemple, car les services Web sont développés par des so-ciétés externes qui ne veulent pas donner des détails sur le comportement interne de leur produits.

Le deuxième problème est connu sous le nom de explosion combinatoire et est provo-qué parce que la combinaison de différents représentations formels de les spécifica-tions des composants qui forment partie du système peut donner comme résultat un modèle très grand, qui est difficile de manipuler.

Donc, la première hypothèse qu’on fait est que la spécification de l’orchestrateur est toujoursdisponible et, même si l’on travaille avec l’approche boîte noire, que le SUT peut être représenté par un modèle formel (que l’on peut obtenir, par exemple, en interagissant avec lui).

Pour attaquer les problèmes décrits précédemment (explosion combinatoire) et la non disponibilité des spécifications des services Web, on propose un approche qui consiste de tester les orchestrateurs en prenant en compte que leur spécifications mais pas celles de reste des composants dans le système, même si les orchestrateurs interagissent avec les services Web pendant qu’on les teste. Plus précisément, on prend en compte la description de l’interface des services Web, qui est normalement disponible sous la forme d’un fichier WSDL, mais qui décrit les servies d’un point de vue syntactique et ne décrit pas leur comportement (du point de vue sémantique).

et les services Weg W S1et W S2; et on veut déterminer si l’orchestrateur est conforme par rapport à son spécification lorsqu’il interagisse avec W S₁ et W S₂.

Figure 1: Teste de boîte noire basé sur modèles pour déterminer la conformité de l’orchestrateur

Dans cette thèse, en prenant en compte que la spécification de l’orchestrateur, on pro-pose un approche pour tester les orchestrateurs en utilisant la technique de test de boîte noire, basée sur des modèles, dans le cas particulier où les orchestrateurs inter-agissent avec le reste des services Web dans le système pendant qu’on les teste. Ceci représente une cas spéciale du test en contexte, où le testeur peut contrôler ou piloter l’orchestration en utilisant l’orchestrateur.

Ceci est précisément l’une des contributions de notre travail, parce que la plupart des travails qui on été fait pour tester des orchestrations et des systèmes à base de com-posants, simulent le contexte de l’orchestrateur, ou font l’hypothèse que les spécifi-cations de tous les services Web sont disponibles ( [CFCB10, LZCH08, BvdMFR06, vRT04]), mais, comme on a dit avant, ceci n’est pas toujours le cas. Aussi, on a choisit la relation de conformité ioco pour tester les orchestrateurs en contexte [Tre96]. ioco veut dire, en anglais, conformité des entrées/sorties, et son idée de base est que n’importe quel SUT est conforme par rapport à son spécification si, après toute séquence des interactions qui on été observés par le testeur en interagissant avec le SUT (et qui est valide selon la spécification, i.e., est spécifiée), n’importe quel ob-servation après cet séquence est aussi spécifiée. S’il y a une obob-servation faite par le testeur qui n’est pas spécifiée, donc on peut conclure que le système qui est soumis au test n’est pas conforme par rapport à son spécification.

Depuis l’année 1996, plusieurs travaux ont été basés sur cet relation de conformité [RBJ00, GGRT06,vdBRT04,FTW06], et a été aussi bien acceptée et utilisée dans des différents

domaines d’application (par exemple, en prenant en compte le temps [FT07]). En plus, cet relation de conformité a comme avantage le fait d’autoriser des spécifications non déterministes. En fait, ioco autorise des situations où il y a de la sous-spécification parce qu’elle ne force pas aux implémentations de considérer toutes les sorties possi-bles (depuis un état), mais seulement quelques unes. Par rapport aux entrées, si une entrée n’est pas spécifiée, n’importe quel observation faite dans le SUT après cet entrée est valide aussi.

En utilisant que la spécification de l’orchestrateur, on complément l’activité du test des orchestrateurs en prenant en compte un autre problème qui est commun lors de travailler avec des orchestrations: commet pouvons-nous être sûrs que les services Web qu’on choisit sont compatibles avec l’orchestrateur ? Dans cette thèse, on montre comment générer des comportements pour tester les services Web, et qui sont extraits de la spécification de l’orchestrateur. Ces comportements sont précisément les com-portements attendues pour les services Web de la part de l’orchestrateur. En plus, ces comportements extraits de la spécification de l’orchestrateur peuvent être vus comme une spécification partiel pour les services web. En fait, les services Web peuvent offrir plus des fonctionnalités que celles qui sont utilisées par l’orchestrateur. Dans notre approche, on choisit de ne prendre en compte tous les fonctionnalités qui ne son pas utilisées par l’orchestrateur et on se focalise seulement dans celles qui sont utilisées.

Donc, on propose un approche pour tester le comportement correcte des orchestrations en testant l’orchestrateur en contexte et en testant aussi la compatibilité des services Web, tout ça en prenant en compote que la spécification de l’orchestrateur. En procé-dant comme ça, on attaque deux problèmes communs à l’heure de tester des systèmes avec des plusieurs composants: la manque de la disponibilité des spécifications des composants et l’explosion combinatoire. En plus, on attaque cet dernier problème en utilisant l’exécution symbolique [Kin75, Cla76], qui a comme idée principale celle de exécuter des programmes en utilisant des symboles à la place de donnés concrets, et de générer une structure en forme d’arbre pour décrire tous les comportements possibles du programme d’un manière symbolique. En effet, dans notre approche, lest objectifs du tests sont des sous-arbres des arbres symboliques, et on utilise un algorithme pour tester la conformité du SUT qui est basé sur ces techniques symboliques.

C

partie théorique qui est la base de notre approche, ainsi comme l’état de l’art et l’introduction aux types des systèmes sur lesquels on travaille dans le reste de la thèse.

• Nous commençons au le Chapitre 2 en introduisant l’état de l’art par rapport aux types des systèmes que nous analysons: les orchestrations des services Web. Nous présentons les différentes façons de créer des compositions des services Web, les standards utilisés par les orchestrations et les systèmes à base des com-posants. Nous présentons aussi l’architecture SOA, qui est la base des orchestra-tions, et le langage le plus utilisé pour créer celles-ci: WS-BPEL (pour son nom en anglais Web Services Business Process Execution Language). Finalement, nous introduisons l’exemple que nous allons utiliser dans le reste de la thèse. • Dans le Chapitre 3 nous introduisons la relation de conformité que nous

util-isons: ioco. In introduise la notation que nous utilisons pour représenter les spé-cifications des systèmes: les systèmes à base des transitions étiquetées (LTS). Nous utilisons les LTSs pour modeler les spécifications des systèmes et les SUTs. Plus spécifiquement, nous utilisons les IOLTS, qui ne sont plus que des LTS où les étiquettes sont divisées entre entrées et sorties. Nous commençons par présenter les techniques utilisées pour tester des systèmes unitaires et après nous continuons avec les systèmes à base de composants. Plus spécifiquement, nous présentons les résultats obtenus dans [vdBRT03] lorsqu’ils utilisent la re-lation de conformité ioco avec des systèmes à base des composants. Finalement nous présentons aussi des autres travaux qui ont été faits pour tester des systèmes similaires.

• Nous continuons dans le Chapitre 4 en présentant la version modifiée de ioco et que nous définissons pour tester des orchestrateurs en contexte. Cette nouvelle relation de conformité nous permet de prendre en compte des informations par rapport au contexte des orchestrateurs, et on fait cela à partir des modifications sur les spécifications des orchestrateurs (qui sont représentées par des IOLTs). Ces modifications prennent en compte le statu des services Web qu’interagissent avec l’orchestrateur. Dans ce chapitre, on introduise une classification pour les différentes situations des services Web. Plus spécifiquement, nous classifions les canaux utilisés par les services Web et nous disons qu’un canal est:

– Contrôlable, si le testeur joue le rôle du service Web, ou bien s’il contrôle complètement les informations qui sont envoyés sur le canal.

– Observable, si le testeur ne contrôle pas les informations qui sont envoyés sur le canal, mais l’architecture du test est tel qu’il peut observer ces infor-mations.

– Caché, si le testeur ne peut ni observer ni contrôler les informations qui sont envoyés sur le canal.

La plus part du temps, lorsque nous travaillons avec des orchestrations, les ser-vices Web sont simulés, mais cela n’est pas toujours le cas. Donc, dans la suite du chapitre, on montre comment modifier les spécifications pour pren-dre en compte ces statu. Inspirés par les travaux dans [vdBRT03], on définit aussi un autre relation de conformité, qu’on utilise quand il y a des actions dans le SUT qui ne peuvent pas être vus par le testeur (à cause de l’architecture du test). Nous finissons le chapitre en présentant nos résultats dans la forme des deux théorèmes, qui ont été définis pour répondre la question suivante: s’il y a un erreur détecté lorsqu’on teste l’orchestrateur en contexte, quelles sont les hypothèses qui doivent être faites pour déterminer que l’erreur est dû à l’orchestrateur et pas à son contexte?.

• Nous finissons la Partie 1 avec le Chapitre 5, qui complètement le Chapitre 4, c’est à dire, nous définissons une relation de conformité qui peut être utilisé pour tester la compatibilité des services Web par rapport à comportements qui sont at-tendus de la part de l’orchestrateur. Pour faire cela, on génère les comportements attendus pour les services Web à partir de la spécification de l’orchestrateur, en utilisant des transformations mathématiques comme le miroir et la projection. Plus spécifiquement, si tous les services Web sont compatibles par rapport à l’orchestrateur (selon cet relation de compatibilité), alors il n’y aura pas des sit-uations de blocage mortel dans le système.

Dans la Partie II, nous montrons comment exploiter les résultats de la Partie 1, où les spécifications sont exprimés d’un manière concise en utilisant des systèmes à base des notations symboliques.

• Dans le Chapitre 6 nous introduisons les techniques d’exécution symboliques, commençant avec le formalisme symbolique que nous utilisons pour modeler les spécifications des orchestrateurs. Après, on présente l’exécution symbolique, qui consiste à exécuter un programme (dans ce cas, les spécifications des sys-tèmes) en utilisant des symboles à la place des données numériques. Le résultat est un arbre qui représente tous les comportements possibles du système.

• Dans le Chapitre 7, nous appliquons applique les techniques symboliques in-troduites dans le Chapitre 6 pour tester des orchestrateurs en contexte, c’est à dire, on adapte le Chapitre 4 en utilisant des techniques d’exécution symbol-iques. Dans ce chapitre on introduit aussi un algorithme basé sur des règles pour tester les orchestrateurs. Cet algorithme est basé dans la relation de conformité introduit dans le Chapitre 3 et est guidé par des objectifs du test. L’algorithme exécute essentiellement 3 actions:

1. il calcule les valeurs pour envoyer au SUT à chaque fois qu’il est nécessaire de le faire de la part du testeur et pour couvrir l’objectif du test,

2. il observe les réactions du SUT,

3. et il émet un verdict le plus tôt possible. En plus, l’algorithme émet des verdicts sur des comportements du système que sont dûs à des interactions avec les services Web.

• Dans le Chapitre 8 nous appliquons les techniques symboliques pour générer des comportements pour les services Web, c’est à dire, on adapte le Chapitre 5 dans l’optique symbolique. Nous montrons que les comportements qui sont générés (à partir des techniques de miroir et projection appliquées à des arbres symbol-iques) peuvent être utilisés pour déterminer si les services Web n’amènent pas à l’orchestration dans une situation de blocage mortel.

• Nous finissons la Partie 3 en présentant notre prototype, qui implémente l’algorithme à base des règles et qui permet de tester des orchestrations des services Web décrites dans WS-BPEL.

References

[ACJY03] R. Anido, A. Cavalli, L. Lima Jr., and N. Yevtushenko. Test suite min-imization for testing in context. Softw. Test., Verif. Reliab., 13(3):141– 155, 2003.

[BPSM+_{08] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau.} Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C, 2008. http://www.w3.org/TR/REC-xml/.

[BvdMFR06] N.C.W.M. Braspenning, J.M. van de Mortel-Fronczak, and J.E. Rooda. A Model-based Integration and Testing Method to Reduce System De-velopment Effort. Electronic Notes in Theoretical Computer Science, 164(4):13–28, 2006. Proc. of the Second Workshop on Model Based Testing (MBT 2006).

[CCMW01] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. WSDL (Version 1.1). W3C, March 2001. http://www.w3.org/TR/wsdl. [CFCB10] T.D. Cao, P. Félix, R. Castanet, and I. Berrada. Online Testing

Frame-work for Web Services. In Proceedings of the 2010 Third International Conference on Software Testing, Verification and Validation, ICST ’10, pages 363–372, Washington, DC, USA, 2010. IEEE Computer Society. [CHvRR04] L. Clement, A. Hately, C. von Riegen, and T. Rogers. UDDI (Version 3.0.2). OASIS, October 2004. http://www.oasis-

open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm.

[Cla76] L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215–222, 1976.

[Dij79] E. Dijkstra. Structured programming. pages 41–48, 1979.

[EGGC09a] J.P. Escobedo, P. Le Gall, C. Gaston, and A. Cavalli. Exam-ples of testing scenarios for web service composition. Techni-cal Report 09003_LOR, TELECOM & Management SudParis, 2009. http://www.it-sudparis.eu/.

[EGGC09b] J.P. Escobedo, P. Le Gall, C. Gaston, and A. Cavalli. Observability and controllability issues in conformance testing of web service com-position. In Testing of Communicating Systems and Formal Approaches to Software Testing (TESTCOM/FATES), volume 5826 of LNCS, pages 217–222. Springer, 2009.

[EGGC10] J.P. Escobedo, P. Le Gall, C. Gaston, and A. Cavalli. Testing web ser-vice orchestrators in context:a symbolic approach. In Proc. of Soft-ware Engineering Formal Methods (SEFM) ’10. IEEE Computer Soci-ety, 2010.

[FGM+_{99] R. T. Fielding, J. Gettys, J. C. Mogul, H. Nielsen, L. Masinter,} P. Leach, and T. Berners-Lee. RFC 2616: Hypertext Transfer Proto-col – HTTP/1.1, 1999. http://tools.ietf.org/html/rfc2616.

[FT07] L. Frantzen and J. Tretmans. Model-Based Testing of Environmental Conformance of Components. In Formal Methods of Components and Objects (FMCO), number 4709 in LNCS, pages 1–25, 2007.

[FTW06] L. Frantzen, J. Tretmans, and T.A.C. Willemse. A Symbolic Framework for Model-Based Testing. In Intl. Workshops FATES/RV, volume 4262 of LNCS, pages 40–54, 2006.

[GGRT06] C. Gaston, P. Le Gall, N. Rapin, and A. Touil. Symbolic Execution Techniques for Test Purpose Definition. In Testing of Communicating Systems (TESTCOM), volume 3964 of LNCS, pages 1–18, 2006. [GHM+_{07] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. Nielsen,}

A. Karmarkar, and Y. Lafon. SOAP (Version 1.2). W3C, April 2007. http://www.w3.org/TR/soap12-part1/.

[GJW04] J. Gortmaker, M. Janssen, and R. Wagenaar. The advantages of web service orchestration in perspective. In ICEC ’04: Proceedings of the 6th international conference on Electronic commerce, pages 506–515, New York, NY, USA, 2004. ACM.

[HS05] M. Huhns and M. Singh. Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing, 9(1):75–81, 2005.

[Kat99] J.-P. Katoen. Concepts, Algorithms, and Tools for Model Checking, 1999.

[Kho04] A. Khoumsi. Test cases generation for embedded systems, 2004. [Kin75] J. C. King. A new approach to program testing. In Intl. Conf. on

Reli-able Software, pages 228–233. ACM, 1975.

[L+_{99] G. Leavens et al. The Java Modeling Language (JML). 1999.} http://www.eecs.ucf.edu/ leavens/JML/.

[LVD09] N. Lohmann, E. Verbeek, and R. Dijkman. Petri net transformations for business processes — a survey. pages 46–63, 2009.

[LZCC07] M. Lallali, F. Zaïdi, C., and Cavalli. Timed modeling of web ser-vices composition for automatic testing. In SITIS ’07: Proceedings of the 2007 Third International IEEE Conference on Signal-Image Tech-nologies and Internet-Based System, pages 417–426, Washington, DC, USA, 2007. IEEE Computer Society.

[LZCH08] M. Lallali, F. Zaïdi, A. Cavalli, and I. Hwang. Automatic timed test case generation for web services composition. European Conference on Web Services (ECOWS), 0:53–62, 2008.

[MKB09] S. Mitra, R. Kumar, and S. Basu. A Framework for Optimal Decentral-ized Service-Choreography. In ICWS, pages 493–500, 2009.

[NS08] S. Noikajana and T. Suwannasart. Web Service Test Case Generation Based on Decision Table (Short Paper). In QSIC ’08: Proceedings of the 2008 The Eighth International Conference on Quality Software, pages 321–326, Washington, DC, USA, 2008. IEEE Computer Society. [Pel03] C. Peltz. Web services orchestration and choreography. In Computer,

pages 46–52. IEEE Computer Society, 2003.

[RBJ00] V. Rusu, L. Bousquet, and T. Jéron. An Approach to Symbolic Test Generation. In IFM ’00: Proceedings of the Second International Con-ference on Integrated Formal Methods, pages 338–357, London, UK, 2000. Springer-Verlag.

[Tre96] J. Tretmans. Test generation with inputs, outputs and repetitive quies-cence. Software - Concepts and Tools, 17(3):103–120, 1996.

[Tre08] Jan Tretmans. Formal methods and testing. In Robert M. Hierons, Jonathan P. Bowen, and Mark Harman, editors, Formal Methods and Testing, pages 1–38, Berlin, Heidelberg, 2008. Springer-Verlag. [UL07] M. Utting and B. Legeard. Practical Model-Based Testing: A Tools

Approach. Morgan Kaufmann, 1 edition, 2007.

[vBK06] F. van Breugel and M. Koshkina. Models and Verification of BPEL, 2006.

[vdBRT03] H.M. van der Bijl, A. Rensink, and J. Tretmans. Component based testing with ioco, 2003.

[vdBRT04] M. van der Bijl, A. Rensink, and J. Tretmans. Compositional testing with ioco. In Workshop on Formal Approaches to Testing of Software (FATES), volume 2931 of LNCS, pages 86–100, 2004.

[vRT04] H.M. van der Bijl, A. Rensink, and G.J. Tretmans. Compositional test-ing with ioco. In A. Petrenko and A. Ulrich, editors, Formal Approaches to Software Testing (FATES), volume 2931 of LNCS, pages 86–100, Berlin, 2004. Springer Verlag.

[YJC10] T. Yoo, B. Jeong, and H. Cho. A Petri Nets based functional validation for services composition. Expert Syst. Appl., 37(5):3768–3776, 2010.

IOST S IOST S

IOST S IOST S IOLT S

LT S LT S IOLT S G G_δ IOLT S SU T τ Orch Rem Orch[Rem] IT (Orch) IOST S IOST S IOLT S GLT S IOST S SE(G) IOST S SE(G)δ

τ SE(Orch)δ SE(Orch) IT (Orch) SE(Orch)δ HO(Orch) SE(Orch)δ SE(Orch) T P Obs(Orch) Accept(T P ) = η5 ev w IOST S Orch SE(Orch) SE(Orch)δ HO(Orch) Obs(Orch) W S.IN CON C W S.HY P.F AIL Orch SE(Orch) HO(Orch)

τ P ASS F AIL IN CON C P ASS W eakP ASS

W

•

•

•

•

•

•

•

•

•

•

user

user orchestrator

Comp1 Comp2 Comp3

q0

q1 d

d a f

IOST S

LT S IOST S

IOST S

IOST S IOST S

T

LT S IOLT S LT S IOLT S LT S IOLT S LT S IOLT S LT S LT S SU T SU T SU T LT S τ LT S

LT S L LT S L (Q, init, T r) • Q • init ∈ Q • T r ⊆ Q × L × Q LT S G = (Q, init, T r) L QG initG T rG Q init T r tr ∈ T rG (q, a, q0)

source(tr) target(tr) act(tr) q q0 _a LT S → LT S LT S {q0, q1, q2, q3} q0

q0−−−→ qtoken 1 q1−−→ qseed 2 LT S LT S IOLT S LT S S S∗ S ε a S m S∗ a.m S∗ a.ε a G _L G = (Q, init, T r) LT S L G _{P ath(G) ⊆ T r}∗ target(p)

• ε P ath(G) target(ε) initG

• p ∈ P ath(G) tr ∈ T r p.tr ∈ P ath(G) target(p) = source(tr) target(p.tr) = target(tr)

LT S

LT S q0 q3

q3 q0

LT S τ LT S G _L G LT S L G _{T races(G) L}∗

{traces(p) | p ∈ P ath(G)} traces(p) • p ε traces(p) = ε

• p p0_{.tr act(tr) = τ traces(p) traces(p}0₎

• p p0.tr act(tr) 6= τ traces(p) traces(p0).act(tr)

(q0, token, q1) (q1, seed, q2) (q2, sequence, q3) (q3, win, q0)

q0 q3 q3 q0

win token seed sequence win

! ? L LI LU

LI LU ?a !a LT S q0 −−−−→ q?token 1 q2 ?sequence −−−−−−→ q3

q1−−−→ q!seed 2 q3−−−→ q!win 0 q3−−−→ q!lose 0

c?v c!v v c M C C Act(C, M ) I(C, M ) ∪ O(C, M ) ∪ {τ } • I(C, M ) c?v c ∈ C v ∈ M • O(C, M ) c!v c ∈ C v ∈ M IOLT S IOT S IOLT S C IOLT S C Act(C, M )

IOLT S G IOLT S LT S LT S IOLT S IOLT S G = (Q, init, T r) C QG initG T rG Q init T r tr ∈ T rG (q, a, q0)

source(tr) target(tr) act(tr) q q0

a

IOLT S G

{u start sg generate sg sequence u screen}

u start u screen

sg generate sg sequence

M {token seed sequence win lose}

{(u start?token) (sg generate!seed) (sg sequence?sequence) (u screen!win) (u screen!lose)}

G

IOLT S τ

G_δ IOLT S G _C G _{IOLT S C} G _{LT S} G_δ Act(C, M ) ∪ {δ} • QG_δ = QG • initG_δ = initG • T rG_δ = T rG∪ T r_δ T r_δ q ∈ QG_δ (q, δ, q) ∈ T r_δ (q, act, q0) ∈ T rG act τ c!v IOLT S IOLT S IOLT S G G _q0 q2 τ q1

IOLT S δ IOLT S IOLT S IOLT S τ IOLT S G = (Q, init, T r) IOLT S C

Live(G) P ath(G) p ∈ Live(G) ∃ tr ∈ T r act(tr) ∈ O(C, M ) ∪ {τ } p.tr ∈ Live(G)

G _{Live(G) = ∅} IOLT S τ q1 q1 τ IOLT S IOLT S IOLT S IOLT S IOLT S

IOLT S G _{IOLT S C} G _{ST races(G) T races(Gδ)} G _{ST races(G)} IOLT S G_{δ q0} q3 q0

δ∗_{u start?token sg generate!seed δ}∗_{sg sequence?sequence u screen!win}

SU T SU T IOLT S SU T IOLT S IOLT S I(C, M ) IOLT S G IOLT S C G _{IOLT S q ∈ Q}G a ∈ I(C, M ) tr ∈ T rG (q, a, q0) IOLT S SU T IOLT S IOLT S SU T IOLT S SU T IOLT S τ SU T SU T SU T SU T

SU T τ SU T C IOLT S ∀tr ∈ T rSU T, act(tr) 6= τ SU T {c} M = {a, b} SU T q1 b τ IOLT S G _{IOLT S SU T} C

SU T G _{∀σ ∈ ST races(G) ∀o ∈ O(C, M )∪{δ}} σ.o ∈ T races(SU T ) ⇒ σ.o ∈ ST races(G)

SU T G SU T SU T G SU T IOLT S Gδ i1 G_δ i₁ i₁ i₂ G_δ

i1 i2

i3

i₂

i₃ G_δ

u screen?1.sg generate!6.sg sequence?4 u screen!error

IOLT S G H

IOLT S C1 C2 G H

G N H _{IOLT S (Q, init, T r) C1∪ C2} • Q = QG× QH

• init = (initG, initH)

• T r (q1, c!v, q01) ∈ T rG (q2, c?v, q20) ∈ T rH c ∈ C1∩ C2 ((q1, q2), c!v, (q10, q20)) ∈ T r (q1, c?v, q01) ∈ T rG (q2, c!v, q20) ∈ T rH c ∈ C1∩ C2 ((q1, q2), c!v, (q10, q20)) ∈ T r (q1, a, q01) ∈ T rG a τ c?v c!v c /∈ C1∩ C2 q2∈ QH ((q1, q2), a, (q10, q2)) ∈ T r (q1, a, q01) ∈ T rH a τ c?v c!v c /∈ C1∩ C2 q2∈ QG ((q1, q2), a, (q01, q2)) ∈ T r IOLT S • • IOLT S G F G F IOLT S IOLT S GNF (q0, u start?token, q1) G F (q1, sg generate!seed, q2) G F (q0 0, sg generate?seed, q01)

IOLT S G F GN F τ F _(q0 1, τ, q20) G (q2, sg sequence?sequence, q3) G F (q0 2, sg sequence!sequence, q00) (q3, u screen!lose, q0) (q3, u screen!win, q0) G F IOLT S IOLT S IOLT S IOLT S τ

IOLT S IOLT S IOLT S G = (Q, init, T r) IOLT S C C ⊆ C Hide(C, G) IOLT S C \ C • QHide(C,G)= QG

• init_Hide(C,G)= initG

• T r_Hide(C,G) (q, a, q0_{) ∈ T r} G a c4v 4 ∈ {?, !} c ∈ C (q, τ, q0) ∈ T rHide(C,G) (q, a, q0) ∈ T rG a c4v 4 ∈ {?, !} c /∈ C a = τ (q, a, q0_{) ∈ T r} Hide(C,G) IOLT S G N F C = {sg generate, sg sequence} τ

IOLT S IOLT S S₁ S_{2 IOLT S C1 C2} I₁ I_{2 SU T C1 C2} I₁ S_{1∧ I2} S_{2 ⇒ I1}NI₂ S₁NS₂ IOLT S S _{IOLT S C} I SU T C C ⊆ C I _{S ⇒ Hide(C, I) Hide(C, S)} IOLT S

s₁ s₂ s₁Ns₂ i₁ i₂ s₁ s₂ i₁Ni₂ i₁ s₁ i₂ s₂ i₁Ni₂ s₁Ns_{2 c!x} i₁Ni_{2 c!x} c!x s₁Ns₂ s_{2 x} s₁Ns₂ s_{1 x s1 c?x q1} i_{1 c?x} x s

i _{{c1?a} {c1!x, c1!y, c2!z}}

i s

c2 s i Hide({c2}, s) Hide({c2}, i)

Hide({c2}, i) Hide({c2}, s) Hide({c2}, i)

c1!y c1?a Hide({c2}, s) s _{c1?a q2 c2!z} c2!z.c1?a c1!y c2!z.c1?a c2 c2!z.c1?a c1?a Hide({c2}, s) c1?a δ Hide({c2}, i) c1!y U T races ST races

G G _{IOLT S C} G _{U T races(G)} σ ∈ ST races(G) p p1 Gδ • σ σ1.a.σ2 a ∈ I(C, M ) • σ p • σ1 p1 • tr ∈ T rG_δ source(tr) = target(p1) σ1.a p1.tr U T races G _IOLT SU T C

SU T G _{∀σ ∈ U T races(G) ∀o ∈ O(C, M )∪{δ}} σ.o ∈ T races(SU T ) ⇒ σ.o ∈ ST races(G)

IOLT S

S₁ S_{2 IOLT S C1 C2} I₁ I_{2 SU T C1 C2}

I₁ S_{1 ∧ I2} S_{2 ⇒ I1}NI₂ S₁NI₂

LT S

IOLT S

U T races LT S

IOLT S

SU T

LT S

IOLT S LT S

IOLT S

I

(b) (b.1) (b.2) IOLT S SU T Orch

W S1 W S2 Orch

user

Orch W S1 W S2

Rem Orch

Orch

Orch Rem Orch[Rem]

Orch Rem IOLT S Orch Rem

Orch

Rem Orch

Rem LT S Orch[Rem]

Rem Orch Orch

Orch[Rem] Orch Orch Rem

Rem

Orch

Orch Rem

IOLT S Orch Rem W S1 W S2 W S1 W S2 W S1 W S2 Rem W S2 W S2 Rem W S2 C Orch Cc Ch Co Ch

Orch Rem Orch[Rem] Orch[Rem] Ch Co Cc Orch[Rem] Obs(Orch[Rem], Co) Orch[Rem] Co Cc Obs(Orch[Rem], Co) Orch

Orch Orch Rem

Obs(Orch[Rem], Co) Orch IOLT S Orch Obs(Orch[Rem], Co) Orch Rem Obs(Orch) Orch[Rem] Orch Rem Orch[Rem] Orch Orch[Rem] Rem Orch Rem Orch c?t c Rem c!t Ch

SU T Obs(Orch[Rem], Co) Obs(Orch) Obs(Orch[Rem], Co) Orch Orch[Rem] Obs(Orch[Rem], Co) IOLT S c?v c!v τ c!v c Orch Rem Orch δ[c1, . . . , cn] c1, . . . , cn {c1, . . . , cn} IOLT S C Cr⊆ C IOLT S C Cr LT S G Act(C, M ) ∪ Int(Cr, M ) ∪ ∆(Cr) • Int(Cr, M ) c!v c ∈ Cr v ∈ M • ∆(Cr) δ[w] w ∈ Cr∗ IOLT S

IOLT S IOLT S

IOLT S

Act(C, M ) ∪ Int(Cr, M ) ∪ ∆(Cr) IntG ∆G

Int(Cr, M ) ∆(Cr) δ[] δ IOLT S IOLT S C Cr ⊆ C G _{IOLT S C Cr} C ⊆ Cr Hide(C, G) IOLT S C \ C Cr\ C • QHide(C,G)= QG

• initHide(C,G)= initG

• T r_Hide(C,G) (q, a, q0_{) ∈ T r} G a c4v c4v 4 ∈ {?, !} c ∈ C (q, τ, q0) ∈ T rHide(C,G) (q, a, q0) ∈ T rG a c4v c4v 4 ∈ {?, !} c /∈ C a = τ a ∈ ∆G (q, a, q0) ∈ T r_Hide(C,G) Orch SU T Cr C Orch SU T Rem Orch Orch Rem SU T IOLT S τ

Orch Rem Orch SU T C Cr ⊆ C Rem SU T Cr

Orch Rem IOLT S C Orch[Rem] Cr

• Q_Orch[Rem]= QOrch× QRem

• init_Orch[Rem] = (initOrch, initRem)

• T rOrch[Rem] (q1, c!v, q10) ∈ T rOrch (q2, c?v, q20) ∈ T rRem ((q1, q2), c!v, (q10, q20)) ∈ T rOrch[Rem] (q1, c?v, q10) ∈ T rOrch (q2, c!v, q20) ∈ T rRem ((q1, q2), c!v, (q10, q20)) ∈ T rOrch[Rem] (q1, a, q10) ∈ T rOrch a τ c?v c!v c /∈ Cr q2∈ QRem ((q1, q2), a, (q10, q2)) ∈ T rOrch[Rem] (q1, δ, q1) ∈ T rOrch (q2, δ, q2) ∈ T rRem ((q1, q2), δ, (q1, q2)) ∈ T rOrch[Rem] Orch Rem Orch Rem Orch Orch Orch c!v Orch Rem Orch[Rem] Orch Rem SU T Orch Rem Orch[Rem] Orch Rem Orch Rem SU T Orch Rem Orch[Rem] Rem

Orch Rem Orch Rem Orch Rem Rem Orch Orch[Rem] S C Ch Co Cc • C = Co∪ Ch∪ Cc • Co∩ Ch= Ch∩ Cc= Co∩ Cc= ∅ Co C Ch C Cc C Cr= Co∪ Ch

Orch[Rem] Cc Orch[Rem] Co Ch C Ch Co Cc Orch[Rem]

Orch Rem Orch SU T C Rem SU T Cr

Orch[Rem] Co

Obs(Orch[Rem], Co) Hide(Ch, Orch[Rem])

Orch[Rem] Co = ∅ Ch = {sg generate sg sequence sg error}

τ τ SU T SU T τ SU T IOLT S τ τ τ Orch Rem C Cr Orch[Rem] C \ Cr C \ Cr = Cc Orch[Rem] Orch Rem C Orch Cc, Ch Co Orch Cr = Co∪ Ch

Orch IOLT S C Orch IOLT S Cr Orchδi • QOrch_δi = QOrch∪ Qδ • initO_rch δi = initOrch • T rO_rch δi = T rOrch∪ T rδ Qδ T rδ q ∈ QOrch (q, act, q0) ∈ T rOrch act τ c!v (q, c?v, q0) ∈ T rOrch c ∈ Cr {c1, · · · , cn} Cr (q, cj?v, qj) ∈ T rO_rch 1 ≤ j ≤ n qδ ∈ Qδ (q, δ[c1· · · cn], qδ) ∈ T rδ (qδ, δ[c1· · · cn], qδ) ∈ T rδ (q, c?v, q0_{) ∈ T r} O_rch c /∈ Cr (qδ, c?v, q0) ∈ T rδ IOLT S IOLT S IOST S IOLT S

c1∈ C/ r c2∈ Cr IOLT S q qδ c2 qδ v c1 qδ q1 IOLT S q v c Orch IOLT S C Orch Cr IOLT S C Cr Orchδf • QO_rch δf = QOrchδi • initO_rch δf = initOrch • T rOrch_δf = T rOrch_δi ∪ T rδe T rδe q ∈ QO_rch (q, δ[], q) ∈ T r_δe

(q, act, q0) ∈ T rOrch act τ act act

c?v c ∈ Cr

δ δ[]

c?v c ∈ Cr

G _{IOLT S C} G _{IOLT S C} Cr G∆ • QG_∆ = QG∪ Qδ • initG_∆ = initG • T rG_∆ = T rG∪ T r_δ Qδ T rδ q ∈ QG (q, act, q0) ∈ T rG act τ c!v Cq {c ∈ Cr | ∃ (q, c?v, q0) ∈ T rG} Cq {c1, . . . , cn} m c1· · · cn Cq ε qδ ∈ Qδ (q, δ[m], qδ) ∈ T rδ (qδ, δ[m], qδ) ∈ T rδ (q, c?v, q0) ∈ T rG c /∈ Cr (qδ, c?v, q0) ∈ T rδ δ δ[] IOLT S IOST S

• IOLT S q q0 q1 cu C \ Cr • IOLT S q IOLT S cu∈ C \ Cr • IOLT S IOST S q τ c!v m IOLT S m cu ∈ C/ r cu ∈ C/ r qδ cu?v δ[c1 · · · cn] δ[] δ δ δ[c1· · · cn] δ[c1· · · cn] δ IOLT S δ[c1· · · cn] δ tr = (q, δ[c1· · · cn], q0) act(tr) δ[c1· · · cn] δ Orch Rem

IT (Orch) Orch Orch IOLT S C Orch IOLT S Cr IT (Orch) • Q_{IT (Orch)}= QOrch_δf

• initIT (Orch)= initO_rch

δf • T rIT (Orch) tr ∈ T rO_rch δf tr (q, c?v, q0_{) c ∈ C} r (q, c!v, q0) ∈ T rIT (Orch) tr (q, a, q0_{) a c?v c ∈ C} r (q, a, q0) ∈ T rIT (Orch) G_∆ Orchδf Co = {sg generate, sg sequence} Orch Orch Obs(Orch) Ch IOLT S IT (Orch)

Orch Rem Orch IOLT S C Orch[Rem] Co Obs(Orch) Hide(Ch, IT (Orch)) Obs(Orch) IOLT S Ch = {sg generate, sg sequence} Obs(Orch[Rem], Co) Obs(Orch) IOLT S

I OLT S

IOLT S

G₁ G_{2 IOLT S C} Cr

G₂ G_{1 ∀σ ∈ T races(G1) ∀o ∈ O(C, M ) ∪ {δ}} σ.o ∈ T races(G2) ⇒ σ.o ∈ T races(G1)

G₂ U T races IOLT S G _{IOLT S Cr} G _{U T races(G)} σ ∈ T races(G) p p1 G • σ σ1.a.σ2 a c?v c!v • σ p • σ1 p1 • tr ∈ T rG source(tr) = target(p₁) σ₁.a p₁.tr G₁ G_{2 IOLT S C} Cr

G₂ G_{1 ∀σ ∈ U T races(G1) ∀o ∈ O(C, M ) ∪ {δ}} σ.o ∈ T races(G2) ⇒ σ.o ∈ T races(G1)

Orch Rem

Orch[Rem] Orch Orch

Orch[Rem] IT (Orch)

Orch Orch Orch[Rem] Orch[Rem]

Orch[Rem] Orch[Rem] IT (Orch) Orch

Rem Orch Orch

Orch IOLT S C Orch Rem

SU T C Cr

Orch Orch ⇒ Orch[Rem] IT (Orch)

IOSLT S

C M

Act(C, M ) = Act(C, M ) ∪ Int(Cr, M ) Act ⊆ (Act(C, M ) ∪ {δ})g ∗

Act(C, M ) σ ∈ gAct

σ1.a.σ2 σ a c!v σ1

σ0.b b 6= δ

Cr C Ext : gAct → (Act(C, M ) ∪ {δ})∗

Ext(ε) = ε σ.a ∈ gAct

• a c?v c!v δ Ext(σ.a) Ext(σ).a • a c!v Ext(σ.a) Ext(σ).c?v

Ext

σ0 _{σ.a σ}00 Ext(σ00) = σ σ000 Ext(σ000_{) = σ}0 _σ000 _σ00_{.b b c!v a} c?v c ∈ Cr b a σ0 _σ 1.δ.c?a c ∈ Cr σ000 Ext(σ000) = σ0 σ0 Actg ¤ Orch Rem SU T C Cr

ExtP ath : P ath(Orch[Rem]) → P ath(Orch) • p ε ExtP ath(p) ε

• p pp.tr tr ((q1, q2), a, (q01, q20))

ExtP ath(pp.tr) = ExtP ath(pp).tr0 tr0 = (q1, c?v, q2)

c!v tr0 (q1, a, q2)

σ ∈ T races(Orch[Rem]) p ∈ P ath(Orch[Rem]) σ = traces(p) Ext(σ) = traces(ExtP ath(p))

σ σ ε p τ ExtP ath(p) τ traces(ExtP ath(p)) ε σ ε Ext(σ) = ε p σ ∈ traces(p) Ext(σ) = traces(ExtP ath(p))

σ σ0_{.a σ = traces(p) p}

pp.tr.ps traces(pp) = σ0 act(tr) = a ps

τ

(H) Ext(σ0_{) = traces(ExtP ath(p} p))

a a c!v Ext(σ) = Ext(σ0_{).c?v ExtP ath(p}0_.tr)

ExtP ath(p0).tr0 tr0 act(tr0) =

c?v (H) Ext(σ) =

traces(ExtP ath(pp.tr)) ps

τ

Ext(σ) = traces(ExtP ath(pp.tr.ps)) Ext(σ) =

traces(ExtP ath(p))

b a c!v Ext(σ) = Ext(σ0).a ExtP ath(p0.tr) ExtP ath(p0).tr0 tr0 act(tr0) = a

a ¤ Orch[Rem] Orch Orch Rem SU T C Cr σ ∈ gAct

σ ∈ T races(Orch[Rem]) ⇒ Ext(σ) ∈ T races(Orch)

σ ∈ gAct σ ∈ T races(Orch[Rem]) p0_{∈ P ath(Orch) Ext(σ) = traces(p}0₎

σ ∈ T races(Orch[Rem]) p ∈ P ath(Orch[Rem])

σ = traces(p) Ext(σ) =

traces(ExtP ath(p)) p0 ExtP ath(p)

¤ ExtP ath

IOLT S Orch C ExtP athS : P ath(IT (Orch)) → P ath(Orchδ)

• ExtP athS(ε) = ε

• ExtP athS(p.(q, act, q0)) act τ c?v c!v

ExtP athS(p).(target(ExtP athS(p)), act(tr), target(tr))

• ExtP athS(p.(q, act, q0)) act c!v

ExtP athS(p).(target(ExtP athS(p)), c?v, target(tr))

• ExtP athS(p.(q, act, q0)) act δ

ExtP athS ExtP ath δ IT (Orch) • q q Orchδ qδ • qδ Orchδ (q, δ, q) Orchδ

Ext(gAct) Act(C, M )∗ σ ∈ Ext(gAct) ∃σ0 _{∈ gAct σ = Ext(σ}0₎

^

ExtP athS: P ath(IT (Orch)) → {p ∈ P ath(Orch) | traces(p) ∈ Ext(gAct)}

^ ExtP athS

p = t1· · · tn {p ∈ P ath(Orch) | traces(p) ∈ Ext(gAct)}

p0 = t0₁· · · t0

n P ath(IT (Orch)) ExtP athS(p0) = p

p0 • trl· · · trm p i ∈ [l, · · · , m[ act(tri) δ act(trm) c?v tr0 l· · · trm0 tr0 l· · · tr0m−1 trl· · · trm−1 tr0_l= · · · = trm−10 trl = · · · = trm−1 trm0 trm c C \ Cr

i ∈ [l, · · · , m[ act(tr0_i) δ source(tr_l0) = source(trl)

target(tr0

l) source(trl)δ

j ∈]l, · · · m[ source(tr0_j) = target(tr_j0) = source(trl)δ

source(tr0

m) = source(trl)δ target(tr0m) = target(trm) act(trm0 )

act(trm) c C \ Cr • k ≤ n tr0_k tr0 k trk act(trk) c?v c ∈ Cr trk0 (source(trk), c!v, target(trk)) ¤

σ ∈ T races(IT (Orch)) p ∈ P ath(IT (Orch)) σ = traces(p) Ext(σ) = traces(ExtP ath^ S(p))

σ σ ε p

τ ExtP ath^ S(p)

τ traces(ExtP ath^ S(p)) ε σ

ε Ext(σ) = ε p σ ∈ traces(p) Ext(σ) = traces(ExtP ath^ S(p))

σ σ0.a σ = traces(p) p pp.tr.ps traces(pp) = σ0 act(tr) = a ps

τ

(H) Ext(σ0_{) = traces(ExtP ath}^ S(pp))

a

a a c!v Ext(σ) = Ext(σ0).c?v ^

ExtP athS(p0.tr) ExtP ath^ S(p0).tr0 tr0

act(tr0_{) = c?v (H)}

Ext(σ) = traces(ExtP ath^ S(pp.tr)) ps

τ

Ext(σ) = traces(ExtP ath^ S(pp.tr.ps))

Ext(σ) = traces(ExtP ath^ S(p))

b a c!v

• a δ Ext(σ) = Ext(σ0).δ ^

ExtP athS(p0.tr) ExtP ath^ S(p0).tr0 tr0

act(tr0_{) = δ}

a

• a δ Ext(σ) = Ext(σ0).a ^

ExtP athS(p0.tr) ExtP ath^ S(p0).tr0 tr0

act(tr0_{) = a}

a

¤ σ ∈ gAct

Ext(σ) ∈ ST races(Orch) p Orch Ext(σ) = traces(p) p ∈ {p ∈ P ath(Orch) | traces(p) ∈ Ext(gAct)}

^

ExtP athS p0∈ P ath(IT (Orch))

^

ExtP athS(p0) = p

Ext(traces(p0)) = traces(ExtP ath^ S(p0))

^

ExtP athS(p0) = p Ext(σ) = traces(p)

Ext(traces(p0)) = Ext(σ) Ext

traces(p0) = σ σ ∈ T races(IT (Orch))

¤

Orch ioco Orch ⇒ Orch[Rem] ioco IT (Orch)

(1) Orch ioco Orch

(2) ∀σ ∈ ST races(Orch) ∀o ∈ O(C, M ) ∪ {δ}

σ.o ∈ T races(Orch) =⇒ σ.o ∈ ST races(Orch)

(3) ∀σ ∈ gAct

σ ∈ T races(Orch[Rem]) ⇒ Ext(σ) ∈ T races(Orch) (3)

(4) ∀σ ∈ gAct ∀o ∈ O(C, M ) ∪ {δ}

σ.o ∈ T races(Orch[Rem]) ⇒ Ext(σ.o) ∈ T races(Orch) Ext(σ.o) = Ext(σ).Ext(o) (4)

(5) ∀σ ∈ gAct ∀o ∈ O(C, M ) ∪ {δ}

Ext(o) ∈ O(C, M ) ∪ {δ} Ext(o) = o (2) (5)

(6) ∀σ ∈ gAct ∀o ∈ O(C, M ) ∪ {δ}

σ.o ∈ T races(Orch[Rem]) ⇒ Ext(σ).Ext(o) ∈ ST races(Orch) IT (Orch) Actg (6)

(7) ∀σ ∈ T races(IT (Orch)) ∀o ∈ O(C, M ) ∪ {δ}

σ.o ∈ T races(Orch[Rem]) ⇒ Ext(σ).Ext(o) ∈ ST races(Orch) Ext(σ.o) = Ext(σ).Ext(o) (7)

(8) ∀σ ∈ T races(IT (Orch)) ∀o ∈ O(C, M ) ∪ {δ}

σ.o ∈ T race(Orch[Rem]) ⇒ Ext(σ.o) ∈ ST races(Orch)

(9) σ ∈ T races(IT (Orch))

Ext(σ.o) ∈ ST races(Orch) ⇒ σ.o ∈ T races(IT (Orch)) (8) (9)

∀σ ∈ T races(IT (Orch)) ∀o ∈ O(C, M ) ∪ {δ}

σ.o ∈ T races(Orch[Rem]) ⇒ σ.o ∈ T races(IT (Orch))

¤

Ch IOLT S

Orch Ch q ∈ QOrch

Orch IOLT S C Ch

Orch Rem SU T C Cr

Orch Orch ⇒ Obs(Orch[Rem], Co) Obs(Orch)

Orch ioco Orch ⇒ Orch[Rem] ioco IT (Orch)

Orch Ch

Orch ioco Orch ⇒ Obs(Orch[Rem], Co) uioco Obs(Orch)

IT (Orch) Orch[Rem] σ ∈ T races(IT (Orch) T races(Orch[Rem]) UCh(σ)

U (σ) • σ = ε U (σ) = ε • σ = σ0.a a c!t c!t c ∈ Ch U (σ) = U (σ0) U (σ) = U (σ0_).a UOrch UOrch Orch[Rem] IT (Orch) Ch τ IT (Orch) Orch Ch σ.o T races(Obs(Orch[Rem], Co)) o σ U T races(Obs(Orch)) pO σ U (traces(p O σ)) = σ κ Orch[Rem] U (κ) = σ.o o κ κ0_.o σ.o Obs(Orch[Rem], Co) ρ IT (Orch)

P athOrch(ρ) = {p ∈ P ath(IT (Orch)) | traces(p) = ρ}

ρ σ σ ρ.π P athOrch(ρ)

ρ µ.a P athG(µ) pµ traces(pµ) = µ a a a c!t IT (Orch) Ch P athO_rch(µ) µ.a P athOrch(ρ)

b a c!t Orch[Rem] ioco IT (Orch µ T races(IT (Orch)) Orch[Rem] µ.a

T races(IT (Orch)) P athOrch(µ.a)

c a c?t P athOrch(µ) c?t p1 U (pOσ) U (p1) Obs(Orch) σ2 traces(U (pO σ)) = traces(U (p1)).c?t.σ2 U (p1) c?t σ U T races(Orch) P athO_rch(µ) µ.a P athOrch(ρ) σ T races(Obs(Orch[Rem], Co))∩ U T races(Obs(Orch)) κ0 Orch[Rem] σ U (κ0_{) = σ Orch ioco Orch Orch}

Ch pσ P ath(IT (Orch))

traces(pσ) = κ0

Orch[Rem] ioco IT (Orch) κ0

Orch[Rem] IT (Orch) o Orch[Rem] κ0.o IT (Orch) U (κ0.o) = U (κ0).o

Obs(Orch)

∀σ ∈ T races(Obs(Orch[Rem], Co)) ∩ U T races(Obs(Orch)), ∀o ∈ O(C, M )

σ.o ∈ T races(Obs(Orch[Rem], Co)) ⇒ σ.o ∈ T races(Obs(Orch))

Obs(Orch[Rem], Co) uioco Obs(Orch)

Orch[Rem] Obs(Orch[Rem], Co) IOLT S Orch Rem Orch Rem IOLT S Orch Rem IOLT S Orch IT (Orch) Obs(Orch) Orch Rem

IOLT S q0 q00 q1 q1 q2 q10 q01 q02 q0 q₀0 a q1 a q0 0 a a a δm δ δm δ act act

IOLT S IOLT S C _C C_{⊆ C S} (Act(C, M ) ∪ {δ})∗ S ↓C {sq ↓ | sq ∈ S} sq ↓ • sq = ε sq ↓= ε • sq = sq0.a a /∈ Act(C, M ) ∪ {δ} sq ↓= sq0_↓ a ∈ Act(C, M ) ∪ {δ} sq ↓= (sq0_↓).a IOLT S IOLT S sq IOLT S q0 q3 q0 u screen!win

u start?token.sg generate!seed.sg sequence?sequence.u screen!win

C

C_{= {sg generate, sg sequence}} sq C

C M ir : (Act(C, M ) ∪ {δ})∗ → (Act(C, M ) ∪ {δ})∗ • M ir(ε) = ε • sq sq0_{.c!v M ir(sq) = M ir(sq}0_).c?v • sq sq0.c?v M ir(sq) = M ir(sq0).c!v • sq sq0.δ M ir(sq) = M ir(sq0).δ IOLT S IOLT S sq IOLT S q0 q3 q0 u screen!win

u start?token.sg generate!seed.sg sequence?sequence.u screen!win

sq

u start!token.sg generate?seed.sg sequence!sequence.u screen?win

Orch IOLT S C W C C = Cc∪S_w∈WCw Cc w 6= w0 _{∈ W C} c∩ Cw = ∅ Cw∩ Cw0 = ∅ Cc Ch Co S w∈WCw Cr= Ch∪ Co C Cc∪Sw∈WCw Orch IOLT S C Orch w ∈ W Cw6= ∅ p ∈ P ath(Orch)

(tri)i∈N source(tr1) = target(p) i ∈ N

target(tri) = source(tri+1) i ∈ N

act(tri) 6∈ O(Cw, M )

Orch δ

δ

δ

w

Orch = (Q, init, T r) IOLT S C w W p ∈ P ath(Orch) Orch SQw(p) p w • p = ε SQw(ε) = {ε} • tr00 p.tr00∈ P ath(Orch) sq.δm∈ SQw(p) sq ∈ SQw(p) δm∈ {δ}∗ • p = p0_{.tr ∈ P ath(Orch) tr ∈ T r} O_rch sq0 ∈ SQ_w(p0) sq0.act(tr) ∈ SQw(p)

act(tr) ∈ O(Cw, M ) sq0.δm.act(tr) ∈ SQw(p) δm∈ {δ}∗

IOLT S G Orch p Orch

(q0, u start?token, q1) (q1, sg generate!seed, q2) (q2, .sg sequence?sequence, q3)

(q3, u screen!win, q0)

sq w p

u start?token.δ∗.sg generate!seed.sg sequence?sequence.u screen!win.δ∗

w

Orch Orch δ

sg generate!seed sg sequence?sequence

Orch

w Orch

Orch w Orch IOLT S C

Orch w SQw(Orch) =Sp∈P ath(Orch)SQw(p)

w Orch Orch IOLT S

C ST r(Orch, w) w Orch M ir(SQw(Orch) ↓Cw) w sq Cw = {sg generate, sg sequence}

w Orch Mir(SQw(Orch) ↓Cw)(sq) δ∗.sg generate?seed.sg sequence!sequence.δ∗

Cw= {sg generate, sg sequence}

u start?token.sg generate!seed.sg sequence?sequence.u screen!win

Orch

Orch IOLT S C w ∈ W W U T SU T CW U T Cw⊆ CW U T T races(W U T )|Cw W U T σ1.c?v.σ2 σ1, σ2∈ (Act(Cw, M ) ∪ {δ})∗ c /∈ Cw W U T Orch • CW U T ∩ Cc= ∅ • w06= w Cw0∩ C_{W U T} = ∅ • σ ∈ (T races(W U T )|Cw) ↓Cw ∩ST r(Orch, w) ∃o ∈ Act(Cw, M ) ∪ {δ}

σ.o ∈ (T races(W U T )|Cw) ↓Cw⇒ σ.o ∈ ST r(Orch, w)

W U T ST r(Orch, w) W U T T races(W U T )|Cw W U T Cw T races(W U T )|Cw Cw (T races(W U T )|Cw) ↓Cw Cw W U T {c, e} IOLT S ST r(Orch, w) C w W U T1 W U T2 {c, e} ST r(Orch, w) {m.c?u.c!o.m0 _{| m ∈ {δ}}∗_{, m ∈ {δ}}∗_{} W U T} 1 W U T2 |C W U T1 e Orch Orch T races(W U T1)|C {m.c?u.m0 _{| m ∈ {δ}}∗_{, m ∈ {δ}}∗_{} ↓} C T races(W U T1)|C T races(W U T1)|C e?v1 |C e!v2 v1 v2 M (T races(W U T1)|C) ↓C= {m.c?u.m0| m ∈ {δ}∗, m ∈ {δ}∗} c?u.δ ST r(Orch, W U T1) W U T1 Orch c!o W U T1

W U T1 W U T2 ST r(Orch, w)

W U T1 Orch

c!o c?u e?u Orch

c!o c?u W U T2 T races(W U T2)|C T races(W U T2) ↓C e!u T races(W U T2)|C (T races(W U T2)|C) ↓C= {m.c?u.c!o.m0 | m ∈ {δ}∗, m ∈ {δ}∗} ST r(Orch, W U T2) W U T2 Orch Orch Orch

IOLT S IOST S IOST S

IOLT S IOST S IOST S IOLT S IOST S IOLT S IOLT S LT S IOLT S IOLT S LT S LT S IOST S • IOST S • IOST S IOST S • IOST S • IOST S IOLT S IOST S IOLT S IOST S IOLT S IOST S IOLT S IOST S

IOST S IOST S IOLT S LT S IOST S IOLT S LT S

IOST S IOST S IOST S IOST S IOLT S

I

IOST S IOST S IOST S IOST S IOST S IOST S IOLT S

IOST S I OST S Ω = (S, Op) S Op s1 · · · sn−1 → sn i ≤ n si ∈ S Ω ΩN = (SN, FN) • SN= {nat, bool} • FN= {0 :→ nat,

succ : nat → nat, + : nat × nat → nat, <: nat × nat → bool, true :→ bool, f alse :→ bool} V = a s∈S Vs Ω V TΩ(V ) = [ s∈S TΩ(V )s Op V T ype : TΩ(V ) → S t ∈ TΩ(V )s T ype(t) = s T ype T ype(X) = s X ⊆ Vs TΩ(∅) TΩ ΩN= (SN, FN)

V = Vnat ∪ Vbool Vnat = {x, y} Vbool = ∅

ΩN V TΩN(V ) 0, x, y, succ(0), succ(x), succ(y), +(0, 0)

(t, s) T ype(t) = s T ype : TΩN(V ) → S

(0, nat) (succ(x), nat) (+(0, 0), nat)

0 + 0 +(0, 0)

Ω σ : V → TΩ(V ) v s t TΩ(V ) s TΩ(V )V Ω V σ σ(f (t1. . . tn)) = f (σ(t1)) . . . f (σ(tn)) Ω V IdV IdV(v) = v v ∈ V ΩN σ : V → T_ΩN(V ) σ(x) = x + 1 σ(y) = y + 1 [x → x + 1, y → y + 1] σ(x + y) = (x + 1) + (y + 1) SenΩ(V ) Ω true f alse t = t0 t, t0∈ TΩ(V )s ¬, ∨, ∧ • x = y • ¬(0 = succ(x)) • x + 0 = x • x + succ(y) = succ(x + y) Ω M S Ms⊆ M M s f : s1· · · sn → s ∈ Op fM : Ms1 × · · · × Msn → Ms Ω ν V M TΩ(V ) MV Ω V M M ϕ M |= ϕ ν M |=ν ϕ M |=ν t = t0 ν(t) = ν(t0) M ϕ ϕ M ν M |=ν ϕ M Ω M IOST S Ω = (S, Op) M

Ω bool integer string

I OST S A = [ s∈S As IOST S C IOST S IOLT S • C c!t c t TΩ(A) • C c?x c x IOST S IOST S IOST S A C IOST S Σ (A, C) IOST S Σ Σsm= (Asm, Csm)

Asm= {token, seed, win seq, seq}

Csm= {u start, sg generate, sg sequence, u screen}

u start u start sg generate sg sg generate IOST S IOLT S τ

Σ IOST S

Σ Act(Σ) = I(Σ) ∪ O(Σ) ∪ {τ }

• I(Σ) = {c?x | x ∈ A, c ∈ C} • O(Σ) = {c!t | t ∈ TΩ(A), c ∈ C} Σsm Act(Σsm) sg generate!seed u screen! lose win Asm Ω IOST S

IOST S Σ Σ = (A, C) IOST S Σ G = (Q, init, T r)

• Q • init ∈ Q

• T r ⊆ Q × SenΩ(A) × Act(Σ) × TΩ(A)A× Q

IOST S G (Q, init, T r) Σ QG initG T rG

Q init T r

tr ∈ T rG (q, ϕ, act, ρ, q0)

source(tr) guard(tr) act(tr) sub(tr) target(tr) q ϕ act ρ q0 _sub(tr) A IdA A IOST S → guard(tr) = true sub(tr) = IdA

IOST S IOST S c!t c?x τ tr {d, v} a b Ω c C q0 q1 a > b guard(tr) a b c v v d q1 guard(tr) v c q1 IOST S IOST S G Σsm = (Asm, Csm) {q0, q1, q2, q3} q0 u start?token −−−−−−−−−−−−−−−→ seed=random(token) win seq=random(seed) q1 u start

IOST S

token seed win seq

random(integer) IOLT S IOST S random(integer) random(x) = x ∗ 2 + 1 I OST S IOST S IOST S IOST S Σ = (A, C) IOST S Σ ActM(Σ) = IM(Σ) ∪ OM(Σ) ∪ {τ } IM(C) = {c?v | c ∈ C, v ∈ M } OM(C) = {c!v | c ∈ C, v ∈ M } v

q0 q1 u start?token token 1 u start?1 1 token IOLT S IOST S G _{= (Q, init, T r)} IOST S Σ tr ∈ T r (q, ϕ, act, ρ, q0) Run(tr) ⊆ MA_{× Act} M(Σ) × MA (νi, actM, νf) ∈ Run(tr) • act c!t M |=νi ϕ νf= νi◦ ρ actM = c!νi(t) • act c?x M |=νiϕ νa νa(z) = νi(z) z 6= x νf = νa◦ ρ actM = c?νa(x) • act τ M |=νiϕ νf = νi◦ ρ actM = τ Run(tr)

r Run(tr) (νi, actM, νf) source(r)

act(r) target(r) νi actM νf

νi

νf

actM

τ

q0 q1

[token → 0, seed → 0, win seq → 0, seq → 0]

[token → 1, seed → 6, win seq → 4, seq → 0] seed win seq random

IOST S G = (Q, init, T r) IOST S Σ

P ath(G) tr1· · · trn T r

• source(tr1) = init

• i 1 ≤ i < n target(tri) = source(tri+1)

q ∈ Q P ath(q) ⊆ P ath(G) p ∈ P ath(G) p = tr1· · · trn p ∈ P ath(q) target(trn) = q p = tr1· · · trn p length(p) = n P ath(q) q IOST S IOST S q0 q2

(q0, true, u start?token, ρ, q1) (q1, true, sg generate!seed, IdA, q2)

ρ : [seed → random(token), win seq → random(seed)] P ath(q2)

G _{IOST S Σ}

p Run(p) p = tr1· · · trn

P ath(G) r1· · · rn

• i ≤ n ri tri ri∈ Run(tri)

• i < n target(ri) = source(tri+1)

G _{RP (G)} RP (G) =S_{p∈P ath(G)}Run(p)

IOLT S IOST S

IOST S G _{IOST S}

Live(G) P ath(G) p ∈ Live(G) ∃ tr ∈ T r act(tr) ∈ O(Σ) ∪ {τ } p.tr ∈ Live(G)

G _{Live(G) = ∅}

Live(G) G

IOST S IOST S Live(G)

G _{IOST S Σ} p ∈ P ath(G)

p traces(p) S

r∈Run(p){traces(r)} traces(r)

• r ε traces(r) ε

• p p0.tr r r0.a r0 ∈ Run(p0) a ∈ Run(tr)

act(a) τ traces(r) traces(r0)

act(a) τ traces(r0_{) traces(r).act(a)}

q0 q3

q0 u screen! win

u start?1 sg generate!6 sg sequence?4 u screen! win IOST S IOST S G _{IOST S Σ} G T races(G) = [ p∈P ath(G) traces(p)