C 22 C 23 op 3 qui, à partir d'un comportement du système global, aidera à se concentrer sur les comportements de sous-systèmes qui sont activés dans l'exécution du système [48].

Abstract

In spite of several decades of research, assuring the quality of software systems still represents a major and serious problem nowadays for the industry with respect to both results and costs. This thesis comes within the scope of a proposal centered on a generic unified framework for both complex software systems modeling and testing.

The contribution of this paper is then twofold: first, it defines a unified framework for modeling generic components, as well as a formalization of integration rules to combine their behaviour. This is based on a coalgebraic definition of components, which is a categorical representation allowing the unification of a large family of formalisms for specifying state-based systems. Second, it studies compositional conformance testing i.e. checking whether an implementation made from correct interacting components combined with integration operators conforms to its specification. La thèse s'inscrit dans le domaine de la modélisation et de la validation des systèmes modernes complexes. Les systèmes actuels sont en fait d'une complexité sans cesse croissante et formés de plus en plus de composants de natures différentes. Ceci rend leur processus de conception et de validation coûteux et difficile. Il semble être la simple façon permettant de faire face à cette hétérogénéité et à cette complexité est l'approche orientée composant. Suivant cette approche, le système est une entité formée par un ensemble des composants interconnectés. Les composants définissent une interface qui permet d'abstraire leur modèle interne (boîte noire), ce qui favorise la modularité et la réutilisation des composants. L'interaction entre ces composants se fait conformément à un ensemble des règles pré-établies, permettant ainsi d'avoir une vision globale de comportement du système.

La conception ainsi que la validation des systèmes modernes reste alors problématique à cause de la nécessité de prendre en compte l'hétérogénéité des différents composants. Dans ce cadre, dans un premier temps, nous définirons un cadre formel générique dans lequel une large famille de formalismes de description de systèmes à base d'états peut être naturellement capturée. Ainsi, nous allons définir un ensemble de règles de composition permettant de mettre en correspondance les différents composants et ainsi de constituer un modèle global du système à concevoir. Dans un second temps, nous proposerons une approche de test d'intégration qui permet de valider le comportement d'un système complexe sous l'hypothèse que chaque composant est testé et validé. Cette approche vise à générer automatiquement des cas de test en s'appuyant sur un modèle global décrit dans notre framework du système sous test.

Introduction Générale

Ce chapitre décrit le contexte de cette thèse et la motivation de notre recherche. Il propose une définition d'un système complexe et se demande comment celui-ci peut être modélisé et testé. Il présente aussi la « feuille de route » pour les chapitres à suivre et fournit les concepts et notions nécessaires pour à la compréhension.

Contexte général

En dépit de plusieurs décennies de recherche, assurer la qualité des systèmes informatiques représente toujours un problème actuel majeur et épineux pour l'industrie en ce qui concerne à la fois les résultats et les coûts [1]. Cette thèse a pour but de proposer une théorie générique et unifiée pour la modélisation et la validation des systèmes complexes.

Par la suite, nous présenterons les concepts et les notions nécessaires pour atteindre notre objectif.

Modélisation d'un système

Les travaux que nous proposons dans cette thèse consistent d'abord à définir un formalisme générique permettant de modéliser la notion d'un composant informatique comme une coalgèbre concrète d'un foncteur donné dans la catégorie des ensembles Set. Avant d'aller à l'explication de ce formalisme, nous allons d'abord succinctement expliquer :

-Ce que nous endentons par la notion d'un composant et d'un système complexe, -L'importance d'avoir une description générique d'un composant, -Pourquoi utiliser la définition du composant proposé par Barbosa dans le cadre de la théorie des coalgèbres et celle des monades.

Composants L'approche orientée composant [2,3,4] est de plus en plus sollicitée grâce à son potentiel. Elle offre de nombreux avantages tels que la modularité, la ré-utilisabilité, et divers autres avantages. Dans cette approche, les composants sont séparément conçus, développés et testés une seule et unique fois, afin d'être utilisés dans divers domaines.

Les fonctionnalités d'un composant sont alors définies à un niveau d'abstraction plus haut que celui de son implantation. Ainsi, la meilleur façon d'adresser formellement le composant est de le considérer comme une représentation abstraite, en omettant les détails de son implantation, tout en surlignant les principales propriétés liées à ses fonctionnalités. Cette représentation est seulement construite en décrivant comment les sorties sont produites en corrélation à la fois avec les entrées et l'état du composant. On parle classiquement d'une représentation boîte noire. La structure interne d'un système (i.e comment il a été mis en oeuvre) est ainsi ignorée. Seule la vue fonctionnelle (ou comportementale) du système (i.e ce que fait un système) est considérée. Toutes les communications entre le système et l'environnement sont décrites via l'interface du système. Un observateur extérieur peut seulement observer le système via cette interface. Une telle vue d'un observateur externe représente le comportement complet du système en termes d'entrées sorties.

Du point de vue de l'environnement, une boîte noire peut alors être considérée comme une fonction qui associe, à tout instant t (qui peut être discret ou continu), une sortie du système o ∈ Out après avoir reçu une entrée i ∈ In. Cette fonction dépend de l'état courant s ∈ S du système, et prend la forme suivante : y = F (x, s, t) où x, y et s sont respectivement l'entrée, la sortie et l'état du composant considéré et t est l'instant de temps. D'un point de vue environnemental, un système peut donc être représenté comme dans la figure suivante.

S In(t)

Out(t)

FIGURE 1 -Représentation du système par une boîte noire

Systèmes complexes Jusqu'ici, nous avons vu que l'approche orientée composant pourrait faire face à l'hétérogénéité croissante des composants de différentes natures en cachant plus ou moins de détails liés aux architectures internes des composants selon l'étape du processus de conception considérée. Cela signifie que le comportement global d'un système complexe, serait moins difficile à étudier quand les sous-systèmes sous-adjacents sont considérés comme des représentations boîte noire. De cette façon, une approche puissante pour le développement des systèmes informatiques complexes pourrait se reposer sur l'idée qu'un système complexe est construit en ayant assemblé des composants d'une manière hiérarchique et récursive. Ces sous-systèmes sont ainsi intégrés par le biais de connecteurs architecturaux, qui sont des outils puissants pour décrire les systèmes en termes de composants et de leurs interactions [4]. L'idée de base est que, à un haut niveau d'abstraction, les systèmes complexes peuvent être récursivement et hiérarchiquement constitués d'un ensemble de plusieurs sous-systèmes interconnectés. Chaque sous-système peut être lui-même un système complexe ou un système simple et élémentaire qui peut être traité entièrement. Une telle description hiérarchique formelle d'un système complexe ressemblerait généralement à la construction illustrée dans la Figure I. 2. La composition est utilisée pour assembler les différents sous-systèmes entre eux pour alors former de plus grands systèmes. Une telle composition peut être considérée comme une opération qui prend les composants ainsi que la nature de leurs interactions pour construire un nouveau composant beaucoup plus complexe. Cette représentation récursive d'un système complexe comme une composition de composants élémentaires en utilisant les règles d'intégration, nous permet alors de séparer la réalisation de différents composants. Cela a pour conséquence de rendre le processus de conception plus modulaire. La composition elle-même devient un composant qui peut être encore composé comme si il était lui-même un composant atomique.

FIGURE 2 -vue compositionnelle d'un système complexe

Vue unifiée des systèmes Les sous-systèmes à partir desquels les systèmes complexes sont conçus, peuvent en effet être modélisés, en utilisant des formalismes de spécification qui différent principalement selon les disciplines scientifiques et les modèles de calcul utilisés pour spécifier l'interaction entre les différents éléments du système. A l'heure actuelle, il n'existe toujours pas de formalisme unifié qui pourrait supporter la conception et la validation des systèmes modernes dans leur généralité. Néanmoins, on peut observer que la plupart des systèmes modernes peuvent être considérés, d'un point de vue théorique et à un haut niveau d'abstraction, comme des systèmes à base d'états dont le comportement peut être seulement observé au travers de leurs interfaces.

Cependant, il s'avère de plus en plus difficile, voire impossible, de construire par de formalismes de description classiques tels que les logiques du premier ordre ou équationnelle, le comportement de ces systèmes dont les structures sont intrinsèquement dynamiques. En effet, les caractéristiques des systèmes actuels tendent à être vues non plus du point de vue de la façon dont ils ont été construits, mais de celui des résultats qu'ils produisent. La sémantique de ces systèmes est alors essentiellement observationnelle. Tout ce qui peut être capturé dans leur évolution est leur interaction avec l'environnement, c'est-à-dire les échanges possibles entre des entrées et des sorties avec le monde extérieur. De ce point de vue, l'approche coalgèbrique peut être perçue comme l'approche duale de l'approche algébrique. Au lieu de construire les objets, on les observe. Dans ce contexte, la théorie des catégories et celle des coalgèbres fournissent tous les concepts nécessaires pour gérer abstraitement le comportement observable de tels systèmes.

Approches coalgèbriques pour la modélisation des systèmes Les coalgèbres se montrent ainsi de plus en plus adaptées pour définir la sémantique des systèmes réactifs. Elles sont considérées aujourd'hui comme une abstraction de formalismes à base d'états fournissant un cadre formel unifié et générique dans lequel une large variété des systèmes à base d'états pourrait être décrite tels que les systèmes de transition, les automates et les classes dans les langages orientés objet [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF][START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF][START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF]8]. Une des contributions majeures dans la modélisation coalgèbrique d'un composant est le travail proposé par Barbosa [9,[START_REF] Barbosa | State-based components made generic[END_REF][START_REF] Barbosa | Generic components[END_REF][START_REF] Barbosa | Components as processes: An exercise in coalgebraic modeling[END_REF][START_REF] Barbosa | Components as coalgebras[END_REF]. Les coalgèbres ont été utilisées comme un modèle sémantique pour les composants informatiques pour un endofoncteur dans la catégorie des ensembles. Un composant est ainsi décrit comme une machine de Mealy étendue par paramétrisation par une monade T, comme il est d'usage dans la programmation fonctionnelle [START_REF] Wadler | Monads for functional programming[END_REF]. La monade T agit comme un modèle de comportement qui peut gérer les calculs usuels tels que le déterminisme, le non-déterminisme, les situations de blocage, les exceptions et beaucoup d'autres encore [START_REF] Moggi | Computational lambda-calculus and monads[END_REF][START_REF] Moggi | Notions of computation and monads[END_REF].

La notion d'un composant comme il a été introduit par Barbosa est la pierre angulaire de notre modélisation.

Validation et vérification

Correction des systèmes et son importance Avec la complexité croissante des systèmes informatiques modernes, les techniques de vérification et de validation gagnent en importance. Assurer le bon fonctionnement des systèmes modernes est devenu l'un des défis majeurs de nos jours. Des conséquences dramatiques en termes de vies humaines, de pertes économiques, de problèmes écologiques, etc. sont causées lorsque une panne (ou défaillance) dans le système survient. Les pannes des systèmes sont en effet omniprésentes à tel point qu'elles sont si familières pour nous que nous avons pris l'habitude de les oublier. Certaines d'entre elles ont peu d'impact dans notre vie quotidienne, par exemple, lorsque notre téléphone mobile ne fonctionne pas correctement ou notre enregistreur vidéo réagit de façon inattendue et à tort, à des commandes. Toutefois, d'autres erreurs ont un énorme impact. Dans l'histoire, il y a une longue liste de bugs typiques qui ont causé des lourdes pertes en termes de vies humaines tels que Therac-25, ou en terme d'argent tels que le crash d'Ariane 5 (qui a coûté environ 500 millions de dollars américains) et le bug de la division du Pentium (environ 500 millions de dollars américains), etc. [START_REF] Hower | Software quality assurance and testing resource center[END_REF][START_REF]10 great bugs of history[END_REF]. Ces exemples font que la correction des systèmes informatiques constitue aujourd'hui un vrai défi (en termes de temps et d'argent) autant pour la conception que pour la validation et la vérification de leur comportement.

Test et vérification La validation d'un système se fait par la mise en oeuvre de méthodes utilisant une représentation formelle du comportement du système. Dans ce cadre, plusieurs techniques ont été proposées telles que la preuve, la vérification de modèles « model checking » ou encore le test. La preuve, telle que la logique de Hoare [START_REF] Hoare | An axiomatic basis for computer programming[END_REF], consiste à exprimer formellement les propriétés attendues du système et à démontrer que ces propriétés sont vraies par déduction à partir d'un ensemble d'axiomes et de règles d'inférences. Les techniques de model checking [START_REF] Clarke | Design and synthesis of synchronization skeletons using branching-time temporal logic[END_REF][START_REF] Queille | Specification and verification of concurrent systems in cesar[END_REF] consistent à construire, à partir d'une description formelle d'un système, l'espace des états atteignables puis, en parcourant l'ensemble de ces états, à vérifier d'une manière automatique le respect des propriétés attendues du système. Le test [START_REF] Myers | Art of Software Testing[END_REF][START_REF] Beizer | Software testing techniques[END_REF] vise à vérifier par expérimentation que le système sous test répond bien aux critères déjà définis (robuste, fonctionnalités correctement implémentées, etc.).

Ces trois techniques sont complémentaires dans le sens où aucune d'entre elles ne suffit à elle-même pour établir complètement la correction d'un système. En effet, la mise en oeuvre de la technique par la preuve est très difficile et nécessite généralement de fortes compétences mathématiques de la part de l'utilisateur. De plus, elle n'est pas complètement automatisée. Par contraste, bien que les techniques de model checking soient exhaustives et automatiques, elles se heurtent rapidement au problème de l'explosion combinatoire du nombre des états du système. Enfin, le test peut servir à détecter automatiquement les erreurs du système mais n'établit jamais leur absence [START_REF] Dijkstra | Notes on structured programming[END_REF]. Il est indispensable pour nous renseigner sur la correction d'un système, surtout dans le cas où la complexité des modèles est importante.

Dans ce travail, nous intéresserons plus particulièrement aux techniques de tests. Nous proposerons de nous intéresser à la définition d'une théorie du test. Nous justifions de porter notre attention sur le test au détriment de la preuve pour deux raisons :

1. Le premier est que, nous avons pour ambition de définir un formalisme, permettant de modéliser des systèmes informatiques complexes dont l'une des caractéristiques est leur grande taille. Or nous venons de voir précédemment que pour de tels systèmes, les méthodes de vérification étaient limitées. 2. La seconde raison de notre choix est plus pratique. En effet, les méthodes de vérification ont pour but essentiel de montrer que les systèmes vérifient un certain nombre de propriétés formelles. Ces propriétés formelles sont exprimées dans une logique. Donc, pour aborder la vérification dans notre cadre, il aurait fallu définir une logique (temporelle) audessus de notre formalisme et établir un certain nombre de propriétés sur cette logique.

Il faudrait par exemple définir un calcul et montrer que ce dernier est correct et complet, montrer que la logique est stable pour la bisimulation, étudier la préservation des propriétés au-travers des opérateurs d'intégration, etc. Or tout ceci est souvent un travail de longue haleine, difficilement abordable en même temps que la définition du formalisme lui-même. Cependant, la définition d'une telle logique est primordiale. Elle fait donc naturellement partie des perspectives de la thèse.

Techniques du test Le test est l'activité du génie logiciel qui vise à renforcer la qualité des systèmes à l'aide d'expérimentations dans l'intention d'y trouver des erreurs. Il peut être utilisé pour révéler la présence d'erreurs, mais ne peut pas établir leur absence [START_REF] Myers | Art of Software Testing[END_REF][START_REF] Dijkstra | Notes on structured programming[END_REF][START_REF][END_REF]. Dans 3. l'aspect que l'on veut tester : il y a multitude d'aspects différents que l'on pourrait utiliser pour tester un système. Par exemple, le test de conformité consiste à tester le comportement de implémentation pour s'assurer que celle-ci va se comporter comme prévu (par rapport à une référence de correction disponible représentée par un cahier des charges). Le test de robustesse vise à tester si l'implémentation réagit bien au comportement non-spécifié, incertain ou malveillant d'environnement, etc.

Dans le cadre de cette thèse, nous allons bien entendu nous intéresser aux techniques de test unitaire et d'intégration qui sont fonctionnelles et fondées sur le test de conformité.

Test de conformité Le test de conformité est une technique de test de type boîte noire, qui a pour objectif de vérifier la conformité d'une réalisation concrète du système (implémentation) à une description formelle de son comportement (spécification) [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF][START_REF] Beizer | Black-box testing: techniques for functional testing of software and systems[END_REF]. Il vise à réaliser des expérimentations sur l'implantation afin de vérifier la correction de son comportement vis-àvis de sa spécification. L'idée consiste alors à dériver automatiquement une suite de cas de tests de la spécification suivant un algorithme de dérivation de tests. L'exécution de chacun des tests générés sur l'implantation à l'aide d'un testeur (qui peut être un être humain ou un programme) mène à un verdict : Pass ou Fail. Le verdict Pass indique que l'implantation est conforme à la spécification pour ce test, tandis que le verdict Fail signifie la non-conformité.

Test d'intégration

A l'heure actuelle, la complexité des systèmes, qui ne cesse de croître, mène naturellement à des difficultés, voire une impossibilité dans certains cas, à utiliser les techniques standards de validation et vérification dans la pratique. Il s'avère que des aspects importants tels que l'hétérogénéité, la décentralisation et la distribution des applications sont difficilement pris en compte par les techniques actuelles de vérification et de validation. Ceci est particulièrement dû au fait que ces techniques ne permettent de considérer que des systèmes de taille réelle maniable, pris comme un seul bloc. Ceux-ci sont généralement traités en de temps raisonnable. Cependant, dès que les systèmes sont de complexité rédhibitoire, ce qui est le cas aujourd'hui avec les systèmes informatiques, ces techniques deviennent difficile à être mises en place. Dans ce cadre, les approches basées sur le raisonnement compositionnel [START_REF] Clarke | Compositional model checking[END_REF][START_REF] Chang | Compositional verification of real-time systems[END_REF][START_REF] Van Der Bijl | Compositional testing with ioco[END_REF] semblent être une des directions les plus prometteuses pour combler le fossé entre la complexité réaliste et croissante des systèmes et les limites des méthodes de vérification et de test.

L'idée directrice de ces approches émergentes, est d'utiliser le principe « diviser pour mieux régner » consistant à décomposer la correction d'un système de taille réaliste en petites tâches. Celles-ci ont ainsi des complexités maniables et leur correction peut être validée localement La vérification compositionnelle a pour but de déduire les propriétés globales d'un système complexe à partir des propriétés de ses composants. Soient n composants dont les modèles de comportement sont M 1 , . . . , M n satisfaisant respectivement les propriétés locales φ 1 , . . . , φ n et op est l'opérateur de composition de comportement. La vérification compositionnelle consiste alors à vérifier si le système op(M 1 , . . . , M n ) résultant de la composition de M 1 , . . . , M 2 satisfait une propriété globale φ. De cette façon, les techniques de vérification compositionnelle peuvent éviter l'explosion combinatoire, en décomposant les systèmes en petits sous-systèmes sur lesquels les techniques de vérification classiques peuvent être appliquées directement.

En ce sens, la théorie du test d'intégration vise à vérifier si la correction du système C = op(C 1 , . . . , C 2 ) est établie en utilisant la correction de chaque composant C i où op est l'opérateur d'intégration considéré. Le problème de test d'intégration peut être alors vu comme suivant : étant données les implantations iut 1 , . . . , iut n , les spécifications spec 1 , . . . , spec n , un opérateur d'intégration op et une relation de conformité ref telles que iut 1 , . . . , iut n ont été testées pour être conforme à leurs spécifications spec 1 , . . . , spec n respectivement, par rapport à la relation ref, pouvons-nous conclure que leur composition op(iut 1 , . . . , iut n ) est aussi conforme à la spécifica- tion globale op(spec 1 , . . . , spec n ), par rapport à la relation ref ?

Contributions de la thèse

Comme indiqué dans l'introduction de ce chapitre, le travail que nous présentons a comme objectif la proposition d'une théorie générique pour la modélisation et la validation des systèmes informatiques complexes. Cette thèse est constituée de deux parties principales : la partie « modélisation » et la partie « validation par la technique du test de conformité ». La première partie consiste à proposer un cadre générique unifié pour la modélisation de systèmes standards à base d'états, en particulier, ceux qui sont dédiés à la génération de cas de tests de conformité.

Elle vise aussi à définir un ensemble minimaliste d'opérateurs d'intégration pour combiner des sous-systèmes. La deuxième partie consiste à proposer une théorie du test d'intégration visant à être en mesure de valider les systèmes informatiques complexes.

Nous nous intéressons plus particulièrement aux thèmes suivants :

Cadre formel unifié pour la modélisation des systèmes à base d'états

Basé sur l'approche proposée [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Meng | Components as coalgebras: the refinement dimension[END_REF] par Barbosa pour la modélisation de composants, nous proposons un cadre formel générique unifié pour la modélisation de systèmes à base d'états. Un tel système est alors représenté par une coalgèbre (S, init, α : S -→ T(Out × S) In ) du foncteur F défini par FX = H(Out × X) In dans la catégorie des ensembles Set, avec T une monade, et In et Out deux ensembles d'éléments qui désignent respectivement les entrées et les sorties du composant. Cette représentation coalgébrique des composants nous permettra :

-de considérer d'une manière générique une large famille de calculs usuels tels que le déterminisme, le non-déterminisme, la partialité, et d'autres. Ceci est dû à l'introduction de la notion d'une monade T dans la définition du composant qui nous permet de définir les composants d'une manière indépendante de toute structure de calcul [START_REF] Wadler | Comprehending monads[END_REF][START_REF] Wadler | Monads for functional programming[END_REF].

-de fournir un cadre formel générique dans lequel une large famille de formalismes de description peut être naturellement capturée. En particulier, il permet d'englober les formalismes standards dédiés à la génération de test de conformité tels que les automates de Mealy [START_REF] Eilenberg | Automata, Languages and Machines[END_REF][START_REF] Mealy | A method for synthesizing sequentiel circuits[END_REF], les systèmes de transitions étiquetées (LTS) [START_REF] Milner | A calculus of communicating systems[END_REF][START_REF] Brookes | An Improved Failures Model for Communicating Processes[END_REF], les systèmes de transitions étiquetées à entrées et sorties (IOLTS) [START_REF] Lynch | An introduction to input/output automata[END_REF][START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF][START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF], etc.

Sémantique unifiée des traces pour les systèmes à base d'états

Cette manière de décrire le comportement des composants nous permettra, suivant les travaux de Rutten [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF], de définir un modèle de traces pour les composants par des fonctions causales.

Ces fonctions sont des transformations de flux de données de la forme :

y = f (x, s, t)
où x, y et s sont respectivement l'entrée, la sortie et l'état du composant et t est le temps discret. Ainsi, en prenant le bénéfice de définir le comportement des composants comme des fonctions de transfert causales, la définition d'un modèle de traces à partir de fonctions causales nous permettra de montrer l'existence d'une coalgèbre finale dans la catégorie des coalgèbres du foncteur H(Out × ) In en imposant certaines conditions suffisantes sur la monade T. Cette dernière est en effet utile pour définir les opérateurs d'intégration et rendre plus facile la preuve des théorèmes tout-au-long de la thèse.

Cette représentation du comportement du système forme la première étape vers un cadre unifié qui capte non seulement l'hétérogénéité des calculs usuels, mais aussi celle du temps (i.e. le temps discret et continu). En effet, dans cette thèse, nous nous restreignons au cas du temps discret pour lequel nous adresserons seulement l'hétérogénéité de formalismes utilisés pour la modélisation des composants. Cependant, il y a d'autres travaux réalisés dans le cadre de thèse de B. Golden [START_REF] Aiguier | Modeling of complex systems: A minimalist and unified semantics for heterogeneous integrated systems[END_REF] qui étendent notre cadre pour être en mesure de prendre en compte à la fois, le temps continu et le temps discret en utilisant les techniques de l'analyse non standard.

Opérateurs d'intégration

Nous proposons un ensemble d'opérateurs d'intégration pour construire de grands composants à partir de plus petits. Nous définissons ainsi deux opérateurs d'intégration de base : le produit cartésien et la rétroaction, et nous défendrons l'idée que les opérateurs d'intégration standards tels que les opérateurs de la composition séquentielle, concurrente ou parallèle et le produit synchronisé peuvent être obtenus par la composition de produit et de rétroaction. Cela nous conduira à définir inductivement des opérateurs d'intégration plus complexes, dont la sémantique sera considérée comme des foncteurs partiels dans la catégories des composants. Ainsi, un système sera construit d'une manière récursive et hiérarchique à l'aide de nos deux opérateurs d'intégration de bases à partir de systèmes élémentaires.

Théorie de test de conformité générique

De la généricité du formalisme développé dans cette thèse, nous proposons de définir une théorie du test de conformité générique pour les composants. Celle-ci sera de facto applicable à l'ensemble des formalismes à base d'états, instances de notre cadre tels que ceux dédiés à la génération des cas de tests. Il existe en effet plusieurs théorie du test de conformité dans la littérature [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Frantzen | A Symbolic Framework for Model-Based Testing[END_REF][START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Tretmans | Testing labeled transition systems with inputs and outputs[END_REF][START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF][START_REF] Rusu | An approach to symbolic test generation[END_REF] qui se différencient par la relation de conformité considérée et les algorithmes de génération mis en place. Bien que la plupart de ces théories pourraient être adaptées à notre formalisme, nous proposons ici d'étendre l'approche définie dans [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] développée dans le cadre des IOLTS. L'intérêt de la théorie du test de conformité proposée dans [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] est qu'elle est fondée sur la relation de conformité ioco qui a montré son adaptation pour le test formel ainsi que pour la dérivation automatique de cas de test. De plus, les algorithmes de génération proposés dans [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] sont simples dans leur implantation et efficaces dans leur exécution.

Nous proposerons une technique du test de conformité basée sur la notion de l'objectif de test. Les objectifs de test seront définis comme des sous-arbres de l'arbre de l'exécution construit à partir de notre modèle de trace pour les composants. Les chemins dans ces sous-arbres caractérisent les comportements à tester. Ensuite, nous définirons un algorithme de génération de cas de tests à partir de l'objectif de tests comme [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF]. Cet algorithme sera formalisé par un ensemble de règles d'inférence. Chaque règle est dédiée pour gérer une observation du système sous test (iut) ou une stimulation envoyée par le cas de test à l'iut. Ce processus de test produit un verdict. Nous trouverons les verdicts Pass, Fail, Inconc et WeakPass.

Cette théorie du test de conformité générique constitue la première étape vers le test de systèmes informatiques complexes définis comme un assemblage d'un ensemble des composants.

Théorie de test d'intégration

Nous proposons aussi de définir une théorie du test d'intégration qui vise à tester un système en supposant que ses composants sous-jacents ont déjà été testés séparément et sont corrects [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF]. Le problème que nous adressons peut alors être vu comme suit. Si les composants d'un système sont conformes à leurs spécifications, que pouvons nous conclure sur la conformité du système par rapport à sa spécification ? Nous montrerons qu'une réponse positive à cette question ne peut être obtenue sans aucune hypothèse sur les spécifications et les implémentations.

Renforcer la qualité des composants par utilisation de techniques de projection

Nous proposons une approche pour renforcer la qualité des composants en tenant compte de leur implication dans le système global. L'idée sous-jacente consiste à montrer comment renforcer la correction de chaque composant impliqué dans le système global, en générant des cas de test plus appropriés pour eux. Ceci sera effectué en définissant un mécanisme de projection

Chapter I Introduction

This chapter provides the context of the thesis and gives the motivation of the research presented in it: what are complex software systems and how can they be modeled and tested? It briefly introduces the "roadmap" for the chapters to follow by giving concepts and notions needed to answer this question and then outlines the contributions and the structure of the thesis.

Context

In spite of several decades of research, assuring the quality of software systems still represents a major and serious problem nowadays for the industry with respect to both results and costs [1]. This thesis comes within the scope of a proposal centered on a generic unified framework for both complex software systems modeling and testing.

In the following, we outline concepts and notions needed to achieve our goal.

System modeling

The work of this thesis proposes first to define a generic abstract complex formalism that models software components as concrete coalgebras for some Set endofunctors. Before concretely addressing the definition of this formalism, we will first succinctly explain: 1. What do we mean by components and complex systems? Components Components are receiving increasing attention as a level of design thanks to the great advantages they offer: modularity, re-usability, cost-effective solution for increasing heterogeneity and complexity, etc. Components are then designed, developed and validated separately in order to be widely used.

Several definitions of a component have been proposed in literature. Szyperski defines components as "binary units of independent production, acquisition, and deployment that interact to form a functioning system" [2]. D'Souza and Wills define a component as "a reusable part of software, which is independently developed, and can be brought together with other components to build larger units. It may be adapted but may not be modified" [3]. Despite the lack of a unifying definition of what a component is, the design community agrees that any component definition should have the following characteristic properties [4]:

-It is a unit of encapsulation. It has internal state space, acting as the memory of the component;

-It is abstract enough to encapsulate a number of services through a public interface. There is no internal observable state, the only way to access its content is via its public interface;

-It persists and evolves in time, according to some given semantics;

-It can be deployed easily and independently;

-It is a unit of third-party composition, i.e. there is a possibility of interaction with other components during the overall computation of the whole system;

-It is equipped with input and output observation universes to ensure the flow of data during its execution.

Formal models of components

The functionality of a component should then be defined at a higher level than the implemented code. The suitable way to formally address components is to consider them as an abstract representation omitting implementation details and only describing properties relevant to their functionalities. Such a representation is only made by specifying how inputs drive changes in component states and how outputs are produced. We classically talk about black box representation. Thus, the internal structure of a system (i.e. how it has been implemented) is ignored, only the functional or behavioral view of the system (i.e. what its requirements are) is considered. All possible communications between the system and the environment are then described via interface. An external observer can observe the system only through this interface. Such an external observer's view represents the complete input-output behaviour of the system. From the point of view of the environment, a black box can be better seen as a function achieving at a different time t (that can be discrete or continuous) some given system functional requirement which makes the inputs In of the system correspond to its outputs Out. This function depends on the current internal state s ∈ S of the system, and then of the form y = F (x, s, t) where x, y and s are respectively the input, output and state of the component under consideration, and t is an instant of time.

A environmental view of a system can therefore be represented in Figure I.1.

S In(t)

Out(t)

Figure I.1 -Black box view of a system

Complex systems So far we have seen that the component-based approach is considered a cost-effective solution for increased modularity and re-usability of system designs. Black box representations can cope with the increasing heterogeneity of components of different natures disregarding underlying non-functional details of the components and their internal architectures. This means the global behaviour of a complex system would be less difficult to study when the underlying subsystems are considered as black box representations. In this way, a powerful approach to developing complex software systems could be to describe them in a hierarchical recursive way as interconnections of sub-systems (i.e. components). These sub-systems are then integrated through architectural connectors that are powerful tools to describe systems in terms of components and their interactions. Each subsystem can be then either a complex system itself or simple and elementary enough to be handled entirely.

Hence, the basic idea for modeling complex systems is that, at a high-level of abstraction, complex systems can be recursively decomposed into a set of subsystems, arriving at subsystems that can be completely handled. Such a formal hierarchical description of a complex system usually looks like the construction illustrated in Figure I. 2.

C 1 C 2 op 1 C11 C12 op 2 C 21 C 22 C 23 op 3 Figure I.2 -Compositional view of complex system
Composition is then used for assembling different sub-systems and then forming larger ones. Such a composition can be seen as an operation taking components as well as the interactive nature between them to provide a new more complex component. Hence, this recursive representation of a complex system as a composition of elementary components using integration rules allows us to separate the realization of different components and subsystems, and then makes the conception process more modular, i.e. the composition itself becomes a component that can be further composed as if it were itself an atomic component.

Suitable unified view of systems Sub-systems from which complex systems are made, may indeed be modeled using different specification formalisms depending especially on the scientific disciplines and the model of computations used to specify the interaction between the different elements of the system. At the moment, there are neither unified models nor unified tools that can be used to deal with such systems in all their generality. Nevertheless, one can observe that a common characteristic of sub-systems of most modern systems is that they can be considered, from a theoretical point of view and at a higher level of abstraction, as state-based components whose behaviour can only be observed along their interface. Hence, state-based systems seem to be a natural formal representation of most concrete modern systems such as digital hardware components, software programs and distributed systems. It turns out it is becoming more and more difficult to express these systems as algebraic representations i.e. in terms of a set of complete constructions. Their characteristics, indeed, tend to be seen as observable entities rather than definable ones. Hence, the semantics of such systems is essentially observational. All that can be captured in their evolution is their interaction with the environment, that is to say, the possible input/output between them and the outside world. Inputs are indeed the signals or data received by the system, and outputs are the signals or data sent from it. In this setting, coalgebra theory and category theory provide all the necessary concepts to handle abstractly the observable behaviour of such systems.

Coalgebraic approach to modeling systems Due to this observational view of systems, coalgebras are increasingly used as an appropriate abstract model of state-based dynamical systems, looking for a unified definition of a model from which a great variety state-based models could be deduced such as: transition systems, automata, process calculi and classes in object-oriented languages [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF][START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF][START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF]8]. One of the major contributions in component coalgebraic modeling are Barbosa's works [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Barbosa | State-based components made generic[END_REF][START_REF] Barbosa | Generic components[END_REF][START_REF] Barbosa | Components as processes: An exercise in coalgebraic modeling[END_REF][START_REF] Barbosa | Components as coalgebras[END_REF]. Coalgebras have been used as a semantic model for software components for some endofunctor on Set. A component is then presented as an extended Mealy machine parametrized by a monad T, as is customary in functional programing [START_REF] Wadler | Monads for functional programming[END_REF], acting as a behaviour model. The monad T can indeed handle the different usual computational effects such as determinism, non-determinism, possible deadlock states, or exceptions and many more [START_REF] Moggi | Computational lambda-calculus and monads[END_REF][START_REF] Moggi | Notions of computation and monads[END_REF]. Barbosa's approach will be the cornerstone of our modeling. We will detail it in Section 1.2 of Chapter IV.

Validation and verification

Correctness and its importance With the increasing complexity of modern software systems, verification and validation techniques are becoming more and more important. Ensuring the functional correctness of a system's behaviour is becoming one of the major challenges nowadays in view of dramatic consequences in terms of human lives, economic loss, ecological problems, etc. caused when the faulty behaviour of a system occurs. System failures are indeed everywhere to the point that they are so familiar to us that we usually forget them. Some of them have little impact in our daily life, for example, when our mobile phone is malfunctioning or our video recorder reacts unexpectedly and wrongly to commands via the remote control. However, other errors have a huge impact. In history, there is a long list of typical software bugs that have caused catastrophes in terms of loss of human lives [START_REF] Hower | Software quality assurance and testing resource center[END_REF][START_REF]10 great bugs of history[END_REF] such as Therac-25, or loss of money such as Ariane 5 crash (costs about 500 million US dollars) and Intel's Pentium floating-point division (a loss of about 500 million dollars), etc. All these examples make verification and validation phases more expensive (in terms of time and money) than construction, in most designs.

Testing vs verification

To reduce, as much as possible, the risk that a system fails, and so increase the level of confidence as well as decrease the gap between requirements specifying the functions that a system is expected to perform and the real implementation of the system, verification and validation techniques seem to be the best method. These techniques should be implemented automatically. Manual techniques such as peer reviewing have shown their unsuitability even impossibility in validating system functionalities as it is stated by Wolper in [START_REF] Wolper | Verification: Dreams and Reality[END_REF]: "manual verification is at least as likely to be wrong as the program itself". On the other hand, automatic techniques are widely used in practice and well-accepted in industrial fields.

Three important techniques are mainly used: formal proofs, model checking and testing. Formal proofs, such as Hoare logic [START_REF] Hoare | An axiomatic basis for computer programming[END_REF], consists in formally expressing the expected properties of the system and proving that these properties are correct by deduction from a set of axioms and inference rules. Model checking [START_REF] Clarke | Design and synthesis of synchronization skeletons using branching-time temporal logic[END_REF][START_REF] Queille | Specification and verification of concurrent systems in cesar[END_REF] consists in automatically and algorithmically verifying whether system properties such as the absence of deadlocks (described in some appropriate logical formalism such as temporal logic) are satisfied by the system (described as a finite state model). Testing [START_REF] Myers | Art of Software Testing[END_REF][START_REF] Beizer | Software testing techniques[END_REF] consists in running the system under test by providing it well-chosen input values (called tests), observing the value of its outputs, and then by comparing the observed behaviour with that desired, deducing whether the system is correct or not.

When talking about these techniques, the question "which technique is more effective?" directly arises. This question can be answered according mainly to both characteristics and complexity of the system under validation/verification. In general, verification and testing are best considered as complementary techniques. In practice, it turns out that they complement each other, and in most cases, there is a need to apply both to get the desired system quality. Indeed, though formal proof techniques are based on formal methods and considered to establish system correctness exhaustively, they are too hard and tedious to use in practice. In most cases, they cannot be automatically implemented, and need human help that renders the proof potentially incorrect. Though model checking intends to verify automatically that a system is free from errors, a close look at reality, however, reveals that it has its own weakness as we state below:

-it is only as good as the model of the system. In fact, it enables one to check exhaustively the correctness of a model of the system, but not the real system itself. The fact that a model has certain properties does not guarantee that the final realization also has the same properties;

-only desired or well-chosen properties are checked: there is no guarantee of the completeness of all system properties;

-it requires some expertise to be used (for example, some knowledge in logical temporal formalisms);

-it is hard to be used for systems of realistic size;

-it is impossible to use it in some cases, for instance, when there is no formal model of the system.

On the other hand, testing techniques can be applied directly to the real implementation, contrary to model checking or formal proofs that are based on mathematical models rather than on the real system. This advantage makes testing techniques more used in practice than other techniques, especially when verification methods seem impossible to be used due to the complexity of the system or its nature: there is no possibility to build a formal model of the real system (e.g physics devices, or it is proprietary). However, testing can never be complete as stated by Dijkstra's in [START_REF] Dijkstra | Notes on structured programming[END_REF]: "Testing can only show the presence of errors, never their absence". This is especially due to the too large set of all possible inputs to be submitted to the system. For example, suppose that a calculator only does both addition and subtraction operations for numbers ranging from 0 to 20. To test this calculator, it is required to execute both addition and subtraction operations on all possible combinations of integers in this range. This will require a total of Σ 20 20 1-42 ) executions. Then, assuming that testing is done on a computer that will take 10 -7 s to input a subset of integers ranging from 0 to 20, execute a calculator operation, and check if the output (i.e. result of the requested operation) is correct, the testing execution process will take approximately 2 × 21 2 × 1-( 42) 20 1-42 × 10 -7 s which is an order of years.

i=1 2 i × 21 i+1 (= 2 × 21 2 × 1-(42)
Thus, neither verification (both mathematical proofs and model checking) nor testing appear to be the perfect technique for proving the correctness of programs. They are often used as two related complementary activities and guide each other.

In this thesis, we are interested in testing, more precisely in defining a testing theory. Our reasons for focusing our attention on testing techniques to the detriment of verification ones are twofold:

1. First of all, our ambition is to define a mathematical framework to model complex software systems whose important characteristic is their large size. Yet, we have just seen that, verification methods are limited in their use for such systems.

2.

The second reason for our choice is more practical. Indeed, verification methods essentially aim to prove that the systems verify a certain number of formal properties. These formal properties are expressed in a logic. Then, to address verification in our framework, we would have had to define a logic (temporal) over our formalism, and then establish a certain number of properties of this logic such as defining a calculus and proving that this latter is correct and complete, showing that the logic is adequate with respect to bisimulation (i.e. every couple of bisimilar states satisfy the same set of properties), studying conditions to preserve properties along integration operators, etc. However, all of this is often a long-term job that is difficult to address at the same time as the formalism definition. Nevertheless, the definition of such a logic is primordial, it is therefore naturally a part of future thesis work.

Software testing Software testing is a process which aims to strengthen the quality of systems through experimentations with the intent of finding errors in them. It can be used to reveal the presence of errors, but never their absence [START_REF] Myers | Art of Software Testing[END_REF][START_REF] Dijkstra | Notes on structured programming[END_REF][START_REF][END_REF]. Many kinds of testing have been proposed that can be mainly classified in accordance with the following three characteristics (see Figure I.3):

level of code accessibility: two testing techniques are commonly distinguished: structural testing (also known as white box) [START_REF] Beizer | Software testing techniques[END_REF] in which system code is examined as to whether it works as expected, and functional testing (also known as black box) [START_REF] Beizer | Black-box testing: techniques for functional testing of software and systems[END_REF] in which system functionalities are examined without requiring any knowledge of the internal structure of the system.

level of abstraction: three testing methods are commonly distinguished: unit testing in which software or hardware components that cannot be subdivided into other components are examined, integration testing in which a larger component built as a combination of a set of basic components is examined, and system testing in which the complete system is tested.

aspects we want to test: there are different aspects used to test a system, for example conformance testing in which the behaviour of the implementation is tested to check whether it conforms to the specified behaviour, robustness testing in which an implementation reacts to unspecified, or "abnormal" environments, etc. Since our goal, in this thesis, is to verify the correctness of behaviour of component-based systems, testing techniques we address here come then within the scope of both unit and integration functional testing based on conformance testing.

Conformance testing theory

Conformance testing is a black box technique for checking correctness implementation against its specification by means of experimentations [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF][START_REF] Beizer | Black-box testing: techniques for functional testing of software and systems[END_REF]. It aims to check if the observable behaviour of the system under test conforms to a specification with respect to a particular conformance relation. The underlying idea consists in automatically generating test cases from a formal model a so-called specification of the system under test. These test cases are then executed by an external tester on the real system, and based on observed results, a verdict is generated indicating if the system was successful or not on the test of interest (or if the test was inconclusive).

Compositional testing

As a matter of fact, the exponentially growing complexity and heterogeneity of today's systems give rise naturally to difficulties even the impossibility, in some cases, of using actual validation and verification methods in practice. It turns out important aspects for software systems such as heterogeneity, decentralized and networked applications, etc. are not well-supported by actual modeling and both verification and testing techniques. This is especially due to the fact that these techniques are limited to scalability of the complexity of actual software systems that are not only large but are also growing dramatically. As in a state-based components approach, compositional reasoning approaches [START_REF] Clarke | Compositional model checking[END_REF][START_REF] Chang | Compositional verification of real-time systems[END_REF][START_REF] Van Der Bijl | Compositional testing with ioco[END_REF] about system correctness is viewed as one of the most promising directions to bridge the gap between the increasing complexity of systems and actual verification and testing method limits.

The underlying idea behind these emergent approaches is to use "divide-and-conquer" approaches consisting in breaking down the correction of a complex system into smaller tasks of lower complexity that involve the correctness of its components. The conclusion for the whole system correctness is then drawn by combining the results from the verification of the subtasks following certain compositional reasoning rules without verifying the whole system.

On the first hand, compositional verification aims to infer global properties of complex systems from properties of their components. It then consists in verifying, given n components with behaviour models M 1 , . . . , M n that satisfy local properties φ 1 , . . . , φ n respectively, and op is some composition behaviour operators, if the system op(M 1 , . . . , M n ) resulting from the composition of M 1 , . . . , M n will satisfy a global property φ. In this way, compositional verification techniques avoid combinatorial explosion by decomposing systems into smaller subsystems to which classical verification techniques can be directly applied.

In this sense, compositional testing theory aims to check whether the correctness of the whole system C = op(C 1 , . . . , C n ) is established using the correctness of each components C i where op is the integration operator of interest. Hence, the problem of compositional testing can be seen as follows: given implementation models iut 1 , . . . , iut n , specifications spec 1 , . . . , spec n , an integration operator op and a conformance relation rel such as iut 1 , . . . , iut n have been tested to be rel-correct according to their specifications spec 1 , . . . , spec n respectively, may we conclude that their composition op(iut 1 , . . . , iut n ) also rel-correct to the integrated specification op(spec 1 , . . . , spec n )?

Since, in this thesis, we propose a compositional method for the testing of component-based systems, we will only address the compositional testing approach.

Thesis overview

Thesis contributions

As stated in the introduction of this chapter, this thesis intends to contribute to two central topics: "modeling" and "testing" complex software systems. It then consists of two main parts. The first part, the modeling, intends to propose a generic unified framework from which most standard state-based systems, especially those which are dedicated to test case generation, can be deduced, and to define a minimalist set of operators to combine components. The second part, the testing, intends to propose generic compositional testing aimed at being able to validate complex software systems.

In particular, the contributions of this research work include:

Unifying formal framework for modeling state-based systems

Based on Barbosa's approach [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Meng | Components as coalgebras: the refinement dimension[END_REF] for component modeling, we propose a formal generic unified framework for modeling state-based systems. Systems are then modeled as concrete coalgebras over the endofunctor H = T(Out × ) In on the category of sets where T is a monad, and In and Out are two sets of elements which denote respectively inputs and outputs of the component. Such coalgebraic models will allow us:

1. to abstract away computation situations such as determinism or non-determinism. Indeed, monads have been introduced in [START_REF] Wadler | Comprehending monads[END_REF][START_REF] Wadler | Monads for functional programming[END_REF] to consider in a generic way a wide range of computation structures such as partiality, non-determinism, etc. Hence, such a component representation allows us to define components independently of any computation structure.

2. to unify in a single framework a large family of state-based formalisms encompassing most standard formalisms dedicated to conformance test generation such as Mealy au-tomata [START_REF] Eilenberg | Automata, Languages and Machines[END_REF][START_REF] Mealy | A method for synthesizing sequentiel circuits[END_REF], Labeled Transition Systems (LTS) [START_REF] Milner | A calculus of communicating systems[END_REF][START_REF] Brookes | An Improved Failures Model for Communicating Processes[END_REF], Input-Output Labeled Transition Systems (IOLTS) [START_REF] Lynch | An introduction to input/output automata[END_REF][START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF][START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF], etc.

Unifying trace semantics of state-based systems

This way of modeling component behaviour allows us, following Rutten's works [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF], to define a trace model over components by causal transfer functions. Such functions are dataflow transformations of the form: y = F (x, q, t) where x, y and q are respectively the input, output and state of the component under consideration, and t is discrete time.

Taking advantage of the definition of components behaviour as transfer functions, defining a trace model from causal functions allows us to show the existence of a final coalgebra in the category of coalgebras over Barbosa's signature H = T(Out × ) In under some sufficient conditions of the monad T. This final coalgebra is indeed useful when defining the integration operators and makes easier theorem proofs throughout the thesis. This representation of system behaviour then forms the first step towards a unified framework that captures not only different usual computations, but also time heterogeneity (i.e. both discrete and continuous times). Indeed, in this thesis we restrict ourselves to discrete time. Only formalism heterogeneity and component nature are addressed. However, there is other current work done in B. Golden's thesis extending our framework to be able to take into account continuous time using non-standard analysis [START_REF] Aiguier | Modeling of complex systems: A minimalist and unified semantics for heterogeneous integrated systems[END_REF].

Calculus of operators

We propose a calculus of standard operators used to build larger components from smaller ones. We then define two basic integration operators, product and feedback, and defend the idea that most standard integration operators such as sequential, concurrent and parallel composition operators and synchronous product can be obtained by composition of product and feedback. This will lead us to define inductively more complex integration operators, the semantics of which will be partial functors over categories of components. Hence, a system will be built by a recursive hierarchical process through these integration operators from elementary systems or basic components.

Generic conformance testing theory

From the genericity of the formalism developed in this thesis, we propose to define a generic conformance testing theory for components. This testing theory will be applicable de facto to all state-based formalisms, instances of our framework. There are several conformance testing theories in literature [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Frantzen | A Symbolic Framework for Model-Based Testing[END_REF][START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Tretmans | Testing labeled transition systems with inputs and outputs[END_REF][START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF][START_REF] Rusu | An approach to symbolic test generation[END_REF] that differ by the considered conformance relation and algorithms used to generate test cases. Although most of these theories could be adapted to our formalism, we propose here to extend the approach defined in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] in the context of IOSTS formalism. The advantage of the testing theory proposed in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] is that it is based on the conformance relation ioco that received much attention by the community of formal testing because it has shown its suitability for conformance testing and automatic test derivation. Furthermore, test generation algorithms proposed in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] are simple in their implementation and efficient in their execution. Hence, test purposes will be defined as some particular subtrees of the execution tree built from our trace model for components. We will then define an algorithm which will generate test cases from test purposes. As in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF], this algorithm will be given by a set of inference rules. Each rule is dedicated to handle an observation from the system under test iut or a stimulation sent by the test case to the iut. This testing process leads to a verdict about implementation correctness with respect to its associated specification. This generic conformance testing theory is the first step toward the testing of complex software systems made of interacting components.

Compositional testing theory

We further propose to define a compositional testing theory that aims to test an integrated system assuming that its underlying components have already been tested in isolation and are correct [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF]. The problem that we address can be seen as follows: if single components of a system conform to their specifications, what can be said concerning conformance of the whole system in accordance with its specification? We will show that a positive answer to this question cannot be obtained without any assumption about both specifications and implementations.

Strengthening components quality by means of projection mechanism

We propose a component-based approach to strengthen the quality of components taking into account their involvement in the global system that encapsulates them. The underlying idea consists in showing how to re-enforce the correctness of each component involved in a global system by generating suitable test cases for them. This will be done by defining a projection mechanism that, from a behaviour of the global system, will help to focus on behaviours of sub-systems that typically occur in the whole system [START_REF] Faivre | Symbolic model based testing for component oriented systems[END_REF].

Plan of the thesis

The rest of the thesis is split into three parts organized as follows.

Part I provides all theoretical notions we use in this thesis. It contains two chapters where we introduce basic notions of both category and coalgebra theories.

In Chapter II we describe the different basic concepts and notions of category theory that serves us as formal background in the remaining chapters.

In Chapter III we describe the basic concepts and notions of coalgebras that will be useful in this thesis.

Part II is the core of the modeling part. It contains two chapters where we introduce a formal framework to model and unify state-based systems, and a calculus of operators to combine components in order to build larger components.

In Chapter IV we define a generic formal framework to define components and their trace models by means of causal transfer functions. We also present some theoretical results regarding the existence and uniqueness of a final model in the category of components.

In Chapter V we describe the basic integration operators: cartesian product and both relaxed and synchronous feedback as well as how to combine them to build more complex integration operators. We also define the notion of a system that will be the result of the composition of basic components using complex integration operators.

Part III is the core of the testing part. It contains three chapters where we introduce a brief overview of black-box conformance testing, our generic conformance testing for components defined in Part II, and our compositional testing for component-based systems.

In Chapter VI we describe the formal testing background used in the remaining chapters of the thesis. We then introduce the testing concepts presented in the international standard IS-9646: "Conformance Testing Methodology and Framework" [START_REF]Information technology, Open Systems Interconnection. International standard IS 9646[END_REF][START_REF]Information Retrieval, Transfer and Management for OSI, Formal Methods in Conformance Testing[END_REF] and their formalization introduced in the setting of "Formal Methods in Conformance Testing" (FMCT) project [52].

In Chapter VII we present our generic conformance testing theory for components defined in Chapter IV. The work presented in this chapter is mainly inspired from the conformance testing theory developed in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF]. In our theory of conformance testing, behaviors of specifications and implementations under test are modeled as components over the signature H = T(Out × ) In , and the conformance relation is defined as a partial inclusion of their traces. We also present an algorithm for test case generation from the specification. This algorithm uses test purposes to eliminate the part of the specification which is not of interest for testing. The basic idea is to generate a finite computation tree from the specification of the system whose set of paths embodies the set of all behaviours of the specification. Test purposes are then used to tag a finite set of paths of interest of testing in the finite computation tree. Thereby, test cases will be generated by exploring the tagged finite computation tree starting from the initial state, and switching between sending stimuli to the implementation and waiting for output of the implementation according to certain inference rules as long as a verdict is not reached. At the end of the chapter, we show both correctness and completeness of generated test cases with respect to specifications and test purposes.

In Chapter VIII we present a compositional method for the testing of component-based systems described in Part II. The main idea is to apply "divide-and-conquer" approaches to global behaviour of a system from behaviours of its subsystems whose complexity is manageable. Instead of entirely testing the global system, the compositional testing approach we propose first decomposes the system under test into small subsystems and then tests each of them separately. The size of a subsystem is then smaller than the size of the whole system, and thus the risk of explosion of state space is significantly decreased.

We also propose a method for test purposes derivation for a given component of an integrated system from the behaviours of the components that constitute it. This last work is based on projection mechanisms that were first developed in [START_REF] Faivre | Symbolic model based testing for component oriented systems[END_REF].

Part I

Theoretical preliminaries

We introduce in this part the basic concepts of both category and coalgebra theories which will be useful throughout the thesis. We will rely on concrete examples to illustrate the expressive power of these two theories in systems modeling. Our aim therefore is to simply show that using these two theories, a unified formal framework for modeling state-based systems can be provided. For more interested readers, we refer to [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF][START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF][START_REF] Jacobs | Introduction to Coalgebra: Towards Mathematics of States and Observations[END_REF][START_REF] Pattinson | An introduction to the theory of coalgebras[END_REF][START_REF] Gumm | Elements of the general theory of coalgebras[END_REF][START_REF] Lane | Categories for the Working Mathematician, volume 5 of Graduate Texts in Mathematics[END_REF][START_REF] Barr | Category theory for computing science[END_REF].

Chapter II

Category theory Category theory is a branch of mathematics that was developed by MacLane and Barr [START_REF] Lane | Categories for the Working Mathematician, volume 5 of Graduate Texts in Mathematics[END_REF][START_REF] Barr | Category theory for computing science[END_REF] in 1940. Since its appearance, it has been used as a powerful tool allowing the generalization of the concept of algebraic structures such as vectorial spaces, groups, topological spaces, etc., and the relations between them. In this chapter we describe the most fundamental concepts of category theory that will be used to define our formal framework. These data have to satisfy the following laws:

-Associativity: if A f -→ B g -→ C h -→ D, then (h • g) • f = h • (g • f ) -Identity composition: if f : A -→ B, then f • id A = id B • f
Remark: in case of ambiguity, the operations of composition, the identities and the set of arrows are denoted by the name of the corresponding category i.e. we write: id C , f • C g and Hom C .

Example 1.1 As a concrete example, we consider a set of objects Obj = {A, B} and a set of arrows

Hom = { f : A -→ B, h : B -→ A, g : B -→ A, id A , id B } that are depicted in Figure II.1 (on the left side) such that: g • f = h • f = id A and f • h = f • g = id B A B f g h id A id B C D E f m id C g h id D id E Figure II.

-Examples of categories

These objects and arrows do not form a category. That is due to the fact that the property of associativity is not verified: there are three arrows f 1 , f 2 and f 3 such that the couples ( f 1 , f 2 ) and ( f 2 , f 3 ) can be composed and (

f 3 • f 2 ) • f 1 = f 3 • ( f 2 • f 1 ). For example: (h • f ) • g = id A • g = g h • ( f • g) = h • id B = h
Similarly to above, it is not hard to check that the objects and arrows that are depicted in Figure II.1 (on the right side) and satisfy (h

• f = g • f = m) form a category.

Constructions of categories

In this subsection, we describe some usual constructions of categories.

D: f • C g = f • D g.
We say that C is a full subcategory of D if C is a subcategory of D such that for each pair of objects A, B ∈ Obj(C), Hom C (A, B) = Hom D (A, B).

From any category C, it is possible to construct another category called dual of C by reversing all the arrows. That is to say, the source and the target of each arrow of C have to be reversed.

Definition 1.3 (The dual of a category)

Let C be a category. The dual (or opposite) of C, noted C op , is the category whose objects and arrows are the objects and arrows of C, but the domain and the codomain of each arrow have been reversed. Then we have: 3 If P is a poset, then the dual of the category P is the category determined by a poset P op : if (x, y) ∈ Hom P , then (y, x) ∈ Hom P op . For instance, the dual of the poset (Z, ≤) is (Z, ≥).

domain( f ) = A in C op if codomain( f ) = A in C codomain( f ) = A in C op if domain( f ) = A in C f = id A in C op if f = id A in C h = g • f in C op if h = f • g in C Example 1.

Properties of arrows

One of the principle characteristics of the theory of categories is its powerful unifying concepts across many branches of mathematics. This characteristic often leads to categorical definitions that do not involve the objects of a category in the sense that the property of one object is entirely defined in terms of the external interactions of that object with other objects.

In the following, we give the categorical definitions of some concepts that are standard in the set theory such as injectivity (monomorphism), surjectivity (epimorphism) and bijectivity (isomorphism). These definitions will be only defined with the concept of arrows of a category, without involving its objects (i.e. objects make no sense of such definitions).

Monomorphisms.

A function f : X -→ Y in Set is injective if for any element y in Y, there is at most one element x in X such that y = f (x). This concept of injective function can be easily redefined in the category theory without using elements of X or Y. This is done by replacing the elements of X by arbitrary arrows into X. Definition 1.4 (Monomorphism) Let C be a category and f : X -→ Y be a arrow of C. We say that f is a monomorphism (or monic) if for any object Z ∈ Obj(C) and any arrows g, h :

Z -→ X ∈ Hom C (Z, X): if f • g = f • h, then g = h. Z X Y h g f
We also say that f is left-cancellative.

Epimorphisms.

A function f : X -→ Y in Set is surjective if for any element in Y, there is at least one antecedent. Like injective functions, surjective functions can also only be redefined in terms of arrows as follows:

Definition 1.5 (Epimorphism) Let C be a category and f : X -→ Y be a morphism of C. We say that f is a epimorphism (or epic) if for any object Z ∈ Obj(C) and any arrows g, h :

Y -→ Z ∈ Hom C (Y, Z): if g • f = h • f , then g = h. X Y Z f g h
We also say that f is right-cancellative.

Isomorphism. The word "isomorphic" is usually used in mathematics to express distinction of objects in form, but not in number. Before stating its categorical definition, we give the following definition: Definition 1.6 (Section and retraction) Let C be a category and f : X -→ Y ∈ Hom C (X, Y):

-We say that an arrow r : Y -→ X is a section (or right inverse) of f , if f • r = id Y ; -We say that an arrow l : Y -→ X is a retraction (or left inverse) of f , if l • f = id X . Definition 1.7 (Isomorphism) Let C be a category and f : X -→ Y be an arrow of C. We say that f is an isomorphism if there exists an arrow g : Y -→ X ∈ Hom C (Y, X) such that g is both a section and a retraction of f i.e. :

f

• g = id Y and g • f = id X X Y X Y id X f id Y f g A function f : X -→ Y in
: Y -→ X such that their compositions f -1 • f = id Y and f • f -1 = id X .
Then, bijective functions in Set are obviously isomorphisms. However, a morphism which is both a monomorphism and an epimorphism is not necessarily an isomorphism (it is a bimorphism) unlike a bijection function which is both injective and surjective.

Example 1. 4 The inclusion of Z into Q in the category of abelian groups Ab is both a monomorphism and an epimorphism, but it is not isomorphism.

If there is such an isomorphism from X to Y, one often writes X ∼ = Y.

Universal properties

Universal properties are the properties that ensure existence and uniqueness of a given construction under some conditions. They are generally formalized as follows: for any . . . there is a unique . . . such that . . .

Commutative diagrams

Categorical properties are often expressed in terms of commuting diagrams. Informally, a diagram in a category C is an oriented graph whose nodes are labeled with objects of C and whose edges are labeled with arrows in C in such a way that source and target nodes of an edge are labeled with source and target objects of the labeling arrow. -A path in G is a non-empty sequence of edges such that the target node of each edge is the source node of the next edge in the sequence; -G is said to commute if, for every pair of nodes X, Y ∈ V, all paths between them lead to the same result by composition.

Hence, verifying in a category C that the diagram below is commutative is equivalent to verifying that

g 2 • f 1 = f 2 • g 1 . A B C D f 1 f 2 g 1 g 2 2.

Note:

The expression "up to isomorphism" means that if we have two constructions of such an object, there is one and only way to convert one into the other and vice-versa.

Example 2.1

In Set, the initial object is the empty set while any singleton set is a final object. As already stated, when reasoning at the level of a category C, its objects are abstracted away and their internal structures are not available. Hence, equality between the objects of a category makes no sense, the real criterion to distinguish them is the isomorphism. Then, objects that cannot be distinguished in such a category are called isomorphic. For instance, the sets {Hello}, {1000}, { * } or {Ok} are all isomorphic: just renaming all elements of a set does not really give us another set. From this point of view, the symbol1 = { * } has been chosen to denote the isomorphism class of all singletons. In other words, 1 is the final object in Set.

Product

Definition 2.4 (Product) Let C be a category. The product of two objects

X, Y ∈ Obj(C) is a new object X × Y ∈ Obj(C) with two projection morphisms π 1 : X × Y -→ X and π 2 : X × Y -→ Y which are universal: for each pair of morphisms f : Z -→ X and g : Z -→ Y in C, there is a unique morphism f , g : Z -→ X × Y in C, making the following diagram commute 1 : X X × Y Y Z π 1 π 2 f g f , g
Proposition 2.2 Let C be a category. Let X, Y ∈ Obj(C). If A is an object of C, π 1 : A -→ X and π 2 : A -→ Y two arrows of C, and ( f , g) → f , g a function that associates to each pair of arrows f : Z -→ X and g : Z -→ Y the arrow Z -→ A such that the following equations:

-

π 1 • f , g = f -π 2 • f , g = g -π 1 • π 2 = id A -f , g • ϕ = f • ϕ, g
• ϕ are satisfied for every objects Z and Z ′ , and for every arrows f : Z -→ X, g : Z -→ Y and ϕ : Z ′ -→ Z, then (A, π 1 , π 2 ) is a product of X and Y in C.

Example 2.2

The cartesian product of two sets X and Y is generally defined by: X × Y = {(x, y) | x ∈ X and y ∈ Y} This product can be easily redefined as an instance of the general notion of product of two objects of such a category. It is therefore defined by a triplet (X × Y, π 1 , π 2 ) such that π 1 and π 2 are projection functions defined by:

π 1 : X × Y -→ X π 2 : X × Y -→ Y (x, y) → x (x, y) → y
Given a set Z and two applications f : Z -→ X and g : Z -→ Y. It is not hard to see that there is a unique function f , g :

Z -→ X × Y such that π 1 • f , g = f , π 2 • f , g = g, π 1 • π 2 = id X×Y and f , g • h = f • h, g • h : Z ′ -→ X × Y where h : Z ′ -→ X × Y.
The product does not only apply to sets, but also to functions. For functions f : X -→ X ′ and g : Y -→ Y ′ , one has:

f × g : X × X ′ -→ Y × Y ′ given by (x, y) → ( f (x), g(x))
This can also be differently defined in terms of projection functions as follows:

f × g = f • π 1 , g • π 2 .
It is easily verified that the operation × on functions satisfies:

id X × id Y = id X×Y and ( f • h) × (g • k) = ( f × g) • (h × k)
Therefore, × applies both sets and functions, and preserves domains, identities and composition.

Coproduct

Every notion in category theory has its dual. Hence, the dual of product is coproduct. 3 Let C be a category. Let X, Y ∈ Obj(C). If A is an object of C, κ 1 : X -→ A and κ 2 : Y -→ A two arrows of C, and ( f , g) → [ f , g] a function that associates to each pair of arrows f : X -→ Z and g : Y -→ Z, the arrow A -→ Z such that the following equations:

-→ Z in C, there is a unique morphism [ f , g] : X + Y → Z in C, making the following diagram commute: X X + Y Y Z κ 1 κ 2 f g [ f , g] Proposition 2.
-[ f , g] • κ 1 = f -[ f , g] • κ 2 = g -[κ 1 • κ 2 ] = id A -ϕ • [ f , g] = [ϕ • f , ϕ • g]
are satisfied for every objects Z and Z ′ , and for every arrows f : X -→ Z, g : Y -→ Z and ϕ : Z -→ Z ′ , then (A, κ 1 , κ 2 ) is a coproduct of X and Y in C.

Example 2. 3 The coproduct (or sum, or disjoint union) of two sets X and Y is generally defined by:

X + Y = { 0, x | x ∈ X} ∪ { 1, y | y ∈ Y}
The components 0 and 1 are useful to force this union to be disjoint. They can be considered as tags used to recognize the elements of X and Y in X + Y. Like the cartesian product, the coproduct of two sets can be seen as an instance of the general definition of coproduct described above. It is therefore defined by a triple (X + Y, κ 1 , κ 2 ) such that κ 1 and κ 2 are coprojection functions defined by:

κ 1 : X -→ X + Y κ 2 : Y -→ X + Y x → 0, x Y → 1, y
Given a set Z and two applications f : X -→ Z and g : Y -→ Z. It is not hard to verify that there is a unique function

[ f , g] : X + Y -→ Z such that [ f , g] • κ 1 = f , [ f , g] • κ 2 = g, [κ 1 • κ 2 ] = id X+Y and h • [ f , g] = [h • f , h • g] : Z ′ → X + Y where h : Z -→ Z ′ .
The coproduct of two functions f :

X -→ X ′ and g : Y -→ Y ′ is f + g : X + X ′ -→ Y + Y ′ with: ( f + g)(u) = 0, f (x) if u = 0, x 1, g(y) if u = 1, y
This can also be differently defined in terms of coprojection functions as follows:

f + g = [κ 1 • f , κ 2 • g].
It is easy to verify that the operation + on functions preserves identities and composition:

id X + id Y = id X+Y and ( f • h) + (g • k) = ( f + g) • (h + k) 2.
f : Z × X -→ Y in C, there is a unique abstraction morphism Λ X ( f ) : Z -→ Y X , making the diagram commute: Y X × X Y Z × X ev Λ X ( f ) × id X f
Let us note here that the arrow Λ X : Z → Y X forms the terminal object in a category whose objects are the diagrams of the form:

A × X f -→ Y
and the arrows from an object A × X f -→ Y to an object B × X g -→ Y are the arrows ϕ : A -→ B such that the following diagram commutes:

A × X Y B × X f ϕ × id X g
Proposition 2. 4 Let C be a category with products ×. Let X, Y ∈ Obj(C). If Z is an object of C, ev : Z × X -→ Y an arrow of C and f → Λ X ( f ) a function that associates to every arrow f : A × X -→ Y, an arrow A -→ Z such that the following equations:

-ev

• (Λ X ( f ) × id X ) = f -Λ X (ev) = id Z -Λ X ( f ) • ϕ = Λ X ( f • (ϕ × id X )
) are satisfied for every object A and B, and for every arrow f : A × X -→ Y and ϕ : B -→ A, then (Z, ev) is an exponent of Y and X in C.

Example 2.4

Let us define the exponent of two sets X and Y as an instance of the general categorical definition of exponents given above. So, given two sets X and Y, the set of functions from X to Y can embody in the object Y X . This set is defined by:

Y X = { f | f : X -→ Y is a total function}
The evaluation function ev can be considered as the following application:

ev : Y X × X -→ Y ( f , x) → f (x)
which sends each pair ( f , x) to f (x), the value of f for x.

Now, let us consider the function f : Z × X -→ Y and then define the abstraction function Λ X ( f ):

Λ X ( f ) : Z -→ Y X z → (x → f (z, x)) which sends z ∈ Z to the function x → f (z, x) that maps x ∈ X to f (z, x) ∈ Y.
Let us verify that the exponent of two sets X and Y is defined by the triple (Y X , ev, Λ X ). For this, we need to prove the following equations:

ev • (Λ X ( f ) × id X ) = f (II.1) Λ X (ev) = id Y X (II.2) Λ X ( f ) • ϕ = Λ X ( f • (ϕ × id X )) (II.3)
hold for every arrow f : Z × X -→ Y and ϕ : Z ′ -→ Z.

For Equation II.1, one has: ev

• (Λ X ( f ) × id X )(z, x) = ev((x → f (z, x)), x) = f (z, x)
For Equation II.2, one has:

Λ X (ev)( f ) = (x → ev( f , x)) = f (x)
For Equation II.3, one has:

Λ X ( f ) • ϕ(z ′ ) = Λ X ( f )(ϕ(z ′ )) = (x → f (ϕ(z ′ ), x)) and Λ X ( f • (ϕ × id X ))(z ′ ) = (x → f • (ϕ × id X ))(z ′ , x) = (x → f (ϕ(z ′ ), x))
Thus, the exponent of two sets X and Y is defined by the triple (Y X , ev, Λ X ).

3 Functors and natural Transformations

Functors

The notion of functors has been defined as a generalization of functions in category theory. Hence, functors are structure-preserving maps between categories. They transpose the objects and arrows of a category to another one. A functor F from a category C to a category D then associates to each object X ∈ Obj(C) an object Y ∈ Obj(D) and to each arrow f : X -→ Y ∈ Hom C (X, Y) an arrow F( f ) ∈ Hom D (F(X), F(Y)), while preserving identity and composition of arrows.

-→ Y ∈ Hom C (X, Y) an arrow F X,Y ( f ) : F o (X) -→ F o (Y) in Hom D (F o (X), F o (Y)).
Both identity and composition properties have to be satisfied:

-For every object X ∈ Obj(C), F X,X (id C X ) = id D F o (X) ; -For every pair of morphisms f : X -→ Y and g : Y -→ Z, F X,Z (g

• C f ) = F Y,Z (g) • D F X,Y ( f ).
A functor is called endofunctor if it maps a category to itself.

In the following, the indexes o and X,Y of F o and F X,Y will be clarified when this is necessary in order to avoid any complications.

Example 3.1 (Forgetful functors) Forgetful functors are functors which send objects of a category to objects of another category by forgetting certain properties of objects. For example, the functor F : Grp -→ Set which maps a group to its underlying set while forgetting its mathematical structure and a group homomorphism to its underlying function of sets, is a forgetful functor.

Example 3.2 (Product, coproduct, exponent)

The product × (respectively the coproduct +) defined in Subsection 2.3 (respectively in Subsection 2.4) give rises to a functor × : Set × Set -→ Set, from the product category (respectively the coproduct category) of Set × Set of Set with itself, to Set. The exponent (defined in Subsection 2.5) is also a functor Set op × Set -→ Set which involves a dual category for its first argument.

In the following, we give three examples of functors:

Powersets

The powerset functor P : Set -→ Set maps any set X to its powerset i.e. the set of all subsets of X: P (X) = {U | U ⊆ X} and any function f : X -→ Y to the function:

P ( f ) : P (X) -→ P (Y) U ⊆ X → { f (x) | x ∈ U} = {y ∈ Y | ∃x ∈ X, f (x) = y ∧ x ∈ U}
The powerset operation is indeed a functor because it preserves identities and composition:

P (id X )(U) = {id X (x) | x ∈ U} = {y ∈ X | ∃x ∈ X, id X (x) = y ∧ x ∈ U} = {y ∈ X | ∃x ∈ X, x = y ∧ x ∈ U} = {x ∈ X | x ∈ U} = U (P (g) • P ( f ))(U) = {z ∈ Z | ∃y ∈ Y, g(z) = z, and ∃x ∈ X, f (x) = y and x ∈ U} = {z ∈ Z | ∃y ∈ Y, g( f (x)) = z and x ∈ U} = {z ∈ Z | ∃y ∈ Y, g • f (x) = z and x ∈ U} = P (g • f )(U)
Finally, the finite powerset of a set X will be denoted by P fin (X) = {U | U ⊆ X ∧ U finite}.

Free monoid

The free monoid functor Mon : Set -→ Set associates to any set X the set of all finite sequences over X (including the empty one):

Mon(X) = X * = { x 0 , x 1 , . . . , x n | ∀0 ≤ i ≤ n, x i ∈ X}
and to any function f : X -→ Y the function:

Mon( f ) = f * : Mon(X) → Mon(Y) x 0 , x 1 , . . . , x n → f (x 0 ), f (x 1 ), . . . , f (x n )

Polynomial functors and Kripke polynomial functors

Polynomial functors are functors Set -→ Set built up inductively from simple basic functors, using products, coproducts and exponents for forming new functors.

Definition 3.2 (Polynomial Functors)

The class of polynomial functors is inductively defined as the least collection of functors Set -→ Set satisfying the following clauses:

1. The identity functor id : Set -→ Set is a polynomial functor; 2. For any set K, the constant functor K : Set -→ Set is a polynomial functor. This functor maps every set X to K, and every function f : X -→ Y to the identity id K : K -→ K;

3. If F 1 and F 2 are polynomial functors, then their product F 1 × F 2 is also a polynomial functor. This functor 3 maps every set X to the product F 1 (X) × F 2 (X) and every function f to the product

F 1 ( f ) × F 2 ( f ); 4.
If F 1 and F 2 are polynomial functors, then their coproduct F 1 + F 2 is also a polynomial functor. This functor maps every set X to the coproduct F 1 (X) + F 2 (X) and every function f to the product F 1 ( f ) + F 2 ( f );

5. For any set E, if F is a polynomial functor, then the exponent F E is also a polynomial functor. This functor maps every set X to the exponent F(X) E and every function f : X -→ Y to the function

F( f ) E = F( f ) id E which maps h : E -→ F(X) to F( f ) • h : E -→ F(Y).
If we add both the power set functor and the free monoid functor, we obtain Kripke polynomial functors:

Definition 3.3 (Kripke polynomial functors)

The class of Kripke polynomial functors is the superset of polynomial functors obtained by the rules defined in Definition 3.2, with two additional rules:

1. If F is a Kripke polynomial functor, then the powerset P (F) is also 4 Kripke. This functor maps every set X to P (F(X)), and every function f to P (F( f )(X));

2. If F is a Kripke polynomial functor, then the free monoid Mon(F) is also Kripke polynomial functor. This functor maps every set X to Mon(F(X)), and every function f to Mon(F( f )(X)).

Occasionally, for technical reasons, we will need to restrict ourselves to the finite Kripke polynomial functors that are Kripke polynomial functors where all powersets P ( ) are finite powersets P fin ( ).

The category of category

The category of category, noted Cat, has all small categories as objects and all functors between such categories as arrows. The composition of two functors

F : A -→ B and G : B -→ C is G • F : A -→ C defined for any object A of A by G • F(A) = G(F(A)) and for any arrow f of A by G • F( f ) = G(F( f )).

Natural transformations

A natural transformation provides a way to transform one functor into another while respecting the structure of the categories involved. Given two parallel functors i.e. with the same domain and codomain:

C D F G
For each object X in C, we can associate two objects F(X) and G(X) in D that should be the source and the target of an arrow τ X :

F(X) -→ G(X) in D: X F(X) G(X) F G τ X
Thus, we have a collection of arrows τ X : F(X) -→ G(X) ∈ D, indexed by objects X ∈ Obj(C). This collection is called a natural transformation from F to G. Hence, natural transformations define morphisms between functors.

τ Y • F( f ) = G( f ) • τ X for every arrow f : X -→ Y in C. X Y F(X) G(X) F(Y) G(Y) C D f F G τ X F( f ) τ Y G( f ) F G Note: τ X is called the component at X of the natural transformation τ.
Example 3.3 Consider the finite powerset functor P fin : Set -→ Set and the free monoid functor Mon : Set -→ Set. There is a natural transformation τ : Mon =⇒ P fin that associates to every set X a function τ X : Mon(X) -→ P fin (X) which is defined for every sequence x 0 , x 1 , . . . , x n ∈ Mon(X) by: τ X ( x 0 , x 1 , . . . , x n ) = {x 0 , x 1 , .

-→ Y: X Y Mon(X) P fin (X) Mon(Y) P fin (Y) f Mon P fin τ X Mon( f ) τ Y P fin ( f ) Mon P fin
That is to say, for each sequence x 0 , x 1 , . . . , x n ∈ Mon(X), one has:

(τ Y • Mon( f ))( x 0 , x 1 , . . . , x n ) = (P fin ( f ) • τ X )( x 0 , x 1 , . . . , x n ) (τ Y • Mon( f ))( x 0 , . . . , x n ) = τ Y (Mon( f )( x 0 , . . . , x n ) = τ Y ( f (x 0 ), . . . , f (x n ) ) = { f (x 0 ), . . . , f (x n )} (P fin ( f ) • τ X )( x 0 , . . . , x n ) = P fin ( f )(τ X ( x 0 , . . . , x n )) = P fin ( f )({x 0 , . . . , x n }) = { f (x 0 ), . . . , f (x n )}

Heterogeneous Compositions

Functor categories

Given three parallel functors: F, G and H from C to D and two natural transformations between them: τ : F =⇒ G and τ ′ : G =⇒ H such that for each X ∈ Obj(C), one has (τ

• τ ′ ) X = τ X • τ ′ X : F(X) G(X) H(X) τ X τ ′ X (τ ′ • τ) X
We can form a new category called functors category and noted C D having as objects all functors from C to D and as arrows the natural transformations between those functors. It is obvious that the composition of natural transformations is a natural transformation, that this composition is associative, and that any identity natural transformation acts as a unit.

Heterogeneous compositions

Natural transformations may be composed with functors to get new natural transformations. Let C, D, C ′ and D ′ be categories, let F, F ′ : C -→ D, G : C ′ -→ C and G ′ : D -→ D ′ be functors and let τ : F =⇒ F ′ be a natural transformation as the following diagram shows:

C ′ C D D ′ G ′ F F ′ G τ
There are two ways to compose natural transformations and functors:

1. Composing G with τ leads to a new natural transformation from G • F to G • F ′ that is usually noted Gτ (not G • τ)
in order to distinguish it from the usual composition. This is a composition of heterogeneous objects. It is not hard to see that Gτ makes the following diagram commute:

X Y (G • F)(X) (G • F ′ )(X) (G • F)(Y) (G • F ′ )(Y) f G • F G • F ′ (Gτ) X (G • F)( f ) (Gτ) Y (G • F ′ )( f ) G • F G • F ′
Let us note here that the functor G impacts only arrows. That is to say that the composition is only made between the "arrow function" of F and the natural transformation τ.

Composing τ with

G ′ leads to a new natural transformation from F • G ′ to F ′ • G ′ making the following diagram commutes: X Y (F • G ′ )(X) (F ′ • G ′ )(X) (F • G ′ )(Y) (F ′ • G ′ )(Y) f F • G ′ F ′ • G ′ (τ G ′ ) X (F • G ′ )( f ) (τ G ′ ) Y (F ′ • G ′ )( f ) F • G ′ F ′ • G ′
Let us note here that the functor G ′ impacts only on objects. That is to say the composition is made between the natural transformation τ and the "object function" of G ′ . For this reason, we write τ G ′ instead of τG ′ (i.e. τ is indexed by G ′ ).

Monads in category theory

Monads are a categorical tool that was first introduced in the 80 ′ s by Moggi in order to develop a categorical semantics of computations for programming languages [START_REF] Moggi | Notions of computation and monads[END_REF][START_REF] Moggi | Computational lambda-calculus and monads[END_REF]. Later, in the 90 ′ s, monads received much attention from the community of functional programming languages because they have shown their suitability for sequentially combining computations into more complex computations [START_REF] Wadler | Comprehending monads[END_REF][START_REF] Wadler | Monads for functional programming[END_REF]. They were then used to introduce aspects of imperative programming languages such as input/output (I/O) operations, state updating, exceptions, nondeterminism, etc., in functional programming languages. More precisely, they allow the explicit addition, to functional programming languages, of concepts which they lack such as side effects. Consequently, monads can then sequentially build severals kinds of computation effects such as non-determinism, partiality, exception, etc., flexibly.

Definition

T T • T T T Tη ηT µ 1 1 T • T • T T • T T • T T Tµ µT µ µ
η is called the unit of the monad. Its components map objects in C to their naturally structured counterpart. µ is the multiplication of the monad. Its components map objects with two levels of structure to objects with only one level of structure. The first condition states that a doubly structured object η T(X) (x) built by η from a structured object x, is flattened by µ to the same structured object as a structured object T(η X )(x) made of structured objects built by η. The second condition states that when flattening two levels of structure, we get the same result by flattening the outer structure first (with µ T(X) ) or the inner structure first (with T(µ X )).

In the following, we will often simply write T 2 for T • T and T 3 for T • T • T.

A working example

Let us consider a monad built on the powerset functor P : Set → Set. For every set X, the component η X : X -→ P (X) of the unit of this monad has to build a set of elements from an element of X. We can choose η X : x → {x} that maps every element x ∈ X to the singleton {x}. On the other hand, for every set X, the component µ X : P (P (X)) -→ P (X) of the multiplication of this monad has to flatten a set of sets of elements of X into a set of elements. In order to define µ, we need to understand the nature of P 2 (X). Indeed, P 2 is the set of all subsets not formed by elements of X, but by elements of P (X). There is a set with two levels of nesting. For instance, x, y and z are elements of X, the sets {x, y}, {z} and {x} are elements of P (X), and the sets {{x, y}, {z}} and {{x}} are elements of P 2 (X). The multiplication of the monad simply consists in transforming a set of subsets of X into a set of X i.e. it flattens all subsets of X into one set by omitting a nesting level. For instance:

µ X ({{x, y}, {z}}) = {x, y, z}
Formally, µ is defined by:

µ : P 2 (X) → P (X) U → u∈U (u)
To check that η and µ are natural transformations, it is enough to show that the following diagrams commute.

P (P (P (X))) P (P (X))

P (P (X)) P (X) P (µ X ) µ P (X) µ X µ X P (X) P (P (X)) P (X) P (X) P (η X ) η P (X) µ X 1 1
The diagram depicted on the left side can be read as follows: given a set of three levels of parentheses, remove the inner parentheses, then the intermediate parentheses (that become inners after the first operation), or remove the intermediate parentheses, then the inner parentheses will get the same result. For example, for a set X = {x, y, z, t}, one has:

{{{x, y}, {z}}, {{t}}} {{x, y, z}, {t}} {{x, y}, {z}, {t}} {x, y, z, t}

P µ X µ P (X) µ X µ X
Similarly, the diagram depicted on the right side can be read as follows: given a set of elements {x 0 , . . . , x n } of a set X, first return the singleton containing the set {x 0 , . . . , x n } (i.e. add a paren- thesis from the outside to {x 0 , . . . , x n }) and then reduce the obtained singleton {{x 0 , . . . , x n }} by µ X , or first return the set {{x 0 }, . . . , {x n }} obtained after applying η X to every element of {x 0 , . . . , x n } and then reduce the obtained result {{x 0 }, . . . , {x n }} by µ X will lead to the same result which is {x 0 , . . . , x n }. For example, for a set X = {x, y, z}, one has:

{x, y, z} {{x}, {y}, {z}} {x, y, z}

P (η X ) µ X id {{x, y, z}} {x, y, z} {x, y, z} η P (X) µ X id
Let us now verify that the above diagrams commute: given that for any morphism f : X -→ Y, P ( f ) : P (X) -→ P (Y) is the morphism which maps each part of X to its image by f . We must check that:

µ • ηP = µ • P η = 1 (II.4) µ • µP = µ • P µ (II.5)
For Equation II.4, we have:

µ X • η P (X) : P (X) η P (X) ---→ P (P (X)) µ X -→ P (X) {x 1 , . . . , x i . . .} {{x 1 , . . . , x i . . .}} {x 1 , . . . , x i . . .} µ X • P (η X ) : P (X) P (η X ) ---→ P (P (X)) µ X -→ P (X) {x 1 , . . . , x i . . .} {{x 1 }, . . . , {x i }, . . .}} {x 1 , . . . x i , . . .}
For Equation II.5, we have: The powerset monad is usually used to model non-deterministic state machines by replacing the target state of a transition by a set of possible target states. Intuitively, the unit η allows us to add a non-deterministic behaviour to every state as a trivial non-determinism (with only one possibility to choose). The multiplication µ allows us to obtain the successors of the successor states of each state, abstracting away internal states:

µ X • µ P (X) : P 3 (X) µ P (X) ---→ P 2 (X) µ X -→ P (X)
µ X • P (µ X ) : P 3 (X) P (µ X ) ---→ P 2 (X) µ X -→ P (X)
s 010 s 01j s 01 s 01m s 0 s 0i . . . µ(s 0 ) =⇒ s 0n s 0n0 s 0nk s 0nl s 010 s 01j s 01m s 0 . . . s 0n0 s 0nk s 0nl

More examples

We describe here a few usual monads.

Partial

The partial monad (or maybe, or also deadlock) is defined by the triplet (id + 1, η, µ) with:

id + 1 : Set -→ Set is the functor that maps a set X to (id + 1)(X) = X ⊥ = X ∪ {⊥} and that sends a function f : X -→ Y to a function :

(id + 1)( f ) : X ∪ {⊥} -→ Y ∪ {⊥} given by: ⊥ → ⊥ and x → f (x)
where 1 is the singleton set whose only element is ⊥.

-For every X, the unit η X : X -→ X ⊥ is the canonical inclusion that maps every element x ∈ X to itself;

-For every X, the multiplication µ X : X ⊥ -→ X ⊥ is the application defined as follows:

µ X : X ⊥ → X ⊥ ⊥ → ⊥ x → x
The monad partial is usually used to model objects that evolve and can be interrupted or disappear at any time. For example, systems that evolve by moving to successor states, and for which we cannot guarantee whether their execution will be normally terminated. There is a deadlock state in which the system runs in unsafe state. Then, the state space X is extended to X ⊥ by adding the special symbol ⊥ to signal explicitly deadlock states.

Ordered nondeterminism

The ordered nondeterminism (or sequence) is defined by the triplet (id * , η, µ) with:

id * : Set -→ Set is the functor that maps a set X to id * (X) which is the set of all lists that can be recursively formed with the elements of X and the usual list operations. As well, the functor id * associates to a function f : X -→ Y a function:

id * ( f ) : id * (X) → id * (Y) [x 0 , . . . , x n ] → [ f (x 0 ), . . . , f (x n )]
-For every X, the unit is the singleton list constructor. It is an application η X : X -→ id * (X) mapping every element x ∈ X to the list [x];

-For everyX, the multiplication µ X : id * (id * (X)) -→ id * (X) is the application that flattens out a list of lists of elements in list of elements, by removing all inner "square brackets". For example, it transforms

[[x, y, z], [t]] into [x, y, z, t].
Formally, this application is defined by:

µ X : id * (id * (X)) → id * (X) [[x 11 , . . . , x 1n 1 ], . . . , [x m1 , . . . , x mn m ]] → [x 11 , . . . , x 1n 1 , . . . , x m1 , . .

. , x mn m ]

The ordered nondeterminism monad is usually used in cases where there is a set of possibilities ordered from a certain perspective, and that requires an exhaustive exploration of all these possibilities. For example, a system that has possible input signals at any given time, and only one of them has to be taken. Hence, this entails an ordered view of nondeterminism. A possible choice may be then "all inputs are possible", but their probability decreases (or increases) depending on their lengths.

Exception

The exception monad is defined by the triplet (id + E, η, µ) with:

-id + E : Set -→ Set is the functor that maps a set X to (id + E)(X) = X ∪ E and a function f : X -→ Y to (id + E)( f ) = f + id E ;
-For every X, the unit η X : X -→ X ∪ E is the injective application maping every x ∈ X to itself;

-For every X, the multiplication µ X :

(id + E)((id + E)(X)) -→ (id + E)(X)
is the application defined as follows:

µ X : (id + E)((id + E)(X)) → (id + E)(X) e → e x → x
The exception monad is usually used to handle exceptions in many programming languages.

Programs may indeed terminate "abruptly" because of an exception. Then, from this point of view, monads allow us to model computations that either normally succeed, moving to a successor state from a given state, or fail raising an exception e ∈ E.

Note first that the partial monad can be seen as a particular instance of the exception monad. It is enough to instantiate E with 1. Second, non-termination (deadlock state) is basically different from exceptions. That is: once a computation is blocked, it blocks forever. There is no way to get out of the deadlock state. However, using a suitable exception handler, normal termination can be restored when a system "exceptionally" terminates.

Category of Kleisli

There is an alternative description of monads to represent computations: Kleisli triple. Formally, Kleisli triples are defined as follows: Definition 4.2 (Kleisli triple) A Kleisli triple over a category C is a triple (T, η, * ) where T : Obj(C) -→ Obj(C) is an object mapping, η X : X -→ TX is a Obj(C)-indexed mapping in X ∈ Obj(C), and * is an operator that assigns to each function f : X -→ TY a function f * : TX -→ TY such that:

-η * X = id TX ; -f * • η X = f for f : X -→ TY; -g * • f * = (g * • f ) * for f : X -→ TY and g : Y -→ TZ.
From any Kleisli triple (T, η, * ) over C, we can define a new category called Kleisli category and noted Kl T (C) [57]. -The objects of Kl T (C) are those of C;

-The morphisms X -→ Y from X to Y in Kl T (C) are the morphisms X -→ TY from X to TY in C;

-For every object X, the identity id

X : X -→ X in Kl T (C) is the morphism η X : X -→ TX in C;
-For every pair of morphisms f : X -→ Y and g :

Y -→ Z in Kl T (C), the composite of g • f : X -→ Z in Kl T (C) is defined in C as follows: g • f : X f -→ TY Tg -→ TTZ µ -→ TZ TTZ TY TZ X Y g µ Z Tg f
It is not hard to see that the data of this definition form a category. Indeed, the following properties are verified:

-Compositionality of arrows: for each pair of arrows f :

X -→ Y and g : Y -→ Z in Kl T (C), there is a composite arrow g • f : X -→ Z in Kl T (C).
This property is ensured by the operations of the monad T as shown in the last point of the above definition.

-Associativity of the composition: if

X f -→ Y g -→ Z h -→ D, then (h • g) • f = h • (g • f ).
To verify this property, it is enough to consider the following diagram in C, and show that the two morphisms from X to TD coincide.

T 3 D T 2 Z T 2 D TY TZ TD X Y Z D Tµ µ µ f Tg T 2 h g Th g h
Example 4.1 (Rel Category) Consider the Rel category of sets and relations. Its objects are ordinary sets, and its arrows X -→ Y are binary relations R ⊆ X × Y. The composition of two relations R 1 :

X -→ Y and R 2 : Y -→ Z is given by: R 2 • R 1 = {(x, z) ∈ X × Z | ∃y ∈ Y such that (x, y) ∈ R 1 and (y, z) ∈ R 2 }
The Rel category can be obtained from the Set category as the Kleisli category Kl T (C) for the monad whose functor corresponds to powerset. Then, instantiating the monad T with the powerset monad P, the kleisli category Kl P (Set) becomes equivalent to the Rel category. Indeed, a relation R ⊆ X × Y can be seen as a function from X to P (Y). Then, given a function X -→ Y in Set, its corresponding in

Kl P (Set) is the relation R f = {(x, y) | y = f (x)}.
This lifting from Set to Kl P (Set) is therefore done via the functor Graph : Set -→ Kl P (Set) which maps a set X to itself Graph(X) = X, and a function f Manes [59] has shown the equivalence between monads and Kleisli triples. Given a Kleisli triple (T, η, * ) the corresponding monad is (T, η, µ) where T is the endofunctor over C that extends the function T and maps any function f : X -→ Y to (η Y • f ) * , and the multiplication µ X acts as id * TX for every set X. Conversely, given a monad (T, η, µ), the corresponding Kleisli triple is (T, η, * ) where T is the restriction of the endofunctor T to objects, and

: X -→ Y to its graph relation Graph( f ) = {(x, y) | y = f (x)} ⊆ X × Y. E.
f * = µ Y • (T f ) for every function f : X -→ TY.

5.1

Proof by bisimulation .

. . 66

Coalgebra theory was first introduced in computer science during the 80 ′ s by Arbib and Ernest in [START_REF] Arbib | Machines in a category[END_REF][START_REF] Manes | Algebraic approaches to program semantics[END_REF] as an abstract formalism for describing state-based systems such as automata (in various forms) and transition systems. Later, coalgebra theory emerged, and rapidly became a powerful tool in different areas of computer science. Indeed, during the 1990 ′ s, a step in the formalization of concepts of classes and objects in object-oriented programming was achieved thanks to this theory [START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF]8,[START_REF] Aczel | Non-Well-Founded Sets[END_REF][START_REF] Aczel | Final universes of processes[END_REF]. Since then, coalgebras have shown that they are suitable mathematical structures to model and unify state-based dynamic systems. They provide a theoretical framework offering an excellent modeling tool whose effectiveness can describe a large family of state-based systems and prove their properties. In fact, the characteristics of modern systems viewed not from the point of view of how they are built, but of the results they produce, are hardly definable (or even simply not definable) by standard formalisms such as first order or equational logic. From this point of view, the theory of coalgebras can be seen as the dual of that of algebras. Then, algebras are used to build objects, by constructors, that are considered different if differently constructed. On the contrary, coalgebras are used to observe (or decompose) objects, by observers (or destructors), that are considered different when they can be distinguished by observation. So the difference between the two approaches is intuitively expressed as follows: one shows the construction part of a system, the other shows the observation part of it. For example, given a set E, in the algebraic approach, finite lists over E can be inductively constructed using the two operations: nil : 1 -→ E * and cons : E × E * -→ E * . The nil operation generates an empty list from nothing and the cons operation adds an element to the list. However, the infinite lists over E cannot be built in this way. One can only observe their elements. Hence, an infinite list can be thought of as a black box with a set of internal states S and two operations obs : S -→ E and next : S -→ S that associate respectively to each state s ∈ S an observation and its successor state.

Coalgebra definition

Coalgebras can be seen as an abstraction of dynamical and reactive systems, behaviours are well described by transition functions (i.e. automata) of all kinds. A coalgebra consists1 of a set S of states equipped with a transition function α : S -→ FS where F : Set -→ Set is an endofunctor on the category of sets, defining the signature of the coalgebra. Hence, α provides the set of states S with some structures. Unlike algebraic operations that enable us to recursively build complex objects from basic objects given by signatures, coalgebra operations are a means to observe system states. More formally, we have: Definition 1.1 (Coalgebra) Let F : Set -→ Set be a functor called signature functor. A coalgebra for F, or F-coalgebra is any couple (S, α) where:

-S is a set whose elements are called states; α : S -→ FS is a mapping called transition function.

In the following, we give some classical examples of formalism semantics which can be defined in terms of coalgebras.

Streams

Streams are used to model continuous input, behaviour of state-based systems, finite or infinite sequences, etc. They are especially useful in modeling behaviour of dynamical systems. As an example, consider a deterministic transition system with output [START_REF] Plotkin | A structural approach to operational semantics[END_REF] S that behaves as follows: in state s, it either goes into the next state s ′ of s, producing an output o as the "observable effect" of the state transition, or it fails and then, its execution is terminated. Such a system is usually considered as a black box which can produce outputs, by moving from one state to another. The behaviour of such a system is called stream automata and consists of a set of internal states S with two operations acting on the state space S:

obs : S -→ Out and next : S -→ S
The operation obs associates to every state s ∈ S the corresponding output o ∈ Out while the operation next : S → S maps every state s ∈ S to a successor state s ′ ∈ S. We distinguish two cases:

-If the computation is infinite (the system is running forever), we consider this kind of systems as coalgebras:

(S, obs, next :

S → A × S)
of the functor F defined by FX = A × X -If the computation is finite (the execution is terminated), we consider this kind of systems as coalgebras:

(S, obs, next : S → A × (S ∪ {⊥}))

of the functor F defined by FX = A × (X + 1).

Mealy Machines

Mealy machines can be seen as stream automata, which also accept environment input. A Mealy automata is indeed a deterministic automaton with inputs and outputs in which output values are determined both by the current state and the input values [START_REF] Mealy | A method for synthesizing sequentiel circuits[END_REF][START_REF] Eilenberg | Automata, Languages and Machines[END_REF][START_REF] Lee | Principles and methods of testing finite state machines-a survey[END_REF]. It is usually defined as consisting of a set S of states, a set In of input labels, a set Out of output labels, an output function obs : S × In -→ Out associating an output to every state s depending on its current input, and finally a transition function next : S × In -→ S mapping every state to its successor state. Note the typical feature of state-based systems is that one can observe the state space by means of functions with the state space as domain. In fact, Mealy automata are naturally in coalgebraic setting because the state space S can be considered as a black box and the functions obs and next can be combined using the cartesian product as a single function:

obs, next : S × In -→ Out × S which can be also written, using the technique of currying, as a single function with domain S:

obs, next : S -→ (Out × S) In
Thus, Mealy automata are coalgebras:

(S, obs, next : S → (Out × S) In )
of the functor F defined by FX = (Out × X) In .

Labeled Transition Systems (LTS)

A labeled transition system (LTS) is simply an automaton labeled by actions, and which has no final state [START_REF] Arnold | Comportements de processus[END_REF][START_REF] Brookes | An Improved Failures Model for Communicating Processes[END_REF]. Formally, it is a tuple (S, A, R) where S is a set of states, A = σ ∪ {τ} is a set of observable actions Σ and unobservable2 actions {τ} and R is the transition relation between states. The relation R can be replaced by a function. Such a binary relation R ⊆ X × Y whose domain is X and codomain is Y can indeed be commonly seen as a part of the cartesian product X × Y. The relation R can be then written as a function sending every element of X to a subset of the powerset P (A × Y) of A × Y. Thus, labeled transition systems are coalgebras:

(S, α : S → P (A × S))
of the functor F defined by FX = P (A × S).

For technical reasons, another class of labeled transition systems called finitely branching transition systems has been defined. Every finitely branching transition system is bounded. That is for all state s ∈ S, the set

{(a, s ′ ) | s a -→ s ′ } is finite
Such systems can be identified with coalgebras:

(S, α : S -→ P fin (A × S))

where P fin is the finite powerset functor.

Input-Output Labeled Transition Systems (IOLTS)

Many variants of LTS, that make distinction between input and output actions, have been introduced over the years 1990 in order to respond to technical testing requirements that we will address later in Chapter VII. For instance, Input-Output Automata (IOA) [START_REF] Lynch | An introduction to input/output automata[END_REF], Input-Output State Machines (IOSM) [START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF], Input-Output Transition Systems (IOTS) [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF][START_REF] Tretmans | Testing labeled transition systems with inputs and outputs[END_REF], Input-Output Labeled Transition Systems (IOLTS) [START_REF] Jéron | Contribution à la génération automatique de tests pour les systèmes réactifs[END_REF]. These models are very similar theoretically. We then consider modeling coalgebraically the IOLTS model since it is the most widely used for the purpose of testing. Formally, an IOLTS is a variant of LTS, where the set of observable actions Σ is partitioned into input and output actions i.e. Σ = Σ ! ∪ Σ ? ∪ {τ}. Classically, in order to distinguish the input actions from the output actions, input actions (resp. output actions) are marked with the symbol ? (respectively the symbol !). Similarly to LTSs, IOLTSs are coalgebras

(S, α : S -→ P ((Σ ? ∪ Σ ! ∪ {τ}) × S))
of the functor F defined by FX = P ((Σ ? ∪ Σ ! ∪ {τ}) × S).

Morphisms

The easiest way to describe the relation between the different coalgebras of a given functor is via morphisms. A morphism from one coalgebra to another is an arrow between their state sets which preserves coalgebraic structures. If (S, α) and (S ′ α ′ ) are two coalgebras of a functor F, an application h : S -→ S ′ is a morphism of coalgebras if h transforms the states of S into those of S ′ and if F(h) transforms the transitions of S into those of S ′ with respect to the following constraint: if there is a transition tr between two states of S, then there must be a transition tr ′ between the two corresponding states in S ′ .

Definition 2.1 (Morphisms of coalgebras)

Let F : Set -→ Set be a functor. Let (S, α) and (S ′ , α ′ ) be two F-coalgebras. A morphism of coalgebras is a function h : S -→ S ′ making the following

diagram commute i.e. α ′ • h = F(h) • α. S S ′ F(S) F(S ′ ) h F(h) α α ′
Now, let us consider a concrete example to better illustrate the notion of a morphism of coalgebras. Figure III.1 depicts two label transition systems LTS and LTS ′ with the same set A = {a, b} of labels. As one has already seen in Section 1.3, labeled transition systems are coalgebras of the functor P (A × ) with A as the set of labels. Then, LTS and LTS ′ are respectively described as coalgebras C = (S, α) and C ′ = (S ′ , α ′ ) as shown in Table III. 1.

The initial states of LTS and LTS are respectively s 0 and s ′ 0 that are drawn as circles with a thick border.

A morphism from LTS to LTS ′ is then a mapping h : S -→ S ′ such that the above diagram commutes i.e. F(h)

• α = α ′ • h where F(h) : P (A × S) -→ P (A × S ′ ) is defined for each U ⊆ A × S by: F(h)(U) = {(a, h(s)) ∈ A × S ′ | (a, s) ∈ U} s 0 s 1 s 2 a a b b s ′ 0 s ′ 1 a b Figure III.1 -Graphical representation of LTS and LTS ′ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ ❵ Characteristics Model LTS LTS' Set of labels A = {a, b} A = {a, b} State space S = {s 0 , s 1 , s 2 } S ′ = {s ′ 0 , s ′ 1 } Transitions Function α : S -→ P ({a, b} × S) α ′ : S ′ -→ P ({a, b} × S ′ ) s 0 → {(a, s 1 ), (a, s 2 )} s ′ 0 → {(a, s ′ 1 )} s 1 → {(b, s 2 )} s ′ 1 → {(b, s ′ 1 )} s 2 → {(b, s 2 )} Table III.1 -LTS and LTS ′
In our example, h is the mapping depicted with dotted line in Figure III. 1. It is defined as follows:

h(s 0 ) = s ′ 0 and h(s 1 ) = h(s 2 ) = s ′ 1
In order to prove that h is a morphism from LTS to LTS ′ , it is enough to verify that the following diagram is commutative:

{s 0 , s 1 , s 2 } {s ′ 0 , s ′ 1 } P ({a, b} × {s 0 , s 1 , s 2 }) P ({a, b} × {s ′ 0 , s ′ 1 }) h P (id A × h) α α ′
Hence, we must check that for each state s ∈ S, one has (α

′ • h)(s) = (P (id A × h) • α)(s). (α ′ • h)(s 0 ) = α ′ (h(s 0 )) = α ′ (s ′ 0 ) = {(a, s ′ 1 )} = P (id A × h)({(a, s 1 ), (a, s 2 )}) = P (id A × h)(α(s 0 )) = (P (id A × h) • α)(s 0 ) (α ′ • h)(s 1 ) = α ′ (h(s 1 )) = α ′ (s ′ 1 ) = {(b, s ′ 1 )} = P (id A × h)({(b, s 2 )}) = P (id A × h)(α(s 1 )) = (P (id A × h) • α)(s 1 ) (α ′ • h)(s 2 ) = α ′ (h(s 2 )) = α ′ (s ′ 1 ) = {(b, s ′ 1 )} = P (id A × h)({(b, s 2 )}) = P (id A × h)(α(s 2 )) = (P (id A × h) • α)(s 2 )
Let us note that F-coalgebras with morphisms between them constitute a category, which noted CoAlg(F). Indeed, there is a forgetful functor CoAlg(F) -→ Set mapping a F-coalgebra (S, α) to its state space S, and a F-morphism coalgebra h to itself.

Bisimulation

The notion of bisimulation was first introduced by Milner for the calculus of communicating systems (CSS) language [START_REF] Milner | A calculus of communicating systems[END_REF][START_REF] Milner | Communication and concurrency[END_REF], and it is usually defined as follows: a bisimulation between two labeled transition systems (S, A, T) and (S ′ , A, T ′ ) is a relation R ⊆ S × S ′ such that for every pair of states (s, s ′ ) ∈ R, the two conditions are satisfied:

-For each transition (s, a, q) ∈ T, there is a state q ′ ∈ S ′ such that (s ′ , a, q ′ ) ∈ T ′ and (q, q ′ ) ∈ R, and -Symmetrically, for each transition (s ′ , a, q ′ ) ∈ T ′ , there is a state q ∈ S such that (s, a, q) ∈ T and (q, q ′ ) ∈ R.

Given two states s ∈ S and s

′ ∈ S ′ , s is bisimilar to s ′ , written s ∼ s ′ , if there is a bisimulation R such that (s, s ′ ) is in R.
This notion of bisimulation was redefined in terms of coalgebras as follows: Given a functor F and two F-coalgebras (S, α) and (S ′ , α ′ ). A relation R ⊆ S × S ′ is a bisimulation between S and S ′ if there exists a coalgebra (R, γ : R -→ F(R)) such that the projections π 1 : R -→ S and

π 2 : R -→ S ′ are morphisms of F-coalgebras. S R S ′ F(S) F(R) F(S ′ ) π 1 π 2 F(π 1 ) F(π 2 ) α γ α ′
We detail in the following some examples of bisimulation.

Stream

A bisimulation R ⊆ S × S ′ between two automata streams (S, obs, next : S -→ A × S) and (S ′ , obs ′ , next ′ : S ′ -→ A × S ′ ) is a coalgebra (R, γ : R -→ (A × R)) such that the function γ has to satisfy the following propriety: for all pair of states (s, s ′ ) ∈ S × S ′ , we have:

γ((s, s ′ )) = (a, (next(s), next(s ′ ))) such that    obs(s) = obs(s ′ ) = a (next(s), next(s ′ )) ∈ R
In order to verify that R is a stream bisimulation between S and S ′ , we have to prove that the projection π 1 (respectively π 2 ) is a morphism of coalgebras from (R, γ) to (S, obs, next ) (respectively from (R, γ) to (S ′ , obs ′ , next ′ )). Hence, we must check:

obs, next • π 1 = F(π 1 ) • γ (III.1) obs ′ , next ′ • π 2 = F(π 2 ) • γ (III.2)
For Equation III.1, for each pair of states (s, s ′ ) ∈ R, one has:

( obs, next • π 1 )((s, s ′ )) = obs, next (π 1 ((s, s ′ ))) = obs, next (s) = (obs(s), next(s)) (F(π 1 ) • γ)((s, s ′ )) = (F(π 1 )(γ((s, s ′ ))) = F(π 1 )(obs(s), (next(s), next ′ (s ′ ))) = (obs(s), next(s))
Similarly we obtain Equation III.2.

Mealy machines

A bisimulation between two Mealy automata:

(S, obs, next : S -→ (Out × S) In ) and (S ′ , obs ′ , next ′ : S ′ -→ (Out × S ′ ) In ) is a coalgebra (R, γ : R -→ (Out × R)
In ) such that its transition function γ is defined for each pair of states (s, s ′ ) ∈ R and for each input i ∈ In by:

γ((s, s ′ ), i) = (o, (next(s)(i), next ′ (s ′ )(i)))
where o = obs(s

)(i) = obs ′ (s ′ )(i) and (next(s)(i), next ′ (s ′ )(i)) ∈ R.

Labeled transition systems

Two labeled transition systems are bisimilar if their labeling is equivalent, and their behaviour cannot be distinguished. A bisimulation R ⊆ S × S ′ between two labeled transition systems (S, α) and (S ′ , α ′ ) over P (A × ) where A is the set of labels, is a coalgebra

(R, γ : R -→ P (A × R))
where γ is the function defined for each pair of states (s, s ′ ) ∈ R by:

γ((s, s ′ )) = {(a, (q, q ′ )) | (a, q) ∈ α(s), (a, q ′ ) ∈ α ′ (s ′ ) and (q, q ′ ) ∈ R}
Let us illustrate this definition by a concrete example. Consider again the two labeled transition systems LTS and LTS ′ depicted in Figure III. 1. In order to prove that LTS and LTS ′ are bisimilar we first have to choose an appropriate relation R and then to check that it is indeed a bisimulation. Let us take the coalgebra (R, γ) with R = {(s 0 , s ′ 0 ), (s 1 , s ′ 1 ), (s 2 , s ′ 1 )} is a relation between S and S ′ and γ : R -→ P (A × R) is a function defined as follows:

γ((s 0 , s ′ 0 )) = {(a, (s 1 , s ′ 1 )), (a, (s 2 , s ′ 1 ))} and γ((s 1 , s ′ 1 )) = γ((s 2 , s ′ 1 )) = {(a, (s 2 , s ′ 1 ))}
and let us verify that the following diagram commutes:

{s 0 , s 1 , s 2 } {(s 0 , s ′ 0 ), (s 1 , s ′ 1 ), (s 2 , s ′ 1 )} {s ′ 0 , s ′ 1 } P (A × S) P (A × R) P (A × S ′ ) π 1 π 2 P (A × π 1 ) P (A × π 2 ) α γ α ′
That is to say, for each pair of states (s, s ′ ) ∈ R, one has:

(α • π 1 )(s, s ′ ) = (P (A × π 1 ) • γ)(s, s ′ ) (III.3) (α ′ • π 2 )(s, s ′ ) = (P (A × π 2 ) • γ)(s, s ′ ) (III.4)
For Equation III.3, for (s 0 , s ′ 0 ) one has:

(α • π 1 )(s 0 , s ′ 0 ) = α(π 1 ((s 0 , s ′ 0 ))) = α(s 0 ) = {(a, s 1 ), (a, s 2 )} (P (A × π 1 ) • γ)(s 0 , s ′ 0 ) = (P (A × π 1 )(γ((s 0 , s ′ 0 ))) = P (A × π 1 )({(a, (s 1 , s ′ 1 )), (a, (s 2 , s ′ 1 ))} = {(a, s 1 ), (a, s 2 )} For (s 1 , s ′ 1 ) one has: (α • π 1 )(s 1 , s ′ 1 ) = α(π 1 ((s 1 , s ′ 1 ))) = α(s 1 ) = {(b, s 2 )} (P (A × π 1 ) • γ)(s 1 , s ′ 1 ) = (P (A × π 1 )(γ((s 1 , s ′ 1 ))) = P (A × π 1 )({(b, (s 2 , s ′ 1 ))} = {(b, s 2 )} For (s 2 , s ′ 1 ) one has: (α • π 1 )(s 2 , s ′ 1 ) = α(π 1 ((s 2 , s ′ 1 ))) = α(s 2 ) = {(b, s 2 )} (P (A × π 1 ) • γ)(s 2 , s ′ 1 ) = (P (A × π 1 )(γ((s 2 , s ′ 1 ))) = P (A × π 1 )({(b, (s 2 , s ′ 1 ))} = {(b, s 2 )}
Similarly we obtain Equation III. 4.

Final coalgebras

In this section, we represent final coalgebras which play a central role in the theory of coalgebras. They provide in fact an abstract model of all possible behaviours of a system. Definition 4.1 (Final coalgebra) Let F be a functor. A final F-coalgebra (Γ, π) is a F-coalgebra such that for every F-coalgebra (S, α), there is a unique3 coalgebra morphism beh : (S, α) -→ (Γ, π) such that the following diagram commutes:

S Γ F(S) F(Γ) beh F(beh) α π
A final coalgebra, when it exits, contains every possible observable behaviour. It can be seen as the maximal representation containing all possible observations of a system. Once the final coalgebra for a functor F is defined, we can associate to any state s of an arbitrary F-coalgebra its behaviour beh(s), that is a state of the final coalgebra which is bisimilar with it.

Theorm 4.1 (Gumm [56]) Let F be a signature functor. If F admits a final coalgebra (Γ, π), then for every F-coalgebra (S, α), and for every state s ∈ S, there is a unique state u = beh(s) ∈ Γ such that u and s are bisimilar.

Moreover, it has been shown that states of the final coalgebra coincide with behaviours. Then, for any functor F, bisimilarity implies behavioural equivalence. We have the fundamental result: Theorm 4.2 (Rutten and Turi [START_REF] Rutten | On the foundations of final semantics: Non-standard sets, metric spaces, partial orders[END_REF]) Let F be a functor. Let (S, α) be an arbitrary F-coalgebra, let (Γ, π) be the final F-coalgebra and let beh : S -→ Γ be the unique morphism from S to Γ. Then, for each pair of states s, s ′ ∈ S, one has:

s ∼ S s ′ =⇒ beh(s) = beh(s ′ )
This result then states that to show equality between two states, it is enough to show that they are mapped to the same state in the final coalgebra.

In most cases, the unique existence of a final coalgebra (Γ, π) for a functor F is what one needs to know. We focus precisely on the uniqueness of the morphism beh which maps a state of an arbitrary F-coalgebra to its behaviour in Γ, rather than on the internal structure of the space state Γ or the form of the transition function π. Hence, we are often interested in defining final coalgebras without building their elements, ensuring their uniqueness up to isomorphism.

-→ F(Γ), then it is necessary an isomorphism π : Γ ∼ = -→ F(Γ).
One class of functors for which a final coalgebra always exists is the class of finite Kripke polynomial functors. As already mentioned, finite Kripke polynomial functors are endofunctors of the category Set which include the identity functor, the constant functors, and are closed by product, coproduct, exponent, and finite powerset. In the following, we describe some concrete examples of final coalgebras to become more familiar with them. We refer to [START_REF] Worrell | On the final sequence of a finitary set functor[END_REF][START_REF] Aczel | A final coalgebra theorem[END_REF][START_REF] Barr | Terminal coalgebras in well-founded set theory[END_REF] for results on the existence and construction of final coalgebras.

Streams

In this subsection, we describe the final coalgebra for stream automata. Assume we have a state s ∈ S of such a stream automata (S, obs, next : S -→ A × S). Apply obs, next on s yields an output obs(s) ∈ A as well as its successor state s ′ ∈ S. In the same manner, obs, next can be again applied on s ′ , and then produce a new couple (obs(s ′ ), next(s ′ )) ∈ A × S. Hence, in this way, we can get for each state s ∈ S, an infinite sequence of outputs:

(obs(s), obs(next(s)), obs(next(next(obs(s)))), . . .

)
This sequence is formally obtained by the following definition:

Definition 4.

(Observable behaviour of streams)

Let FX = A × X be a functor. Let C = (S, obs C , next C ) be a F-coalgebra, let s be a state in S and let n ∈ N. The observable behaviour of s is defined by:

(beh(s))(n) = obs C (next n C (s)) where next n is inductively defined via:    next 0 C (s) = s next n+1 C (s) = next C (next n C (s))
The set of states Γ of the final coalgebra is then the set

A N = { f : N → A} = {(a i ) i∈N | a i ∈ A}
of all infinite sequences (a i ) i∈N over A, and its transition function π is the cartesian product of the two following functions:

head, tail : A N → A × A N (a 0 , a 1 , a 2 , . . . ) → (a 0 , (a 1 , a 2 , . . . ))
which are defined for any function f : N -→ A as follows:

head( f ) = f (0) and tail( f ) = f ′ such that ∀n ∈ N, f ′ (n) = f (n + 1)
Thus, everything we can possibly observe about a state s ∈ S is obtained via the function beh : S -→ A N . It assigns to a state s ∈ S, the sequence of outputs beh(s) ∈ A N which is generated on the unique path starting from s.

In order to prove that (A N , head, tail : A N -→ A × A N ) is indeed a final coalgebra of the func- tor FX = A × X, it suffices to show that the function beh : S -→ A N is the unique morphism making the following diagram commute.

S

A

N A × S A × A N beh id A × beh obs, next head, tail
In fact, it leads to two points:

1. verify that beh is a morphism of coalgebras from S to A N ; 2. verify that beh is the unique morphism from S to A N .

For the first point, we need to prove that for any s ∈ S, one has:

(head • beh)(s) = (id A • obs)(s) and (tail • beh)(s) = (beh • next)(s) (head • beh)(s) = head(beh(s)) = head((obs(s), obs(next(s)), obs(next(next(s))), . . . )) = obs(s) = id A (obs(s)) = (id A • obs)(s) (tail • beh)(s) = tail(beh(s))
= tail((obs(s), obs(next(s)), obs(next(next(s))), . . . ) = (obs(next(s)), obs(next(next(s))), . . .

) = beh(next(s)) = (beh • next)(s)
We still have to show the second point. Let us assume that f : S -→ A N is also a morphism of coalgebras which satisfies (head

• f = id A • obs) and (tail • f = f • next)
, and then prove that for any s ∈ S, one has beh(s) = f (s).

First of all, we need to define an auxiliary function tail n : A N -→ A N that takes a sequence σ ∈ A N and returns the sequence σ ′ ∈ A N containing all the elements after the index n in σ.

More formally, it is defined for any σ = (a i ) i∈N ∈ A N and for any n ∈ N by: tail n (σ) = (a i+n ) i∈N Proposition 4.1 For every morphism f : S -→ A N and for any n ∈ N, one has:

( f (s))(n) = obs(next n (s)) (III.5)
Proof Let us assume f (s) = (a 0 , a 1 , a 2 , . . . , a n , . . . ). On one hand, we have:

head(tail n ( f (s))) = head((a n , a n+1 , . . . )) = a n = ( f (s))(n) (III.6)
On the other hand, since f is a morphism, we have tail

• f = f • next which implies tail n • f = f • next n .
Then, we have:

head(tail n ( f (s))) = head( f (next n (s)) = (id A • obs)(next n (s)) = obs(next n (s)) (III.7)
Consequently, Equation III.5 is obtained as an equality between Equation III.6 and Equation III. [START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF].

End

We have just proved that for any n ∈ N, ( f (s))(n) = obs(next n (s)). We have therefore beh(s) = f (s). Thus, beh is the unique morphism of coalgebras from S to A N .

Mealy machines

Given a Mealy machine (S, obs, next : S × In -→ (Out × S)). Its observable behaviour (i.e. a representation in which only inputs and outputs of the machine are involved) is obtained as follows: assume we have a state s ∈ S and an input i ∈ In. Apply obs, next to s produces an output obs((s, i)) ∈ Out and leads the machine state to its successor state next((s, i)) ∈ S. In the same way, we can re-apply obs, next on next(s) for a new input i ′ ∈ In, and then produces an output obs((next(((s, i)), i ′ )) ∈ Out and the successor state next((next(((s, i)), i ′ ))). Continuing in this way 4 , for each finite sequence of inputs (i 0 , i 1 , . . . , i n ), we can get a finite sequence of outputs (o 0 , o 1 , . . . , o n ). Thus, everything we can observe about a state s ∈ S after receiving a finite sequence of inputs σ ∈ In + is obtained via the function beh(s) : In + -→ Out + which assigns to any finite non-empty sequence of inputs (i 0 , i 1 , . . . , i n ) ∈ In + , the finite non-empty sequence of outputs (o 0 , o 1 , . . . , o n ) ∈ Out + .

Definition 4.3 (Observable behaviour of Mealy machines)

Let FX = (Out × X) In be a functor. Let C = (S, obs C , next C ) be a F-coalgebra, let s be a state in S and let (i 0 , i 1 , . . . , i n ) ∈ In + . The observable behaviour of s after receiving (i 0 , i 1 , . . . , i n ) is defined by:

beh(s) = (obs C (next * C (s)(i 0 )), obs C (next * C (s)((i 0 , i 1 ))), . . . , obs C (next * C (s)((i 0 , i 1 , . . . , i n )))
where the function next * is inductively defined via:

   next * C (s)(i) = next C (s)(i) next * C (s)((i 0 , i 1 , . . . , i n )) = next * C (next C (s)(i 0 ))((i 1 , i 2 , . . . , i n ))
The set of states Γ of the final coalgebra is then the set {φ | φ ∈ (Out + )

In + } = {φ | φ : In + -→ Out + }
and its transition function π is:

π : Γ × In → (Out × Γ) (φ, i) → φ(i), φ ′
where φ ′ : In + -→ Out + is defined for each σ ∈ In + by:

φ ′ (σ)(n) = φ(σ)(n + 1), ∀n ∈ N
Hence, the function π splits the elements of Γ into couples in (Out × Γ) as follows: let φ ∈ Γ and i ∈ In:

φ(i) is the output associated to the current state;

φ ′ : In + -→ Out + is the function which associates to every input sequence (i 1 , .

(i 0 , i 1 , i 2 , . . . , i n ) is applied to it. φ φ ′ φ ′′ . . . i 0 |o 0 i 1 |o 1
Rutten proposed in [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF][START_REF] Hansen | Synthesis of mealy machines using derivatives[END_REF] another way to define the final coalgebra of Mealy automata using transfer functions. He showed that the set of all causal stream functions Γ = {F : In ω -→ Out ω | F is causal} carries itself the structure of a Mealy coalgebra via the notions of initial output and stream function derivative.

i : In ω -→ Out ω with F i (σ) = F (i.σ) ′
for any σ ∈ In ω chosen arbitrarily.

Let us now define the coalgebra (Γ, π) as follows:

-Γ = {F : In ω -→ Out ω | F is causal}; -π : Γ × In -→ (Out × Γ)
is the transition function defined for every F ∈ Γ and for every i ∈ In by: [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF] The Mealy machine (Γ, π) defined above is a final Mealy machine coalgebra: for every Mealy machine (S, α) there is a unique homomorphism ! α : S -→ Γ from (S, α) to (Γ, π).

π(F )(i) = F [i], F i Theorm 4.
Proof For every Mealy machine coalgebra (S, α), let us define ! α : S -→ Γ which for every state s ∈ S, associates the transfer function ! α (s) : In ω -→ Out ω which is defined for every s ∈ S, every σ ∈ In ω and every k ∈ ω as follows:

! α (s)(σ(k)) = o k such that s 0 σ(0)|o 0 s 1 σ(1)|o 1 . . . σ(k)|o k s k+1
where there exists an infinite sequence of states s 0 , . . . , s k , s k+1 ∈ S and s 0 = s. It is not difficult to check that ! α is causal, and that ! α defined in this way is the unique homomorphism making the diagram below commute.

S Γ

(Out × S) In (Out × Γ) In ! α (id Out ×! α ) id In α π End

Labeled transition systems

Consider again the finitely branching labeled transition systems that we previously described as coalgebras (S, α : S -→ P fin (A × S)) of the functor FX = P fin (A × X) with A as an alphabet of actions. By Theorem 4.3, the powerset functor P does not admit a final coalgebra. This is indeed due to Cantor's theorem [START_REF] Cameron | Sets, Logic and categories[END_REF][START_REF] Van Dalen | Sets: Naive, Axiomatic and Applied[END_REF] that states that, for any set X, its powerset P (X) has a strictly greater cardinality than X itself. That means there is no bijection between X and P (X) (there is in fact no injection from P (X) to X). However, by Theorem 4.4, the finite powerset P fin belonging to the class of polynomial functors, admits a final coalgebra.

In the following, we then describe the final coalgebra (Γ, π) of finitely branching labeled transition systems. The state set Γ that we will note ST A ∼ is the equivalence classes of so-called synchronization trees over A, modulo bisimilarity. We can in fact look at the synchronization trees [START_REF] Milner | A calculus of communicating systems[END_REF] as transition systems without circuits whose states (or nodes) are represented implicitly and transitions (or arcs) carry labels of A. Intuitively, a synchronization tree is a representation that captures at once all possible behaviours of a system. It can be obtained by unfolding Let us note some points:

s 0 s 1 s 2 a 0 a 2 a 1 a 3 a 0 a 1 a 3 a 2 a 3 a 2 a 0 a 1 Figure III.
-Synchronization trees have finite branches and eventually infinite paths. Many nodes (potentially infinitely many) of the synchronization tree represent the same state of the original labeled transition system: they correspond in fact to different visits to the state; -Nodes of synchronization trees are represented implicitly (they are not labeled). Information on nodes is not present in the behaviour;

-Two states which are bisimilar in the labeled transition systems are mapped to the same synchronization tree in TS A ∼ because TS A ∼ 's elements are equivalence classes modulo bisimilarity ∼.

The transition function π : TS A

∼ -→ P fin (A × TS A ∼ ) is the application splitting the synchroniza- tion tree into its immediate subtrees as follows:

TS A ∼ -→ P fin (A × TS A ∼ )       t 1 t n a 1 a n . . .       ∼ → {(a 1 , [t 1 ] ∼ ), . . . , (a n , [t n ] ∼ )}
Now, to prove that (TS A ∼ , π) is the final coalgebra, we need to verify the commutativity of the following diagram:

S TS A ∼ P fin (A × S) P fin (A × TS A ∼ ) beh P fin (id A × beh) α π
with beh is the function that associates to every state s ∈ S, the corresponding synchronization tree beh(s) ∈ TS A ∼ as follows:

s s 1 s n . . . a 1 a n =⇒ beh(s) =       beh(s 1 ) beh(sn ) a 1 a n . . .       ∼
It is straightforward to verify the commutativity of the above diagram.

More examples

We present here more examples of systems modeling in terms of coalgebras. For each system, we give the corresponding functor as well as its final model without going into technical details. 5 1. Finite stream over a set of labels A: is a coalgebra (S, α : S -→ (A × S) ∪ {⊥}) of the functor FX = (A × X) + 1 where ⊥ is a state expressing the possibility of termination.

The final coalgebra is (A ∞ , π : A ∞ -→ (A × A ∞ ) ∪ {⊥})
where π is the function defined for σ ∈ A ∞ by:

π(σ) =    ⊥ if σ = ǫ (a, σ ′ ) if σ = a.σ ′

Binary tree over a set of labels

A: is a coalgebra (S, α : S -→ ((A × S) × (A × S)) ∪ {⊥}) of the functor FX = ((A × X) × (A × X)) + 1.
The final coalgebra is (Γ, π) where:

- Γ = {φ : {0, 1} * → (A × A) ∪ {⊥} | ∀v ∈ {0, 1} * , φ(v) ∈ {⊥} =⇒ (∀w ∈ {0, 1} * , φ(v.w) = φ(v))}
is the set of all binary trees whose arcs are labeled with actions of A and whose branches are eventually infinites

-π : Γ -→ ((A × Γ) × (A × Γ))
∪ {⊥} is the function defined for any tree φ ∈ Γ by:

π(φ) =    ⊥ if φ(ǫ) = ⊥ ( a 1 , φ 1 , a 2 , φ 2 ) if φ(ǫ) = a 1 , a 2 with for i = 1, 2, φ i is defined for v ∈ {0, 1} * by φ i (v) = φ(a i .v). 3. Deterministic automata: is a coalgebra (S, α : S -→ {0, 1} × S A ) of the functor FX = {0, 1} × X A . The final coalgebra is (L, o L , d L ) where L = {L|L ⊆ A * }
o L (L) =    1 if ǫ ∈ L 0 otherwise and d L (L)(a) = {v ∈ A * | a.v ∈ L} 5. A ∞ = A * ∪ A N
is the set of finite and infinite sequences of elements over A, ǫ denotes the empty sequence and _._ :

A ∞ × A ∞ -→ A ∞ )
is the binary operation of concatenation. 4. Moore automata: is the coalgebra (S, α : S -→ Out × S In ) of the functor

FX = Out × X In
The final coalgebra is (Out In * , head, tail : Out In * -→ Out × Out In * ) where head, tail is the function defined for φ : In * -→ Out ∈ Out In * by: head, tail (φ) = φ(ǫ), φ ′ with φ ′ is the function defined for i ∈ In and σ ∈ In * by:

φ ′ (i)(v) = φ(i.σ)

Co-induction

Due to the fact that coalgebras are duals of algebras, definitions and results known from universal algebra were dualized to the coalgebra theory such as coinduction principle which we present in this section. The coinduction principle is the categorical dual of induction which, in a categorical setting, refers to the use of the initiality principle for algebras. In fact, induction is used to build new data entities from data entities already constructed. On the contrary, coinduction is used to observe potentially infinite data entities whose structure may contain patterns that repeat infinitely. It does not tell us how to build objects, it tells us only what we can observe on them. As mentioned in the previous section, once we know the final coalgebra (Γ, π) of a given functor F, we can use its finality to define functions into its carrier set Γ and to prove properties. Hence, existence of final coalgebra allows us to define functions (it is called coinduction definition principle) while its uniqueness allows us to prove properties of the functions already constructed (it is called coinduction proof principle).

Example 5.1 (Definition of functions by coinduction)

In this example, we define by coinduction, the function merge : A N × A N -→ A N which builds a new sequence by interleaving the elements of two sequences. For this, it is enough to verify that the function merge is a morphism of coalgebras from an appropriate coalgebra with the same domain of merge i.e. A N × A N to the final coalgebra (A N , head, tail : A N -→ A × A N ) of the functor FX = A × X. Let us take a coalgebra whose carrier set is A N × A N and whose transition function is α m :

A N × A N -→ A × (A N × A N ) defined by: ∀(σ 1 , σ 2 ) ∈ A N × A N , α m ((σ 1 , σ 2 )) = (head(σ 1 ), (σ 2 , tail(σ 1 )))
Now, by the conduction definition principle, we can directly conclude the existence of the morphism

merge : A N × A N -→ A N which makes the following diagram commute: A N × A N A N A × (A N × A N ) A × A N merge id A × merge α m head, tail
The fact that this diagram is commutative gives indeed:

head(merge((σ 1 , σ 2 )) = head(σ 1 ) and tail(merge((σ 1 , σ 2 ))) = (merge((σ 2 , tail(σ 1 ))) (III.8) as expected.

O = (A N , α O : A N -→ A × A N ) and E = (A N , α E : A N -→ A × A N )
of the functor FX = A × X where α O and α E are defined respectively for any sequence σ ∈ A N by: 6

α O (σ) = (head(tail(σ)), tail 3 (σ)) and α E (σ) = (head(σ), tail 2 (σ)))

A N A N A N A N A × A N A × A N A × A N A × A N odd id A × odd α O head, tail even id A × even α E head, tail
Then, the commutativity of the above diagrams gives the two following equations: for any sequence σ ∈ A N : head(even(σ)) = head(σ) and tail(even(σ)) = even(tail(tail(σ))) (III.9) head(odd(σ)) = head(tail(σ)) and tail(odd(σ)) = odd(tail(tail(tail(σ)))) (III.10)

We can also easily prove that:

odd(σ)) = even(tail(σ)) and even(tail 2 (σ)) = odd(tail(σ)) (III.11)

Now, we need to show that the composite function merge • even, odd :

A N -→ A N
and the identity function on A N are equal. It suffices then to prove that they are both morphisms for the same coalgebra structure on A N . It is not difficult to see that the identity function id A N : A N → A N is indeed a morphism of coalgebras from (A N , head, tail ) to (A N , head, tail ). We still have to show that merge • even, odd is also a morphism from A N to A N . For this, it is enough to show the commutativity of the following diagram:

A N A N × A N A N A × A N A × (A N × A N ) A × A N even, odd id A × even, odd head, tail α m merge id A × merge head, tail id A N 6.
The function tail n : A N -→ A N has been defined in the previous section for σ = (a i ) i∈N ∈ A N and n ∈ N by tail n (σ) = (a i+n ) i∈N This amounts to show that:

head, tail • (merge • even, odd ) = (id A × (merge • even, odd )) • head, tail
This is proved for σ ∈ A N by: head(merge(even(σ), odd(σ)))=head(even(σ))

see Equation III.8 =head(σ) see Equation III.9

tail(merge(even(σ), odd(σ))) =merge(odd(σ), tail(even(σ))) see Equation III.8 =merge(odd(σ), even(tail(tail(σ)))) see Equation III.9 =merge(even(tail(σ)), odd(tail(σ))) see Equation III.11 =merge( even, odd (tail(σ))) =merge • even, odd )(tail(σ))

Proof by bisimulation

There is another alternative for proving properties. The underlying idea is that two states are behaviourally equivalent if and only if they are bisimilar (see Theorem 4.2). This result indeed gives rise to a proof method. Then, two states are equals if and only if they are contained in a bisimulation relation.

Corollary 5.1

Two states s and s ′ have the same behaviour if and only if there is a bisimulation R such as (s, s ′ ) ∈ R. For every bisimulation R on the final 7 coalgebra (Γ, π), one has R ⊆ ∆ Γ where

∆ Γ = {(s, s) | s ∈ Γ}.
Equivalently, for all s and s ′ in Γ, one has:

s ∼ s ′ ⇐⇒ s = s ′ Example 5.

(Proof by bisimulation) Let us consider again the property:

∀σ ∈ A N , merge((odd(σ), even(σ))) = σ proved in Example 5.2, and then prove it using the notion of bisimulation. Our aim is to prove the equality: merge(odd(σ), even(σ)) = σ Then, we need a bisimulation R ⊆ A N × A N containing both sides of the equation. We take:

R = {(merge(odd(σ), even(σ)), σ) | σ ∈ A N } Recall from Section 3 that a relation R ⊆ A N × A N
is a bisimulation if the two projections π 1 : R -→ A N and π 2 : R -→ A N are morphisms of coalgebras from the coalgebra (R, γ) to (A N , head, tail ) where γ is defined as follows:

γ : R -→ A × R (σ 1 , σ 2 ) → (head(σ 1 ), (tail(σ 1 ), tail(σ 2 )))
By finality of A N , it is obvious to show that π 1 and π 2 are morphisms of coalgebras from

({(merge((odd(σ), even(σ))), σ)|σ ∈ A N }, γ) to (A N , head, tail )
Then, one has merge((odd(σ), even(σ))) = σ. [START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF]. Recall s and s ′ define behaviours belonging to the final coalgebra. (merge(a N , b N ), (ab) N ) and (merge(b N , a N ), (ba) N ) R is a bisimulation if for any pair of streams (σ 1 , σ 2 ) ∈ R, one has:

R((σ 1 , σ 2 )) =⇒    head(σ 1 ) = head(σ 2 ) tail(σ 1 ) = tail(σ 2 )
Consider the first pair (merge(a N , b N ), (ab) N ) of R, the only transition step of its left component is:

merge(a N , b N ) a -→ merge(b N , a N )
whereas its right component can take the step:

(ab) N a -→ (ba) N
Hence, the resulting pair (merge(b N , a N ), (ba) N ) is again in the relation R.

In the same manner, we can show that the resulting pair of the second pair (merge(b N , a N ), (ba

) N ) is (merge(a N , b N ), (ab) N ) which is in the relation R.
Consequently, R is a bisimulation. Corollary 5.1 tells us that R ⊆ ∆ A N , proving then the equality:

merge(a N , b N ) = (ab) N Part II

Systems modeling framework

This part provides the first contribution of this thesis. It presents a formal abstract framework for developing, in a compositional way, complex software systems viewed as componentbased systems. It intends to contribute to the following topics:

-The definition of a generic modeling of components. This will then enable us to unify a wide family of state-based formalisms classically used to specify components, such as Mealy machines [START_REF] Eilenberg | Automata, Languages and Machines[END_REF][START_REF] Mealy | A method for synthesizing sequentiel circuits[END_REF], labeled transition systems (LTS) [START_REF] Milner | A calculus of communicating systems[END_REF] and input-output labeled transition systems (IOLTS) [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF]. We will see that the generality of our formalization will be obtained by taking into account various kinds of computation structures such as non-determinism, partiality, etc. [START_REF] Moggi | Notions of computation and monads[END_REF].

-The definition of a trace model over components using causal transfer functions [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF][START_REF] Hansen | Synthesis of mealy machines using derivatives[END_REF][START_REF] Raney | Sequential functions[END_REF] as is usual in control theory or physics when dealing with dynamic system modeling.

-The definition of a minimal and unified set of component integration operators able to take into account the interaction semantics present in most modern systems. Such integration operators will be used to combine component behaviours that interact together in order to build a larger system.

This part consists of two chapters. The first chapter introduces a generic unified coalgebraic model of components enabling us to naturally describe a large family of state-based formalisms as well as its trace model given as transfer functions. The second chapter introduces how components can be composed to obtain systems. It presents two basic integration operators: cartesian product and feedback, and shows that both seem sufficient to build most other standard operators such as synchronous product and sequential, double sequential, concurrent and synchronous parallel operators, by composition.

Chapter IV

Generic components 1

Components as coalgebras .

. . 88

This chapter presents a formal generic framework for developing basic components viewed as state-based systems. As explained in the introduction, our formalization is based on Barbosa's components [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Barbosa | State-based components made generic[END_REF][START_REF] Barbosa | Generic components[END_REF][START_REF] Barbosa | Components as processes: An exercise in coalgebraic modeling[END_REF][START_REF] Barbosa | Components as coalgebras[END_REF]. We then start, in Section 1, by introducing Barbosa's definition of a component as well as some explicative concrete examples. We further show that this component definition is powerful enough to be a unified generic state-based formalism by providing some basic examples. In Section 2 we define, by relying on the work proposed by Rutten in [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF], a trace model over components using causal transfer functions. The formalization of components and their traces as coalgebras and transfer functions respectively, allows us to extend standard results connected to the definition of a final component in Section 3. We show, over some assumptions, the existence of a final model which will be useful to define the basic integration operators in Chapter V. Finally, Section 4 concludes with some final remarks and an assessment of the results.

Components as coalgebras 1.Motivation

In a series of papers [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Barbosa | State-based components made generic[END_REF][START_REF] Barbosa | Generic components[END_REF], Barbosa and his colleagues used the coalgebra theory to define a generic notion of a state-based software component. In these works, a component was then introduced as a generalized Mealy automaton in which the dependence between outputs and both current state and inputs is relaxed from a strict deterministic, to encompass more complex behaviours such as partiality, non determinism, etc. The reasons for using Barbosa's definition are twofold:

-It fits to the standard view of functional components that is, at a high level of abstraction, components may be considered as black boxes that take inputs and provide appropriate outputs. The behaviour of a component is then specified by describing how inputs drive changes in component state and how outputs are produced.

-It is considered as an excellent modeling tool for representing several kinds of computational effects, such as: determinism, non-determinism and partiality, as well as abstractly providing a unifying formal framework in which a great diversity of state-based formalisms used to describe dynamical systems behaviour, such as: Mealy machines [START_REF] Eilenberg | Automata, Languages and Machines[END_REF][START_REF] Mealy | A method for synthesizing sequentiel circuits[END_REF], Labeled Transition Systems (LTS) [START_REF] Milner | A calculus of communicating systems[END_REF][START_REF] Brookes | An Improved Failures Model for Communicating Processes[END_REF], Input-Output Labeled Transition Systems (IOLTS) [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF] can be naturally captured (see Section 1.2). This is due to the introduction of monads in the component definition. Barbosa further requires that the monad T should be strong [START_REF] Wolff | Monads and monoids on symmetric monoidal closed categories[END_REF]. That means T is equipped with two natural transformations: τ r : TX × Y -→ T(X × Y) and τ l : X × TY -→ T(X × Y) for any sets X and Y, called the right and left strength respectively, satisfying certain coherent conditions [START_REF] Wolff | Monads and monoids on symmetric monoidal closed categories[END_REF]. This requirement is mainly supposed to be able to link in [START_REF] Barbosa | Components as coalgebras[END_REF] computations carried by T. For instance, when composing two components C 1 and C 2 over T(Out 1 × S 1 ) and T(Out 2 × S 2 ) respectively, τ r followed by τ l allows the mapping of

Components

T(Out 1 × S 1 ) × T(Out 2 × S 2 ) to TT((Out 1 × S 1 ) × (Out 2 × S 2 ))
This latter can then be flattened to T((Out

1 × S 1 ) × (Out 2 × S 2 )) via µ.
We do not require that the monad T should be strong as it was assumed in the original definition introduced in [START_REF] Barbosa | Components as coalgebras[END_REF]. We rather assume the existence of two natural transformations η ′ and η ′-1 that we will present in Section 2. These two natural transformations will be useful not only to link computations carried by T, like strong monads do, when composing components in Chapter V but also to define a trace model over components in Section 2. The behaviour of M is the following: from its initial state STDBY, when it receives a coin from the user, it goes into the READY state. Then, when the user presses the "coffee" button, three cases are distinguished: (1) M serves a coffee to the user and goes back to the STDBY state; (2) M serves a coffee to the user and goes to the FAILED state (for example, when there is one cup in the machine); (3) M fails to deliver coffee to the user and so refunds him and goes to the FAILED state. The only escape from the FAILED state is to have a repair. This machine can be modeled as a component M = (S, init, α) over the signature P fin (Out × ) In . The state space is S = {STDBY, READY, FAILED} and init = STDBY. The sets of inputs and outputs are In = {coin, coffee, repair} and Out = {abs, served, refund}. Finally, the transition function: α : S -→ P fin {abs, served, refund} × S {coin,coffee,repair} is defined as follows: The behaviour of M is the following: from its initial state s 0 , it is waiting either for a request for amount (the "amount" action) or a request for bank account balance (the "check" action):

       α(STDBY)(coin) = (abs, READY) α(READY)(coffee) = (served, STDBY), (served, FAILED), (refund, FAILED) α(FAILED)(repair) = (
-if the user enters amount, M goes to s 1 . An internal test is then made to check whether the received amount can be withdrawn (represented by the action τ). If there is enough money in the customer's account, the requested amount is withdrawn and the ATM returns to its initial state (the "cash" action). If there is not enough money in the customer's account, the withdraw operation fails and an error message is displayed on the machine screen (the "screen" action).

-If the user asks for the amount of his/her account, M does an internal action and then notifies the user by the amount (the "sold" action). It then returns back to its initial state s 0 .

This machine can be modeled It consists of two essential parts: the road and the crosswalk. A pedestrian crossing system is then made to avoid any interactions between pedestrians that want to cross the crosswalk and vehicles that want to cross the road. A traffic light is then usually used to control pedestrian and vehicle flows at the crosswalk. Such a typical traffic light consists of three colors: green, orange and red, and behaves as follows: in the absence of any pedestrian request, the green color is illuminated. When a pedestrian wishes to cross the road, he then pushes the request button that sends a signal to the traffic light system to change its illumination to an orange light to prepare to stop the vehicles. Then, it switches to a red light prohibiting any vehicle flow at the road and yielding to the pedestrians. Once the crosswalk is free from pedestrians, the traffic light receives a signal saying the road is free and thus the green color is again illuminated. In this way, the traffic light system allows one to yield either to pedestrians or vehicles by repetitively making the green-orange-red-green cycle.

       α(s 0 )(amount) = (abs, s 1 ) α(s 0 )(check) = (abs, s 3 ) α(s 1 )(τ) = (abs, s 2 )            α(s 3 )(τ) = (abs, s 4 )} α(s 2 )(screen) = (abs, s 0 ) α(s 2 )(cash) = (abs, s 0 ) α(s 4 )(sold) = (abs, s 0 ) s 0 s 1 s 2 s 3

Figure IV.3 -Pedestrian crossing

The traffic light system can be modeled as a component M = (S, s 0 , α M ) over the signature (Out × ) In . The state space is S = {s 0 , s 1 , s 2 , s 3 , s 4 }. The sets of inputs and outputs are:

In = {stopLight, lightOk, abs} and Out = {lightRed, lightOrange, lightGreen, pedestrianOk, abs} Finally, the transition function: α M : S -→ ({lightRed, lightOrange, lightGreen, pedestrianOk, abs} × S) {stopLight,lightOk,abs} is defined as follows:

       α M (s 0 )(abs) = (lightGreen, s 0 ) α M (s 0 )(stopLight) = (lightGreen, s 1 ) α M (s 1 )(abs) = (lightOrange, s 2 )          α M (s 2 )(abs) = (lightRed, s 3 ) α M (s 3 )(abs) = (pedestrianOk, s 4 ) α M (s 4 )(lightOk) = (abs, s 0 )
The graphical diagram of this component is shown in Figure IV

= T(Out × ) In . A component morphism h : C -→ C ′ is a coalgebra homomorphism h : (S, α) -→ (S ′ , α ′ ) such that h(init) = init ′ .
We note Comp(H) (resp. PComp(H)) the category of components (resp. pre-components) over H.

This will be in the category of pre-components PComp(H), where we will show the existence of a final model under some conditions (see Section 3).

Genericity of component definition

Definition 1.1 is generic enough to unify in a single framework a large family of formalisms classically used to specify state-based systems [START_REF] Kanso | Testing of abstract components[END_REF]. We describe the most important of them in three tables: Table IV 3. Each table illustrates the possible models of dynamic systems that can be framed as instances of our component definition depending on the monad T. The first column consists of instances of the input set In, the second column consists of instances of the output set Out, the third column introduces the possible coalgebraic models obtained by making a particular choice for In and Out, and the fourth column gives an example of which dynamic system can be obtained.

input set I output set O X -→ P (({!} × O) ∪ {abs ! } × X) ({?}×I)∪{abs ? } IOLTS Table IV.
3 -The non-deterministic computational features 2. abs, abs ? and abs ! are particular fresh action, input action and output action denoting the lack of reaction, input and output respectively.

To completely define IOLTS, we need to impose the supplementary property on the transition function α : S -→ P (Out × S) In : ∀i ∈ In, ∀s ∈ S, (o, s) ∈ α(s)(i) =⇒ either i = abs ? or o = abs ! to express that input and output are mutually exclusive. This construct of α means that one can define three kinds of transition depending on the label that is allowed to appear in it.

-Input-kind: the transition can only be labeled by input action, that is i|abs ! ; -Output-kind: the transition can only be labeled by output action, that is abs ? |o; -Internal-kind: the transition is labeled by abs ? |abs ! .

Therefore, a transition can be labeled by input or output 3 actions, but never both.

Each of these instances leads to obvious algorithms that transform each of previous models into components according to Definition 1. 1. Let us illustrate this for IOLTS models.

Definition 1.3 (IOLTS as component)

Let Σ = Σ ? ∪ Σ ! ∪ {τ} be an alphabet of actions. Let H = P (Out × ) In be the signature associated to IOLTS where

In = ({?} × Σ ? ) ∪ {abs ? } and Out = ({!} × Σ ! ) ∪ {abs ! }
The transformation of an IOLTS over IOLT S(Σ) into a component over H is the application:

φ : IOLT S(Σ) -→ Comp(H)
that maps an IOLTS M = (Q, q 0 , Σ, Tr) to a component 4 C = (S, s 0 , α) as follows:

-S = Q and s 0 = q 0 ; α : S × In -→ P (Out × S) is the function defined by the following rules:

3.

Our transformation of an IOLTS into our framework is inspired from the works done by M. Phalippou in his thesis [START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF], that transform an IOLTS into finite state machine. 4. IOLT S(Σ) denotes the set of input-output labeled transitions systems over the alphabet Σ.

Component traces

As shown in Table IV.1, Mealy automata with input set In and output set Out are coalgebras of the functor F : Set -→ Set defined by F(X) = (Out × X) In . For a coalgebraic modeling of Mealy automata, Rutten in [41] defined 5 the final coalgebra of F (i.e. the set of all possible observable behaviours) as causal stream functions (traditionally called transfer functions). Hence, it is shown in [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF][START_REF] Hansen | Synthesis of mealy machines using derivatives[END_REF] that the final coalgebra of F is isomorphic to the set of all causal functions from the set of infinite input sequences to the set of infinite output sequences equipped with the operations of initial output and stream function derivative. In this section, similarly to Rutten's work, we show that the observable behaviour of our components can also be characterized by causal functions mapping infinite input sequences to infinite output sequences.

Transfer function

In the following, we note ω the least infinite ordinal, identified with the corresponding hereditarily transitive set.

∀n ∈ ω, σ ′ (n) = σ(n + 1).
For every a ∈ A, let us note a.σ the dataflow σ defined by:

σ(0) = a and ∀n ∈ ω \ {0}, σ(n) = σ(n -1)
Hence, σ = σ(0).σ ′ .

Transfer functions will be used to describe the observable behaviour of components. They can be seen as dataflow transformers satisfying the causality condition as this is classically done in control theory and physics for modeling dynamic systems [START_REF] Sontag | Mathematical control theory: deterministic finite dimensional systems[END_REF], that is the output data at index n only depends on input data at indexes 0, . . . , n.

Definition 2.3 (Transfer function) Let

In and Out be two sets denoting, respectively, the input and output domains. A function F : In ω -→ Out ω is a transfer function if, and only if it is causal, that is:

∀n ∈ ω, ∀σ 1 , σ 2 ∈ In ω , (∀m, 0 ≤ m ≤ n, σ 1 (m) = σ 2 (m)) =⇒ F (σ 1 )(n) = F (σ 2 )(n)
Causal transfer functions and the notion of transfer function derivative were first introduced by Raney in [START_REF] Raney | Sequential functions[END_REF]. Raney's [START_REF] Raney | Sequential functions[END_REF] also showed that both composition of two causal transfer functions and the derivative of a causal transfer function are again causal.

Example 2.1

The function F : {0, 1} ω -→ {0, 1} ω defined for every σ ∈ {0, 1} ω and every k ∈ ω by

F (σ)(k) = k ∑ i=0 σ(i) mod 2
is the transfer function that takes a sequence of bits σ ∈ {0, 1} ω and checks at each step k whether it has received an odd number of "ones". It then returns 0 if the number of "ones" is even, and 1 otherwise. In Example 3.1, we will define the component that implements it. [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF]. See Chapter III, Subsection 4.2 for more explanations for Rutten's work.

Component Traces

To associate behaviours to components by transfer functions, we have to require the existence of two natural transformations η ′ : T =⇒ P and η ′-1 : P =⇒ T such that η ′-1 • η ′ = id T where P is the powerset functor. Indeed, from a component (S, α), we need to "compute" for an infinite input sequence σ ∈ In ω all the outputs o after going through any sequence of states (s 0 , . . . , s k ) such that s j is obtained from s j-1 by σ(j -1). However, we do not know how to characterize s j with respect to α(s j-1 )(σ(j -1)) because nothing ensures that elements in α(s j-1 )(σ(j -1)) are (output, state) couples. Indeed, the monad T may yield a set with a structure different from Out × S. The mapping η ′ Out×S maps back to this structure. η ′-1 Out×S is useful for going back to T when defining final models.

Most monads used to represent computation situations satisfy the above condition. For instance, for the monad T : P, both η ′ S and η ′-1

S

are the identity on sets. For the functor T : id + 1, η ′ S associates the singleton {s} to any s ∈ S and the empty set to ⊥, and η ′-1 S associates the state s to the singleton {s} and ⊥ to any other subset of S which is not a singleton. Let us observe that given a monad T, the couple (η ′ , η ′-1 ) when it exists, is not necessarily unique. Indeed, for the monad T = id, η ′ S can still be defined as s → {s}. However, η ′-1 S is not unique. Indeed, any mapping η ′-1 S that associates the singleton {s} to s, and every subset of S which is not a singleton to a given s ′ ∈ S, satisfies η ′-1 S • η ′ S = id S . Hence, in the following, given a signature T(Out × ) In , we will assume given a couple (η

′ , η ′-1 ) such that η ′-1 • η ′ = id.
In the following, we note η ′ Out×S (α(s

)(i)) | 1 (resp. η ′ Out×S (α(s)(i)) | 2 )
the set composed of all first arguments (resp. second arguments) of couples in α(s)(i).

Let us now associate behaviours to components by their transfer functions. Let us consider a state s ∈ S of such a component C = (S, α) over T(Out × ) In . Applying α to s after receiving an input i 1 ∈ In yields a set η ′ Out×S (α(s)(i 1 )) of couples (output|successor state). Similarly, after receiving a new input i 2 ∈ In, we can repeat this step for each state s ′ ∈ η ′ Out×S (α(s)(i 1 )) | 2 and form another set of couples (output|successor state). Thus, we get for each infinite sequence of inputs i 1 , i 2 , . . . ∈ In ω , a set of infinite sequences of outputs o 1 , o 2 , . . . ∈ Out ω . All we can possibly observe about a state s ∈ S is obtained in this way. More formally, this leads to: Definition 2.4 (Component behaviour) Let C = (S, init, α) be a component over T(Out × ) In . The behaviour of a state s of C, noted beh C (s) is the set of transfer functions F : In ω -→ Out ω that associate to every σ 1 ∈ In ω a dataflow σ 2 ∈ Out ω such that there exists an infinite sequence of couples

(o 1 , s 1 ), . . . , (o k , s k ), • • • ∈ Out × S satisfying: ∀j ≥ 1, (o j , s j ) ∈ η ′ Out×S (α(s j-1 )(σ 1 (j -1)))
with s 0 = s, and for every k

< ω, σ 2 (k) = o k+1 .
Hence, C's behaviour is the set beh C (init). where (coin.coffee) 0 = (coin.coffee.repair) 0 = (abs.served) 0 = (abs.refund.abs) 0 = ǫ (the empty word).

Hence, the transfer function that would remain in the loop between the states STDBY and READY could be defined by any function F σ with σ = n 1 .0.n 2 .0 . . . n i .0 . . .

In the context of our work, we will need to use finite traces. Finite traces are finite sequences of couples (input|output) defined as follows :

φ t (M) : Trace(M) -→ Trace(φ(M))
which is inductively defined as follows:

-for every 6 trace tr = ǫ ∈ trace(M), φ t (tr) = ǫ; -for every trace tr =?i ∈ trace(M), φ t (tr) =?i|abs ! ; -for every trace tr =!o ∈ trace(M), φ t (tr) = abs ? |!o;

-for every trace tr = τ ∈ trace(M), φ t (tr) = abs ? |abs ! ; -for every trace tr = a 1 . . . a n ∈ trace(M) with a ∈ Σ τ , φ t (tr) = φ t (a 1 ) . . . φ t (a n ).

Results

Following Rutten's works [START_REF] Hansen | Synthesis of mealy machines using derivatives[END_REF][START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF], this trace model can be computed. This first requires the existence of a final model in the category PComp(H). As usual, this terminal model can be obtained under some conditions on the cardinality of the set yielded by the mapping beh C for every component C = (S, α) ∈ PComp(H). [START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF]. ǫ stands for the empty trace.

Final model

The condition we need to obtain the existence of a final model is the following: Assumption: we suppose that for every pre-component C = (S, α) over a signature H = T(Out × ) In , and for every s ∈ S, the cardinality of beh C (s) is less than a cardinal κ.

This assumption allows us then to define a coalgebra (Γ, π) over H and to show that it is final in PComp(H).

-Γ = P ≤κ ({F :

In ω -→ Out ω | F is causal}) -for every F ∈ Γ and for every i ∈ In, π(F)(i) = η ′-1
Out×Γ (Π) where:

Π = (o, F ′ o ) | o ∈ F ∈F
(F (i.x)(0)) and,

F ′ o = {F (i.x) ′ | F (i.x)(0) = o and F ∈ F}, for x ∈ In ω chosen arbitrarily
Let us note here that using

F ′ o = {F (i.x) ′ | F (i.x)(0) = o and F ∈ F} instead of F ′ = {F (i.x) ′ | F ∈ F}
in the definition of (Γ, π) allows us to keep the computational effects carried by the monad T. This is done by linking the output o to the derivative function set F ′ i.e. the derivative function set is not only linked to the input i but also to the output associated to i. This construction of the set F ′ is useful to prove that (Γ, π) is final in PComp(H). Proof Let (Γ, π) be as stated, and let C = (S, α) ∈ PComp(H) be an arbitrary component. We have to show that there exists a unique homomorphism of components S → Γ. For this, let us take the behaviour mapping beh C : S -→ Γ (see Definition 2.4) which for every s ∈ S associates a finite set of transfer functions F = {F : In ω -→ Out ω | F is causal} ∈ Γ. We have to prove that it is the unique homomorphism making the following diagram commute.

F F ′ o 1 F ′ o j F ′ on . . .

S × In

Γ × In T(Out × Γ) T(Out × S) beh C × id In α π T(id Out × beh C )
We first prove the commutation.

First of all, it is easy to see that the following properties are satisfied:

∀ f , f : S -→ S ′ , ∀X ∈ T(S) : T( f )(X) = η ′-1 S ′ • P ( f ) • η ′ S (X) (IV.1) ∀s ∈ S, i ∈ In and ∀(o, s ′ ) ∈ η ′ Out×S (α(s)(i)) beh C (s ′ ) = beh C (s) ′ o = {F (i.x) ′ | F (i.x)(0) = o and F ∈ beh C (s)} (IV.2) ∀i ∈ In, s ∈ S and beh C (s) ∈ Γ, η ′ Out×S (α(s)(i)) | 1 = {F (i.x)(0) | F ∈ beh C (s)} (IV.3)
Hence, let s ∈ S, i ∈ In and x ∈ In ω be arbitrary. We have to prove that:

(T(id Out × beh C ) • α)(s)(i) = (π • (beh C × id In ))(s)(i) (T(id Out × beh C ) • α)(s)(i) = T(id Out × beh C )(α(s)(i)) = η ′-1 Out×Γ (P (id Out × beh C )(η ′ Out×S (α(s)(i)))) Property IV.1 = η ′-1 Out×Γ ({(o, beh C (s ′ )) | (o, s ′ ) ∈ η ′ Out×S (α(s)(i))}) Property IV.2 = η ′-1 Out×Γ (o, beh C (s) ′ o ) | o ∈ η ′ Out×S (α(s)(i)) | 1 and , beh C (s) ′ o = {F (i.x) ′ | F (i.x)(0) = o and F ∈ beh(s)} Property IV.3 = η ′-1 Out×Γ (o, beh C (s) ′ o ) | o ∈ F ∈ beh C (s)(F (i.x)(0)) and , beh C (s) ′ o = {F (i.x) ′ | F (i.x)(0) = o and F ∈ beh C (s)} Definition of π = π((beh C (s), i)) = π(beh C × id In )(s)(i) = (π • (beh C × id In ))(s)(i)
Next we have to prove uniqueness. In order to prove this last point, we need to prove the following lemma: Lemma 3.1 For every component homomorphism f : S -→ Γ, for every x ∈ In ω and for every s ∈ S we have:

( f (s)(x)) ′ = { f (s ′ )(x ′ ) | s ′ ∈ η ′ Out×S (α(s)(x(0))) | 2 }
where x ′ is the derivative of x.

Proof ( f (s)(x)) ′ = (o 1 , o 2 , . . . , o k , . . . ) ′ | ∃s 0 , s 1 , . . . , s k , • • • ∈ S such that s = s 0 , o 1 , s 1 ∈ η ′ Out×S (α(s 0 )(x(0))) and ∀2 ≤ j ≤ k -1, (o j , s j ) ∈ η ′ Out×S ((s j-1 )(x(j -1))), and o k ∈ η ′ Out×S (α((s k )(x(k))) | 1 ) = (o 2 , . . . , o k , . . . ) | ∃s 1 , . . . , s k , • • • ∈ S such that s 1 ∈ η ′ Out×S (α(s 0 )(x(0))) | 2 and ∀2 ≤ j ≤ k -1, s j ∈ η ′ Out×S (α((s j-1 )(x(j -1)))) | 2 , and o k ∈ η ′ Out×S (α(s k )(x(k))) | 1 = { f (s 1 )(x ′ ) |s 1 ∈ η ′ Out×S (α(s 0 )(x(0)) | 2 } = { f (s ′ )(x ′ ) |s ′ ∈ η ′ Out×S (α(s)(x(0)) | 2 }

End

Now, let us assume that g : S → Γ is also a homomorphism of components. Let us show that the relation R ⊆ P κ (Out ω ) × P κ (Out ω ) defined as:

R = { g(s)(x), beh(s)(x) | s ∈ S, x ∈ In ω , g(s)(x) = beh(s)(x)}
is a bisimulation. It can be shown by coinduction on x ∈ In ω , that for all s ∈ S we have:

g(s)(x) = beh(s)(x)
The initial set outputs of g(s)(x) and beh(s)(x) agree, since at the initial input x(0) of x, we have:

g(s)(x)(0) = η ′ Out×S (α(s)(x(0)) | 1 = beh(s)(x)(0) (g(s)(x)) ′ = (g(s)(x(0).x ′ )) ′ = {g(s ′ )(x ′ ) | s ′ ∈ η ′ Out×S (α(s)(x(0))) | 2 } Lemma 2 (beh(s)(x)) ′ = (beh(s)(x(0).x ′ )) ′ = {beh(s ′ )(x ′ ) | s ′ ∈ η ′ Out×S (α(s)(x(0))) | 2 } Lemma 2
Hence the function derivatives sets are also R-related, and we conclude that R is a bisimulation. End

Minimal component

A final model of the functor F = T(Out × ) In provides an abstract model of all possible behaviours of its F-coalgebras. Hence, in practice, it cannot be handled as a whole, but we can construct the minimal part of it (minimality refers to the cardinality of the state set) for every state s ∈ S of a F-coalgebra C = (S, α). This is done by computing the smallest subcoalgebra in (Γ, π) containing beh C (s). More generally, given a subset F ∈ Γ of causal functions, we can compute the smallest subcoalgebra in (Γ, π), noted F , containing F. This coalgebra is called the coalgebra generated by F in (Γ, π) in [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF]. This construction will be useful to us to define our composition operators (see Chapter V). -F is the initial state, -F is the set of transfer function sets inductively defined as follows:

-

F 0 = {F} -F j = G ′ | ∃G ∈ F j-1 , ∃i ∈ In, ∃o ∈ Out, o ∈ F ∈G F (i.x)(0)
and

G ′ = {F (i.x) ′ | F (i.x)(0) = o and F ∈ G}, for x ∈ In ω chosen arbitrarily Hence, F = j<ω F j -α F : F × In → T(Out × F )
is the mapping which for every G ∈ F , and for every input i ∈ In associates η ′-1 Out× F (Π ′ ) where Π ′ is the set:

Π ′ = (o, G ′ o ) | o ∈ F ∈G (F (i.x)(0)) and, G ′ o = {F (i.x) ′ | F (i.x)(0) = o
s in the component C i 1 |o 1 i n |o n =⇒ beh C (s) beh C (s) ′ o 1 = beh C (s 1 ) beh C (s) ′ on = beh C (s n ) i 1 |o 1 i n |o n . . . beh C (s) in the component Γ
From the finality of (Γ, π), the component F generated by F in (Γ, π) can be built by a repeated computation of derivative sets starting from F. The state of F therefore contains all derivative sets of F and may eventually not be finite. In the following we will be only interested in component F with finite state spaces. [START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF]. This machine M is considered as a component M = ({s 0 , s 1 , s 2 }, s 0 , α) over the signature ({0, 1} × ) {0,1} where the transition function:

α : {s 0 , s 1 , s 2 } -→ ({0, 1} × {s 0 , s 1 , s 2 }) {0,1}
is defined as follows:

α(s 0 )(0) = (0, s 2 ) α(s 0 )(1) = (1, s 1 ) α(s 1 )(0) = (1, s 1 ) α(s 1 )(1) = (0, s 2 ) α(s 2 )(0) = (0, s 2 ) α(s 2 )(1) = (1, s 1 ) s 0 s 1 s 2 0|1 0|0 1|1 0|0 1|0 1|1 Figure IV.
F 1 (σ(k)) = k ∑ i=0 σ(i) mod 2
Now to compute the minimal component beh M (s 0 ) , we need to compute all derivative sets of trans- fer functions starting from beh M (s 0 ). With a simple computing, we can conclude that the state of beh M (s 0 ) consists of two states: {F 1 } and {F 2 } where F 2 : {0, 1} ω -→ {0, 1} ω is the transfer function defined for every σ ∈ {0, 1} ω and for every k ∈ ω by:

F 2 (σ(k)) = 1 - k ∑ i=0 σ(i) mod 2
Computing further derivative sets will not yield any new transfer functions sets. Thus, beh M (s 0 ) is the component ({F 1 , F 2 }, {F 1 }, α beh M (s 0 ) ) where:

α beh M (s 0 ) : {{F 1 }, {F 2 }} -→ ({0, 1} × {{F 1 }, {F 2 }}) {0,1}
is the transition function defined as follows:

             α beh M (s 0 ) ({F 1 })(0) = (0, {F 1 }) α beh M (s 0 ) ({F 1 })(1) = (1, {F 2 }) α beh M (s 0 ) ({F 2 })(0) = (1, {F 2 }) α beh M (s 0 ) ({F 2 })(1) = (0, {F 1 })
and can be then depicted as:

0|0 0|1 1|1 1|0

Conclusion

The contribution of this chapter is threefold: first, it shows the effectiveness of Barbosa's coalgebraic definition of components in unifying in a single framework a wide variety of state-based formalisms such as Mealy automata [START_REF] Eilenberg | Automata, Languages and Machines[END_REF][START_REF] Mealy | A method for synthesizing sequentiel circuits[END_REF], Labeled Transition Systems [START_REF] Milner | A calculus of communicating systems[END_REF][START_REF] Brookes | An Improved Failures Model for Communicating Processes[END_REF] and Input-Output Labeled Transition Systems [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF] by using a suitable choice of computation structures introduced by the monad T [START_REF] Moggi | Notions of computation and monads[END_REF][START_REF] Moggi | Computational lambda-calculus and monads[END_REF]. Second, this way of modeling the behaviour of components allows us, following Rutten's works [START_REF] Rutten | Algebraic specification and coalgebraic synthesis of mealy machines[END_REF][START_REF] Hansen | Synthesis of mealy machines using derivatives[END_REF], to define a trace model over components by causal transfer functions [START_REF] Raney | Sequential functions[END_REF]. Such functions are dataflow transformations of the form: y = F (x, s, t) where x, y and s are respectively the input, output and state of the component under consideration, and t stands for discrete time. This representation of system behaviour forms the first step towards a unified framework that will capture not only different usual computations, but also time heterogeneity (i.e. both discrete and continuous times). Indeed, in this thesis, we restrict ourselves to discrete time. However, there are other current works extending our framework to be able to take into account continuous time using non-standard analysis [START_REF] Aiguier | Modeling of complex systems: A minimalist and unified semantics for heterogeneous integrated systems[END_REF]. Third, defining a trace model from causal functions (which is the main contribution of this chapter) allows us to show the existence of a final coalgebra in the category of coalgebras over a signature T(Out × ) In under some sufficient conditions on the monad T. Final coalgebras are indeed important because their existence is the key of co-induction, a powerful reasoning principle in coalgebraic theory. Such a final minimal component model will be the cornerstone of defining how components are combined to define larger components in the following chapter.

Chapter V

Integration of components 1

Basic integration . .

. . 125

So far in this part we have seen that the easiest way to model complex systems is to describe them as compositions of simpler systems, being considered as coalgebraic components. In this chapter, we explain how to define a larger component by composition of multiple components using integration operators. Many different integration operators have been defined and studied in the literature such as sequential composition, double sequential composition, synchronous product, concurrent composition or synchronous parallel composition. Here, we will show that most of them can be obtained by a composition of two basic integration operators, namely: cartesian product and feedback. In Section 1, we will then define these two basic operators for building larger components from simpler ones. In Section 2, we will define more complex operators by composition of our basic integration operators. Finally, in Section 3, we will define how systems can be built over these complex operators defined in Section 2 and will give some concrete system examples.

Basic integration 1.Cartesian product

The cartesian product is a composition where both components are executed simultaneously when triggered by a pair of input values (see Figure V.1).

Definition 1.1 (Cartesian product ⊗) Let H 1 = T(Out 1 × ) In 1 and H 2 = T(Out 2 × ) In 2 be two signatures. Let H = T((Out 1 × Out 2 ) × ) (In 1 ×In 2 )
be the signature resulting from the product of H 1 and H 2 . Let us define the cartesian integration functor:

⊗ : Comp(H 1 ) × Comp(H 2 ) -→ Comp(H) ( (S 1 , α 1 ) In 1 -→ Out 1 -→ , (S 2 , α 2 ) In 2 -→ Out 2 -→ ) → (S, α) In 1 ×In 2 -→ Out 1 ×Out 2 -→ as follows: ∀C 1 = (S 1 , init 1 , α 1 ) ∈ Comp(H 1 ), ∀C 2 = (S 2 , init 2 , α 2 ) ∈ Comp(H 2 ), ⊗((C 1 , C 2 )) = (S, init, α)
where:

-S = S 1 × S 2 is the set of states,

-init = (init 1 , init 2 ) is the initial state, -α : S × (In 1 × In 2 ) -→ T((Out 1 × Out 2 ) × S) is the mapping defined as follows: ∀i = (i 1 , i 2 ) ∈ In 1 × In 2 and (s 1 , s 2 ) ∈ S: α((s 1 , s 2 ))(i) = η ′-1 (Out 1 ×Out 2 )×S ((o 1 , o 2 ), (s ′ 1 , s ′ 2 ))|(o 1 , s ′ 1 ) ∈ η ′ Out 1 ×S 1 (α 1 (s 1 )(i 1 )) and (o 2 , s ′ 2 ) ∈ η ′ Out 2 ×S 2 (α 2 (s 2 )(i 2 )) C 1 C 2 In 1 Out 1 In 2 Out 2 In 1 × In 2 Out 1 × Out 2 Figure V.1 -Cartesian product

Feedback

A component with feedback has directed cycles, where an output from a component is fed back to affect an input of the same component (see Figure V.2). That means the output of a component in any feedback composition depends on an input value that in turn depends on its own output value. The feedback operator is then a composition where some outputs of a component are linked to its inputs i.e. some outputs can be fed back as inputs. In order to obtain a model which fits our component definition, we need to take into account the computational effects of the monad T. This monad impacts both the evolution of component states and the observation of its outputs. Therefore, the feedback link between outputs and inputs carries part of the structure imposed by T to the inputs. For instance, with the monad built on P for modeling non-determinism, the feedback may bring non-determinism to the inputs of the component. We introduce feedback interfaces for defining correspondences between outputs and inputs of components. A feedback interface also allows us to keep only the inputs and the outputs that are not involved in feedback thanks to component-wise projections π i and π o :

Definition 1.2 (Feedback interface) Let H = T(Out × ) In be a signature. A feedback interface over H is a triplet I = ( f , π i , π o ) where: -f : In × Out -→ In is a function such that: ∀(i, o) ∈ In × Out, f ( f (i, o), o) = f (i, o)
π i : In -→ In ′ and π o : Out -→ Out ′ are surjective mappings1 such that:

∀(i, o) ∈ In × Out, π i (i) = π i ( f ((i, o)))
The mapping f allows us to specify how components are linked and which parts of their interfaces are involved in the composition process. Both mappings π i and π o can be thought of as extensions of the hiding connective found in process calculi [START_REF] Hoare | Communicating sequential processes[END_REF]. Thereby, the feedback interface enables encapsulation by making the internal interactions made in the scope of the component invisible. Such an encapsulation helps to separate both the internal behaviour and the interaction of a component from the external interaction with the global system, and thus deals with the interaction between components independently of the behaviour of individual components.

Two kinds of feedback operators are usually distinguished: relaxed feedback and synchronous feedback. The first kind means that in a reaction, the output is not simultaneous with the input. This relaxed feedback composition depends on the previous output and the current input. The second kind means that the reaction of a system takes no observable time [START_REF] Benveniste | The synchronous approach to reactive and real-time systems[END_REF]. Systems produce their outputs synchronously with their inputs. More precisely, at some reaction r, the output of system S in r must be available to its inputs in the same reaction r.

Definition 1.3 (Relaxed feedback ←֓)

Let H = T(Out × ) In be a signature and I = ( f , π i , π o ) be a feedback interface over H. Let us note H ′ = T(Out ′ × ) In ′ . Let C = (S, s 0 , α) be a component over H. Let us define for every x ∈ In ω , the set Θ x whose elements are couples ( x, y x ) ∈ In ω × Out ω inductively defined from an infinite sequence of states (s 0 , s 1 , . . . , s k , . . . ) of S as follows:

x(0) = x(0) and y

x (0) ∈ η ′ Out×S (α(s 0 )(x(0))) | 1 -∀n, 0 < n < ω, -x(n) = f (x(n), y x (n -1)) -y x (n) ∈ η ′ Out×S (α(s n )( x(n))) | 1 -and s n ∈ η ′ Out×S (α(s n-1 )( x(n -1))) | 2
Then, the operation of relaxed feedback over I, ←֓ I : Comp(H) -→ Comp(H ′ ) associates to every component C = (S, s 0 , α) over H, the component ( F , F, α F ) over H ′ where F is the set of transfer functions F : In ′ω -→ Out ′ω , each one defined by F (x ′ ) = y ′ where there exists x ∈ In ω such that there exists ( x, y x ) ∈ Θ x satisfying ∀i < ω, x ′ (i) = π i ( x(i)) and y ′ (i) = π o (y x (i)) Definition 1.3 calls for some comments. We want to build a component that hides the relaxed feedback of a component C. As one can see in Figure V.3, the relaxed feedback component ←֓ I (C) is given as a set of transfer functions, each one mapping an infinite sequence of inputs x ′ ∈ In ′ω to an infinite sequence of outputs y ′ ∈ Out ′ω . The outputs are then hidden from any state s

C π i f π o x(n) x ′ (n) y ′ (n) y x(n-1)
←֓ I (C) that are fed back as inputs to the successor of s. The result is a component with input and output sets In ′ and Out ′ respectively. This is done by means of the feedback interface I = ( f , π i , π o ).

Let us suppose that the current state of C at the n th reaction is s n ∈ S and the current external input is x(n) ∈ In, then let us compute both new input x ′ (n) ∈ In ′ and output y ′ (n) ∈ Out ′ when C is triggered by x(n). First, by f , we compute the input x(n) = f (x(n), y x(n-1) ). Then, x(n) becomes the new input of C. Indeed, component C reacts by updating its state to s n+1 and producing an output y x(n) . In this way, the output of C at the n th reaction is given by relying on the previous output y x(n-1) and the current input x(n). Second, by means of π i and π o , we hide both input and output involved in the feedback, and then produce the input

x ′ (n) = π i ( x(n))
and the output y ′ (n) = π o ( ȳ(n)) of the relaxed feedback component ←֓ I (C).

(C i ) = ( F i , F i , α F i ) for i = 1, 2 as follows:
-←֓ I ( f )(F 1 ) = F 2 -for every j, 0 < j < ω, for every G ′ ∈ F 1 j , we know by definition that there exists

G ∈ F 1 j-1 , i ∈ In and o ∈ Out such that : -o ∈ F ∈G (F (i.x)(0)) -G ′ = {F (i.x) ′ | F (i.x)(0) = o and F ∈ G} for x ∈ In ω chosen arbitrarily. It is sufficient to write down ←֓ I ( f )(G ′ ) = F ′ (i.x) ′ | F ′ (i.x)(0) = o and F ′ ∈←֓ I ( f )(G)
f being a morphism on coalgebras, we can easily show that ←֓ I ( f )(G ′ ) is nonempty.

Let us finish by showing that ←֓ I ( f ) preserves identities and compositions.

←֓ I (id C )(G ′ ) = F ′ (i.x) ′ | F ′ (i.x)(0) = o and F ′ ∈←֓ I (id C )(G) by induction hypothesis = F ′ (i.x) ′ | F ′ (i.x)(0) = o and F ′ ∈ id ←֓ I (C) (G) by definition of id ←֓ I (C) = F ′ (i.x) ′ | F ′ (i.x)(0) = o and F ′ ∈ G by hypothesis = G ′ = id ←֓ I (C) (G ′ )
For preservation of composition. Let f 1 : C 1 -→ C 2 and f 2 : C 2 -→ C 3 be two homomorphisms in Comp(H).

Let ←֓ I ( f 1 ) : F 1 -→ F 2 and ←֓ I ( f 2 ) : F 2 -→ F 3 their associated homomor- phisms in Comp(H ′ ) where ←֓ I (C 1 ) = F 1 , ←֓ I (C 2 ) = F 2 and ←֓ I (C 3 ) = F 3 .
Let us then prove by induction on the structure of F that ←֓ I (

f 2 • f 1 ) =←֓ I ( f 2 )• ←֓ I ( f 1 ).
-Basic Step: By definition of ←֓ I (

f 2 • f 1 ), one has ←֓ I ( f 2 • f 1 )(F 1 ) = F 3 by definition of ←֓ I ( f 2 ) = ←֓ I ( f 2 )(F 2 ) by definition of ←֓ I ( f 1 ) = ←֓ I ( f 2 )(←֓ I ( f 1 )(F 1 )) = ←֓ I ( f 2 )• ←֓ I ( f 1 )(F 1 ) -Induction Step: let G ′ 1 ∈ F 1 j+1 .
We know by definition of G ′ 1 that there exists

G 1 ∈ F 1 j , i ∈ In and o ∈ Out such that o ∈ F 1 ∈G 1 (F 1 (i.x)(0)) and G ′ 1 = {F 1 (i.x) ′ | F 1 (i.x)(0) = o and F 1 ∈ G 1 } for x ∈ In ω chosen arbitrarily. By definition of ←֓ I ( f 1 ), we also know that ←֓ I ( f 1 )(G ′ 1 ) = F ′ 1 (i.x) ′ | F ′ 1 (i.x)(0) = o and F ′ 1 ∈←֓ I ( f 1 )(G 1 ) . Let us denote by the set F ′ 1 (i 1 .x 1 ) ′ | F ′ 1 (i 1 .x 1 )(0) = o 1 and F ′ 1 ∈←֓ I ( f 1 )(G 1 ) by G ′ 2 .
This set belongs to F 2 . Then, we know by definition of

G ′ 2 that ∃G 2 ∈ F 2 such that G 2 =←֓ I ( f 1 )(G 1 ), o ∈ F 2 ∈G 2 (F 2 (i.x)(0)) and G ′ 2 = {F 2 (i.x) ′ | F 1 (i.x)(0) = o and F 2 ∈ G 2 }. By definition of ←֓ I ( f 2 ), we know that ←֓ I ( f 2 )(G ′ 2 ) = F ′ 2 (i.x) ′ | F ′ 2 (i.x)(0) = o and F ′ 2 ∈←֓ I ( f 2 )(G 2 )
. Now, we have that

←֓ I ( f 2 )• ←֓ I ( f 1 )(G ′ 1 ) = ←֓ I ( f 2 )(←֓ I ( f 1 )(G ′ 1 )) = ←֓ I ( f 2 )(G ′ 2 ) = F ′ 2 (i.x) ′ | F ′ 2 (i.x)(0) = o and F ′ 2 ∈←֓ I ( f 2 )(G 2 ) = F ′ 2 (i.x) ′ | F ′ 2 (i.x)(0) = o and F ′ 2 ∈←֓ I ( f 2 )(←֓ I ( f 1 )(G 1 )) = F ′ 2 (i.x) ′ | F ′ 2 (i.x)(0) = o and F ′ 2 ∈←֓ I ( f 2 )• ←֓ I ( f 1 )(G 1 ) by induction hypothesis = F ′ 2 (i.x) ′ | F ′ 2 (i.x)(0) = o and F ′ 2 ∈←֓ I ( f 2 • f 1 )(G 1 ) = ←֓ I ( f 2 • f 1 )(G ′ 1 )

End

∈ N * n i+1 →      n i /2 i f n i ≡ 0 (mod 2) 3n i + 1 otherwise
This sequence starts with any positive integer n, and produces at each step either half of itself (i.e. n/2) if it is even or three times itself plus one (i.e. 3n + 1) if it is odd. We can easily see that any output n i produced at the i th step is linked to the input at the (i + 1) th i.e. n i will be considered as the input at the next step. Then, there is a relaxed feedback. Figure V. 4 shows the component that can be considered as a structural model of the Syracuse sequence. When a new positive integer n is available, it is directly available as an input of the component C that produces it as output. If n is even, n is sent to the component DivideBy2 which produces as an output (n/2). If n is odd, n is sent to the component MultipleBy3Plus1 which produces as an output (3n + 1). Both outputs of DivideBy2 and MultipleBy3Plus1 are linked to the component ∆ which is considered as a unit delay allowing time to pass. This sequence can be modeled in our framework as a component S = (S, init, α) over the functor

(N * × ) ({⊥}×N * )∪N *
where:

-init is the initial state; -of the form i where i stands for the initial input received from the environment (i.e. the integer for which we compute its associated Syracuse sequence). For instance, α(init) [START_REF] Barbosa | State-based components made generic[END_REF] = (10, s 10 ) states that the component starts running by receiving from the environment an input value 10 and goes to state s 10 while producing the output value 10.

-S = {s i | i ∈ N * } ∪ {init} is the set of states; -α : S × (({⊥} × N * )} ∪ N * ) -→ N * × S is defined as follows: α(init)(k) = (k, s k ) for every k ∈ N * and α(s k )((⊥, k)) =    (k/2, s k/2 ) if k ≡ 0 (mod 2) (3k + 1, s 3k+1 ) otherwise
-or pair of input values (⊥, i) where ⊥ is the external input value received from the environment3 and i is the input value feeding back from the output. For instance, α(s 10 )((⊥, 10)) = (5, s 5 ) expresses that the component receives no value from the environment and the input value 10 feeding back from the output and goes to state s 5 while producing the output value 5.

Starting with the initial state init, one gets for example the following execution: Let us now compute the Syracuse's feedback component. We need to compute a transfer function that takes an input value n 0 and computes its associated Syracuse sequence. For this, we have to hide both the input and output values involved in the feedback. Taking Sequence V.1, one needs to hide the output values 3, 10, 5, 16, 8, 4 and 2 in (⊥, 3), (⊥, 10), (⊥, 5), (⊥, 16), (⊥, 8), (⊥, 4), (⊥, 2) that are fed back as inputs. This can be obtained by applying the relaxed feedback operator ←֓ I on S where I = ( f , π i , π o ) is the feedback interface defined as follows:

-f : {⊥} × N * -→ {⊥} × N * is the identity on {⊥} × N * ; π i is the function defined as follows:

π i : N * ∪ ({⊥}, N * ) → N * ∪ {⊥} n → n (⊥, n) → ⊥ -π o : N * -→ N *
is the identity function on N * . Thus, the input-output feedback sequence computed from Sequence V.1 is the following: 3|3, ⊥|10, ⊥|10, ⊥|5, ⊥|16, ⊥|8, ⊥|4, ⊥|2, ⊥|1

Hence, it becomes clear that ←֓ I (S) is equal to the component F with F as the set containing the unique transfer function F : (N * ∪ {⊥}) ω -→ N * ω defined for every input sequence σ ∈ (N * ∪ {⊥}) ω and for every k ∈ ω as follows:

F (σ)(k) =              σ(k) i f σ(k) = ⊥ (F (σ)(k -1))/2 i f F (σ)(k -1) is even (3 × F (σ)(k -1)) + 1 i f F (σ)(k -1)

is odd otherwise

The synchronous feedback is more difficult to define because it requires the existence of an instantaneous fixpoint (i.e. defined at the same time and not deferred by one unit). This gives rise to the notion of well-formed feedback composition.

Definition 1.4 (Well-formed feedback composition)

Let H = T(Out × ) In be a signature. Let C be a component over H and I = ( f , π i , π o ) be a feedback interface over H. We say that the synchronous feedback composition C over I is well-formed if, and only if for every state s ∈ S and every x ∈ In ω : there exists y ∈ Out ω such that for every n < ω, y(n

) ∈ η ′ Out×S (α(s)( f (x(n), y(n)))) | 1
We illustrate the last definition with the following example:

Example 1.2 (Well-formed composition) Consider two components C 1 = ({s 1 , s 2 }, s 1 , α 1 ) and C 2 = ({q 1 , q 2 }, q 1 , α 2 ) over the signature ({T, F} × ) {T,F}
with the transition function α 1 (respectively α 2 ) graphically drawn on the left side (respectively on the right side) of Figure V. [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF]. There is then a feedback composition for C 1 and a feedback composition for C 2

I = ( f , π i , π o )
as the "and" logic operator. More formally, f : {T, F} × {T, F} -→ {T, F} is defined as follows:

f ((i, o)) =    F if i = F or o = F T otherwise
The composition of the component C 1 is well-formed. This is due to the fact that for every state s ∈ {s 1 , s 2 } and for every input sequence x ∈ {T, F} ω there exists an output y ∈ {T, F} ω such that for every n, n < ω, y(n) ∈ α 1 (s)( f (x(n), y(n))). More precisely 4 , one has:

-F ∈ α(s 1 )( f (F, F)) -F ∈ α(s 1 )( f (T, F)) -T ∈ α(s 2 )( f (F, T)) -T ∈ α(s 2 )( f (T, T))
On the other hand, the feedback composition of C 2 is not well-formed. Indeed, similarly, as just shown above for s 1 , one gets a fixed point in state q 1 for both input F and T. But, there is no fixed point in state q 2 i.e. given an input sequence x ∈ {T, F} ω , there is no output sequence y(n) ∈ {T, F} ω such that y(n) ∈ α 2 (q 2 )( f (x(n), y(n)))). In fact, if we attempt to choose x(n) = F, then C 2 may stay in state q 2 and its output may be the same as the fed back input T (T ∈ α 2 (q 2 )( f (F, T))). If we attempt to choose x(n) = T, then C 2 may go either to state q 1 and its output is not the same as the fed back input T (T ∈ α 2 (q 2 )( f (T, T)), or to stay in state q 2 and its output is not the same as the fed back input F (F ∈ α 2 (q 2 )( f (T, F))).

Hence, systems with feedbacks not well-formed (called ill-formed) will be rejected. They are considered to be unstable and insecure systems.

∀n, 0 ≤ n < ω, (y(n), s n+1 ) ∈ η ′ Out×S (α(s n )( f (x(n), y(n))
)) (by hypothesis, C's feedback composition being well-formed over I, such y exists) Then, the operation of synchronous feedback over I is the partial mapping

I : Comp(H) -→ Comp(H ′ )
that associates to every component C = (S, s 0 , α) over H whose feedback composition is well-formed, the component ( F , F, α F ) over H ′ where F is the set of transfer functions F : In ′ω -→ Out ′ω , each one defined by F (x ′ ) = y ′ where there exists x ∈ In ω s.t. there exists y ∈ Θ x satisfying ∀i, i < ω, x ′ (i) = π i (x(i)) and y ′ (i) = π o (y x (i)) The function F : {T, F} ω -→ {F, T} ω defined for every x ∈ {T, F} ω and for every k, 0 ≤ k < ω, by:

F (x)(k) =    F i f k is even T otherwise
is the unique transfer function that can be defined using our synchronous feedback definition. Indeed, both associated outputs to each input x ∈ {T, F} from s 1 are F, and both associated outputs to each x ∈ {T, F} from s 2 are T. Then the feedback composite I (C) over the signature I is the component ( {F } , {F }, α {F } ) where the set of states {F } is obtained by a repeated computation of derivative starting from {F }. The states of {F } then contain the set of all derivative functions of F that are F and F ′ where F ′ : {T, F} ω -→ {F, T} ω is the function defined for every x ∈ {T, F} ω and for every k, 0 ≤ k < ω, by:

F ′ (x)(k) =    T i f k is even F otherwise
Note that computing further derivative sets will not yield any new transfer functions sets.

This then leads to the following component {F } :

q 0 q 1 T,F|F T,F|T
We can also define the feedback in terms of its argument as concrete coalgebras, as done for the product in Definition 1.1, and not on behaviours as done in Definition 1.3 and Definition 1. [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF]. For the synchronous feedback, this leads to: Definition 1.6 (Synchronous feedback c ) Let H = T(Out × ) In be a signature and I = ( f , π i , π o ) be a feedback interface over H. Let us note H ′ = T(Out ′ × ) In ′ . The operation of synchronous 5 feedback over I is the partial functor c I : Comp(H) -→ Comp(H ′ ) that associates to every com- ponent C = (S, init, α) over H whose the feedback composition over I is well-formed, the component C ′ = (S ′ , init ′ , α ′ ) over H ′ such that:

-S ′ = S -init ′ = init; -α ′ : S ′ -→ T(Out ′ × S ′ )
In ′ is the transition mapping defined by: ∀s

′ 1 ∈ S ′ , ∀i ′ ∈ In ′ , α ′ (s ′ 1 )(i ′ ) = η ′-1 Out ′ ×S ′ (Π) where Π is the set: Π = (o ′ , s ′ 2 ) | ∃i ∈ In, ∃o ∈ Out, (o, s ′ 2 ) ∈ η ′ Out×S (α(s ′ 1 )( f (i, o))), π i (i) = i ′ and π o (o) = o ′
Relaxed feedback can be defined similarly. Definition 1.5 and Definition 1.6 are equivalent. Indeed, it is obvious to check that

beh c I (C) (init ′ ) = beh I (C) (F) = F Although, c
I is defined more uniformly with product ⊗ because both are defined as concrete coalgebras, the interest of I (resp. ←֓ I ) is that the resulting component is the minimal one. This will allow easier compositionality proofs such as those given in Section 3.3 and Section 1.1 of Chapter VIII.

The exponent c in c

I is to express that feedback is defined in terms of its argument as concrete coalgebras.

Complex operators

As previously explained, both cartesian product and feedback operators depend mainly on the component structure. However, when modeling systems, there is not only a need to specify component structure, but also some requirements for the input and output sets. On one hand, there is a need to make some component actions private and therefore inaccessible or hidden to the environment. To make this possible, our framework has to offer an operation to do that. This operator is classically called hiding 6 . Hidding aims to delimit the scope of both input and output sets. Let us observe that this operator can be naturally defined in terms of the feedback operator by taking the elements f , π i and π o of the feedback interface I as follows:

f : In × Out -→ In is the mapping defined by (i, o) → i;

π i : In -→ {abs} ∪ In \ In ′ is the mapping defined by:

π i (i) = i if i ∈ In \ In ′ abs otherwise -π o : Out -→ {abs} ∪ Out \ Out ′
is the mapping defined by:

π o (o) = o if o ∈ Out \ Out ′ abs otherwise
In the following, we denote by C[h in , h out ] a component C over T(Out × ) In in which In and Out are restricted using h in and h out where h in and h out stand for π i and π o respectively.

On the other hand, we need another operation that allows us to rename component actions. This is useful when components have a common behavioural pattern and can be seen as specific instances of a generic component. We then define an operation called renaming 7 aiming to rename inputs and outputs of components. The renaming operation is defined as a pair of bijective functions r in : In -→ In ′ and r out : Out -→ Out ′ that maps each i ∈ In to an element i ′ ∈ In ′ (respectively, each o ∈ Out to an element o ∈ Out ′ ). We denote by C] r in ,r out a component C over T(Out × ) In in which In and Out are renamed using r in and r out .

Definition 2.1 (Complex operator)

The set of complex operators, is inductively defined as follows:

-is a complex operator of arity 1;

-op is a complex operator of arity n and (r in , r out ) is a renaming couple, then (r in , r out )(op) is a complex operator of arity n;

-if op 1 and op 2 are complex operators of arity n 1 and n 2 respectively, then op 1 ⊗ op 2 is a complex operator of arity n 1 + n 2 ;

-if op is complex operator of arity n and I is a feedback interface, then I (op) is a complex operator of arity n;

-if op is complex operator of arity n and I is a feedback interface, then ←֓ I (op) is a complex operator of arity n. [START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF]. also known as restriction operation. [START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF]. also known as relabeling operation.

To show that both cartesian product and feedback operators are expressive enough to define, by composition, standard composition operators, we explain in this section how sequential, double sequential, concurrent and synchronous parallel compositions, and synchronous product can be obtained by their composition. Hence, the definition of the feedback interface I = ( f , π i , π o ) is rather wide and abstract in the sense that each suitable choice of f , π i and π o gives a particular semantic to the feedback composition and then a way of defining the global and final reaction of the composition of a set of components.

Before defining these operators in our framework, let us note two important points: -there seems to be no consensus on the terminologies used to describe composition operators. For instance, sequential composition is introduced as "cascade composition" in [START_REF] Lee | Structure and interpretation of signals and systems[END_REF][START_REF] Lee | Introduction to Embedded Systems -A Cyber-Physical Systems Approach[END_REF] and "1-way-cascade" in [START_REF] Yevtushenko | Sequential synthesis by language equation solving[END_REF], the synchronous parallel composition is called "synchronous composition" in [START_REF] Petrenko | Solving asynchronous equations[END_REF] and does not have the same semantic as "interleaving parallel composition" introduced in [START_REF] Yevtushenko | Sequential synthesis by language equation solving[END_REF]. The cartesian product where the set of inputs are considered as disjoint is called "synchronous side-by-side composition" in [START_REF] Lee | Introduction to Embedded Systems -A Cyber-Physical Systems Approach[END_REF]. The concurrent composition is called "asynchronous side-by-side composition" in [START_REF] Lee | Introduction to Embedded Systems -A Cyber-Physical Systems Approach[END_REF], and there are many other examples. Therefore, we prefer to choose the terminology the best adapted to our framework, and give the informal definition of each operator before giving its formal definition to avoid any confusing terminology. Further technical details about the different kinds of composition presented in the following can be found in textbooks such as [84, 85,

-The symbol abs is previously used to express the absence of component reaction when modeling IOLTS as components. Here, it is also useful for building complex components. Hence, the sets In 1 and In 2 (respectively, Out 1 and Out 2 ) may include some special action, denoted by abs, in order to allow components to stutter 8 . For instance, if the input action is (abs, i 2 ) with i 2 = abs, the reaction of the composite consists only of the reaction of the second component (i.e. the composite behaves like the second component). Double stuttering corresponds to the input (abs, abs) with the following additional requirement that, for any s ∈ S 1 × S 2 , η ′ (Out1×Out 2 )×S (α(s)((abs, abs))) = {((abs, abs), s)}. We will see later in this section that this can be useful for building larger components from smaller ones using composition. This is of interest if we want to take into account a reaction of the composite with only one of the components that reacts.

Sequential composition

The sequential composition (called also cascade composition, or series composition), denoted by C = ⊲((C 1 , C 2 )), of two components C 1 and C 2 corresponds to a composition where both components C 1 and C 2 are interconnected side-by-side and the output of one is the input of the other.

Figure V.6 illustrates this kind of composition.

A reaction of C consists then of a reaction of both C 1 and C 2 , where C 1 reacts first, produces its outputs, and then C 2 reacts. That is to say, when C 1 is triggered by an input i from the environment, C 1 executes i and the produced output is fed to C 2 . A requirement for this composition to be defined is that Out 1 has to be included into In 2 (Out 1 ⊆ In 2 ). This ensures that any output produced by C 1 is an acceptable input to C 2 . This kind of composition can be naturally defined in our framework using both the feedback operator and the cartesian product by:

⊲((C 1 , C 2 )) = ⊖ I ((C 1 ⊗ C 2 )) (V.2)
f ((i, i ′ ), (o, o ′ )) = (i, o), π i ((i, i ′ )) = i and π o ((o, o ′ )) = o ′
and ⊖ stands for ←֓ or depending on whether we want a relaxed or instantaneous sequential composition. For the first sequential composition, the output o produced from the component C 1 after triggering by an input i takes some observable time to feed to the component C 2 . In this case, ⊲ will be denoted by ⊲ r . For the second one, the output o produced from the component C 1 after triggering by an input i is directly fed to the input of the component C 2 . In this case, ⊲ will be denoted by ⊲ s . Note that in both cases there is a causality dependency; that is, the outputs of C 1 can affect the behaviour of C 2 i.e. sequential composition entails an ordering of the component reactions.

As already mentioned, our synchronous feedback operator is only applied to systems whose composition is well-formed. Therefore, applying this operator to the cartesian product ⊗((C 1 , C 2 )) of two components C 1 and C 2 requires that the composition of ⊗((C 1 , C 2 )) is wellformed.

Theorm 2.1

Let H 1 = T(Out 1 × ) In 1 and H 2 = T(Out 2 × ) Out 1 be two signatures such that Out 1 ⊆ In 2 . Let I = ( f , π i , π o ) be the feedback interface defined for every (i, i ′ ) ∈ In 1 × In 2 and every (o, o ′ ) ∈ Out 1 × Out 2 as follows:

f ((i, i ′ ), (o, o ′ )) = (i, o), π i ((i, i ′ )) = i and π o ((o, o ′ )) = o ′ Let C 1 ∈ Comp(H 1 ) and C 2 ∈ Comp(H 2 ). Then the feedback composition of ⊗((C 1 , C 2 )) is well-formed. Proof Let C 1 = (S 1 , α 1 ) ∈ Comp(H 1 ), C 2 = (S 2 , α 2 ) ∈ Comp(H 2 ) and C = ⊗((C 1 , C 2 )) = (S, α)
be the cartesian product of C 1 and C 2 . Let us show that the synchronous feedback composition of C is well-formed. For this, let (s 1 , s 2 ) ∈ S be a state in S and (i 1 , i 2 ) be an input in In 1 × In 2 and then show that there exists an output (o 1 , o 2 ) ∈ Out 1 × Out 2 such that:

(o 1 , o 2 ) ∈ η ′ (Out 1 ×Out 2 )×S (α((s 1 , s 2 ))( f ((i 1 , i 2 ), (o 1 , o 2 )))) | 1 (1) i.e. by the definition of f (o 1 , o 2 ) ∈ η ′ (Out 1 ×Out 2 )×S (α((s 1 , s 2 ))((i 1 , o 1 ))) | 1 (i 1 , i 2 ) ∈ In 1 × In 2 , then there exists an output o 1 ∈ η ′ Out 1 ×S 1 (α 1 (s 1 )(i 1 )) | 1 .
We also know that o 1 is an input of C 2 since Out 1 ⊆ In 2 . Hence, there exists an output o

2 ∈ η ′ Out 2 ×S 2 (α 2 (s 2 )(o 1 )) | 1 .
We can now conclude that (i 1 , o 1 ) is an input of C and there exists an output (o 1 , o 2 ) of C such that:

(o 1 , o 2 ) ∈ η ′ (Out 1 ×Out 2 )×S (α((s 1 , s 2 ))((i 1 , o 1 ))) | 1
Consequently, (1) is verified.

End

Let us explain now how the synchronous sequential composition of two components can be obtained with our modeling. Two components C 1 and C 2 are sequentially interconnected by linking the output of C 1 to the input of C 2 . This interconnection is made without taking time (i.e. instantaneously). Suppose that at the n th reaction the input action of C = ⊲ s ((C 1 , C 2 )) is x(n) = (i 1n , i 2n ), the state is s n = (s 1n , s 2n ) (s 1n is the state of component C 1 and s 2n is the state of component C 2 ). There is an output action y

(n) = (o 1n , o 2n ) ∈ η ′ Out×S (s n )( f (x(n), y(n))
| 1 because the feedback composition of C is well-formed. Then, f ((i 1n , i 2n ), (o 1n , o 2n )) becomes the new input action of C. This is equal to (i 1n , o 1n ) according to the definition of I. This means i 1n becomes the input of C 1 and the output action o 1n of C 1 becomes the input of C 2 at the n th reaction. Then, component C 1 (resp. C 2 ) reacts by updating its state to s 1(n+1) (resp. to s 2(n+1) ) and producing an output action o 1n (resp. o 2n ). Finally, to omit outputs that are involved in the feedback, we use π i and π o . Hence, at any reaction n, π i ((i 1n , i 2n )) = i 1n and π o ((o 1n , o 2n )) = o 2n .

Double sequential composition

The double sequential composition, denoted by C =⊲⊳ ((C 1 , C 2 )), of two components C 1 and C 2 is a composition in which the system can be triggered either by an input of C 1 and then feeds the output produced to C 2 or by an input of C 2 and then feeds the output produced to C 1 (see Figure

V.7). C 1 In 1 Out 1 ⊲⊳ C 2 In 2 Out 2 C (In 1 ∪ In 1 ) \ (Out 1 ∪ Out 2 ) Out 1 ∪ Out 2 Figure V.

-Double sequential composition

In our framework, this kind of composition can be obtained by modifying the cartesian product to be able to express not only the component reaction of the form (i 1 , i 2 )/(o 1 , o 2 ) but also those of the form (i 2 , i 1 )/(o 2 , o 1 ) while keeping the sequential feedback interface I as defined in Section 2. 1. In other words, we extend the cartesian product operator ⊗ to an operator ⊗ e taking as input the set (In 1 × In 2 ) ∪ (In 2 × In 1 ) and as output the set (Out

1 × Out 2 ) ∪ (Out 2 × Out 1 )
. This operator can be naturally expressed using both the sequential operator ⊲ s and the cartesian product ⊗ as follows:

⊗ e ((C 1 , C 2 )) = ⊲ s (⊲ s (C 0 , ⊗(C 1 , C 2 )), C ′ 0 ) (V.3)
where:

-C 0 = ({init 0 }, init 0 , α 0 ) is the component over the signature

T((In 1 × In 2 ) × ) (In 1 ×In 2 )∪(In 2 ×In 1 )
where α 0 is the transition mapping defined by: ∀(i, i ′ ) ∈ (In

1 × In 2 ) ∪ (In 2 × In 1 ) α 0 (init 0 )(i, i ′ ) =    ((i, i ′ ), init 0 ) if (i, i ′ ) ∈ In 1 × In 2 ((i ′ , i), init 0 ) otherwise -C ′ 0 = ({init ′ 0 }, init ′ 0 , α ′ 0 ) is the component over the signature T((Out 1 × Out 2 ) ∪ (Out 2 × Out 1 ) × ) (Out 1 ×Out 2 )
where α ′ 0 is the transition mapping defined by: ∀

(o, o ′ ) ∈ Out 1 × Out 2 α ′ 0 (init ′ 0 )(o, o ′ ) =    ((o, o ′ ), init ′ 0 ) if (o, o ′ ) ∈ (Out 1 ∩ In 2 ) × Out 2 ((o ′ , o), init ′ 0 ) if (o, o ′ ) ∈ Out 1 × (Out 2 ∩ In 1 ) C 1 In 1 Out 1 ⊗ e C 2 In 2 Out 2 C (In 1 × In 2 ) ∪ (In 2 × In 1 ) (Out 1 × Out 2 ) ∪ (Out 2 × Out 1 ) Figure V.8 -Extended cartesian product ⊗ e Now, it is expected that ⊲⊳ (C 1 , C 2 ) should be I (⊗ e (C 1 , C 2 )
) with I as the sequential feedback interface, however this is not the case due to the fact that the feedback composition of ⊗ e (C 1 , C 2 ) over the sequential interface I is not necessarily well-formed. Indeed, ⊗ e (C 1 , C 2 ) may take an input (i 1 , i 2 ) for which there is no output (o 1 , o 2 ) that feeds back as input to ⊗ e (C 1 , C 2 ). For instance, when i 1 ∈ In 1 ∩ Out 2 and i 2 ∈ In 2 \ Out 1 . To cope with this problem, it suffices to replace the set of inputs of ⊗ e (C 1 , C 2 ) by

((In 2 \ Out 2 ) × (In 2 ∩ Out 1 )) ∪ ((In 2 \ Out 1 ) × (In 1 ∩ Out 2 ))
instead of (In 1 × In 2 ) ∪ (In 2 × In 1 ), and define C 0 over the signature T((In 1 × In 2 ) × ) ((In 1 \Out 2 )×(In 2 ∩Out 1 ))∪((In 2 \Out 1 )×(In

1 ∩Out 2 ))
where α 0 is the transition mapping defined by:

∀(i, i ′ ) ∈ ((In 1 \ Out 2 ) × (In 2 ∩ Out 1 )) ∪ ((In 2 \ Out 1 ) × (In 1 ∩ Out 2 )) α 0 (init 0 )((i, i ′ )) =    ((i, i ′ ), init 0 ) if (i, i ′ ) ∈ (In 1 \ Out 2 ) × (In 2 ∩ Out 1 ) ((i ′ , i), init 0 ) otherwise Figure V
.9 illustrates a simple example of the application of the extended cartesian product.

Hence, it is easy to see that the synchronous feedback composition of ⊗ e ((C 1 , C 2 )) is wellformed. Thus, the double sequential composition is defined by:

⊲⊳ ((C 1 , C 2 ) = I (⊗ e (C 1 , C 2 )) (V.4)
with I is the sequential feedback interface.

Synchronous product

The synchronous product, denoted by C = ⊛((C 1 , C 2 )), of two components C 1 and C 2 corresponds to a composition where both components C 1 and C 2 are executed independently or jointly, depending on the input. Hence, C 1 and C 2 are simultaneously executed when triggered by a joint input i that belongs to both inputs set of C 1 and C 2 (see Figure V.10). This kind of product can also be naturally expressed in terms of the synchronous feedback operator and the cartesian product (see Figure V.11) as follows:

⊛((C 1 , C 2 )) = ⊲ s (C 0 , (C 1 ⊗ C 2 )) (V.5)
where C 0 = ({init 0 }, init 0 , α 0 ) is the component over the signature

T((In 1 × In 2 ) × ) In 1 ∪In 2
where α 0 is the transition mapping defined by: ∀i ∈

In 1 ∪ In 2 α 0 (init 0 )(i) =        ((i, i), init 0 ) if i ∈ In 1 ∩ In 2 ((i, abs), init 0 ) if i ∈ (In 1 \ In 1 ∩ In 2 ) ((abs, i), init 0 ) otherwise C 0 C 1 C 2 In 1 ∪ In 2 Out 1 × Out 2 Figure V.11 -Synchronous product: ⊛((C 1 , C 2 )) = ⊲ s (C 0 , (C 1 ⊗ C 2 ))

Concurrent composition

The concurrent composition, denoted by C = ⊕((C 1 , C 2 )), of two components C 1 and C 2 corresponds to a composition where both components C 1 and C 2 are executed independently or jointly, depending on the input received from environment. It combines both choice and parallel compositions, in the sense C 1 and C 2 can be simultaneously executed when triggered by a pair of inputs (i 1 , i 2 ) (i 1 belongs to inputs set of C 1 and i 2 belongs to inputs set of C 2 ), or separately when triggered by an input i: if i ∈ In 1 , then C 1 is executed and the reaction of C is that of C 1 , otherwise C 2 is executed and the reaction of C is that of C 2 . Figure V.12 illustrates this kind of composition.

C 1 In 1 Out 1 ⊕ C 2 In 2 Out 2 C In 1 ∪ In 2 ∪ In 1 × In 2 Out 1 ∪ Out 2 ∪ Out 1 × Out 2 Figure V.12 -Concurrent composition
This kind of composition can also be naturally expressed in terms of the synchronous feedback operator and the cartesian product (see Figure V.13) as follows:

⊕((C 1 , C 2 )) = ⊲ s (⊲ s (C 0 , (C 1 ⊗ C 2 )), C ′ 0 ) (V.6)
where -C 0 = ({init 0 }, init 0 , α 0 ) is the component over the signature

T((In 1 × In 2 ) × ) In 1 ∪In 2 ∪In 1 ×In 2
where α 0 is the transition mapping defined by: ∀i ∈

In 1 ∪ In 2 ∪ In 1 × In 2 α 0 (init 0 )(i) =        (i, init 0 ) if i ∈ In 1 × In 2 ((i, abs), init 0 ) if i ∈ In 1 ((abs, i), init 0 ) otherwise -C ′ 0 = ({init ′ 0 }, init ′ 0 , α ′ 0 ) is the component over the signature T((Out 1 ∪ Out 2 ∪ Out 1 × Out 2 ) × ) Out 1 ×Out 2
where α ′ 0 is the transition mapping defined by: ∀o

= (o 1 , o 2 ) ∈ Out 1 × Out 2 α ′ 0 (init ′ 0 )(o) =        (o 1 , init ′ 0 ) if o ∈ Out 1 × {abs} (o 2 , init ′ 0 ) if o ∈ {abs} × Out 2 (o, init ′ 0 ) otherwise C 0 C 1 C 2 C ′ 0 In 1 ∪ In 2 ∪ In 1 × In 2 Out 1 ∪ Out 2 ∪ Out 1 × Out 2 Figure V.13 -Concurrent composition: ⊕((C 1 , C 2 )) = ⊲ s (⊲ s (C 0 , (C 1 ⊗ C 2 )), C ′ 0 )

Synchronous parallel composition

The synchronous parallel composition, denoted by C = ⊙((C 1 , C 2 )), of two components C 1 and C 2 is a composition in which both C 1 and C 2 are executed independently or jointly depending on the input, in such a way that each input action received by C from the environment consists exclusively of an input action of either C 1 or C 2 i.e. there is no common input action for C 1 and C 2 . Indeed, when the global system receives an input which is supposed to be an input action of C 1 , C 1 reacts by producing an output. If that output does not belong to the input set of C 2 , the reaction of the global system consists only of the reaction of C 1 . Otherwise, the output produced is directly fed to C 2 and the reaction of the global system consists of the reaction of both C 1 and C 2 (one falls into the same composition as the sequential9 composition). In the same manner, when the global system receives an input supposed to be an input action of C 2 , C 2 reacts by producing an output. If that output does not belong to the input set of C 1 , the reaction of the global system consists only of the reaction of C 2 . Otherwise, the output produced is directly fed to C 1 and the reaction of the global system consists of the reaction of both C 1 and C 2 (see Figure V.14).

C 1 In 1 Out 1 Out 1 ∩ In 2 Out 2 ∩ In 1 C 2 In 2 Out 2 C In 1 ∪ In 2 \ Out 1 ∪ Out 2 Out 1 ∪ Out 2 \ In 1 ∪ In 2 Figure V.

-Synchronous parallel composition

This kind of composition can be seen as a general composition embodying both the synchronous and parallel (or interleaving parallel) aspects of composition. On one hand, it is synchronous in the sense that all common actions between C 1 and C 2 are synchronized. That means each output of C 1 that is fed as input of C 2 (i.e. Out 1 ∩ In 2 ) and each output of C 2 that is fed as input of C 1 (Out 2 ∩ In 1 ) are hidden (i.e. synchronized). They are not observable from the outside. On the other hand, it is parallel in the sense that both components C 1 and C 2 are considered autonomous, that is to say, a component may produce an output o regardless of whether o is specified as an input of the other component.

This kind of operator is not easy to be formally defined in our framework without any special treatment. In fact, it is not clear how the global reaction of the integrated system is given when outputs produced by C 1 (respectively C 2 ) are unspecified in C 2 (respectively C 1 ). Nevertheless, let us observe that if the concurrent composition operator ⊕ is extended to an operator ⊕ e taking as inputs not only the set In 1 ∪ In 2 ∪ In 1 × In 2 , but also the set In 2 × In 1 , and modifying the sequential feedback signature to deal with cases where component outputs are not fed back as inputs, we do not have that problem.

C 1 In 1 Out 1 ⊕ e C 2 In 2 Out 2 C (In 1 \ Out 1 ) ∪ (In 2 \ Out 2 ) ∪ ((In 1 ∩ Out 2 ) × (In 2 ∩ Out 1 )) ∪ ((In 2 \ Out 1 ) × (In 1 ∩ Out 2 )) Out 1 ∪ Out 2 ∪ Out 1 × Out 2 ∪ Out 2 × Out 1 Figure V.15 -Extended concurrent composition ⊕ e
Let us first define the extended concurrent operator ⊕ e . Similarly as ⊕, ⊕ e can also be naturally expressed in terms of the synchronous feedback operator and the cartesian product as follows:

⊕

e ((C 1 , C 2 )) = ⊲ s (⊲ s (C 0 , (C 1 ⊗ C 2 )), C ′ 0 ) (V.7)
where 1. C 0 = ({init 0 }, init 0 , α 0 ) is the component over the signature T((In 1 × In 2 ) × ) (In 1 \Out 2 )∪(In 2 \Out 1 )∪((In 1 \Out 2 )×(In 2 ∩Out 1 ))∪((In 2 \Out 1 )×(In

1 ∩Out 2 ))
where α 0 is the transition mapping defined by: ∀i ∈ (In

1 \ Out 2 ) ∪ (In 2 \ Out 1 ) ∪ ((In 1 \ Out 2 ) × (In 2 ∩ Out 1 )) ∪ ((In 2 \ Out 1 ) × (In 1 ∩ Out 2 )) α 0 (init 0 )(i) =              ((i 1 , i 2 ), init 0 ) if i = (i 1 , i 2 ) ∈ ((In 1 \ Out 2 ) × (In 2 ∩ Out 1 )) ((i 2 , i 1 ), init 0 ) if i = (i 1 , i 2 ) ∈ ((In 2 \ Out 1 ) × (In 1 ∩ Out 2 )) ((i, abs), init 0 ) if i ∈ (In 1 \ Out 2 ) ((abs, i), init 0 ) otherwise 2. C ′ 0 = ({init ′ 0 }, init ′ 0 , α ′ 0 ) is the component over the signature T((Out 1 ∪ Out 2 ∪ (Out 1 × Out 2 ) ∪ (Out 2 × Out 1 )) × ) Out 1 ×Out 2
where α ′ 0 is the transition mapping defined by: ∀o [START_REF] Moggi | Notions of computation and monads[END_REF] illustrates a simple example of the application of the extended concurrent operator. In this way, the synchronous parallel composition is defined in our framework as:

= (o 1 , o 2 ) ∈ Out 1 × Out 2 α ′ 0 (init ′ 0 )(o) =              (o 1 , init ′ 0 ) if o ∈ Out 1 × {abs} (o 2 , init ′ 0 ) if o ∈ {abs} × Out 2 (o, init ′ 0 ) if o ∈ Out 1 × Out 2 ((o 2 , o 1 ), init ′ 0 ) otherwise Figure V.
⊙(C 1 , C 2 ) = I (⊕ e (C 1 , C 2 )) (V.8) with I = ( f , π i , π o ) is the feedback interface defined: ∀i ∈ (In 1 \ Out 2 ) ∪ (In 2 \ Out 1 ) ∪ ((In 1 \ Out 2 ) × (In 2 ∩ Out 1 )) ∪ ((In 2 \ Out 1 ) × (In 1 ∩ Out 2 )) and o ∈ Out 1 ∪ Out 2 ∪ (Out 1 × Out 2 ) ∪ (Out 2 × Out 1
) as follows:

f (i, o) =    i if i ∈ (In 1 \ Out 2 ) ∪ (In 2 \ Out 1 ) (i 1 , o 1 ) with i = (i 1 , i 2 ) and o = (o 1 , o 2 ) otherwise
3 Systems and compositionality

Systems

Complex operators for basic components yield larger components that we will call systems. However, it is not always possible to yield a component for a complex operator from any set of basic components passed in arguments. Indeed, for a complex operator of the form I (op), according to the component C resulting from the evaluation of op, the interface I has to be defined over the signature of C and the feedback over C has to be well-formed over I. This leads up to the following definition: Definition 3.1 (Systems) Let C be a set of components. The set of systems over C is inductively defined as follows:

-for any C ∈ C, a component over a signature H, (C) = C is a system over H and is defined for C;

-if (r in , r out )(op) is a complex operator of arity n, then for every sequence (C 1 , . . . , C n ) of components with (S, init, α) (In) such that: S ′ = S, init ′ = init and ∀s ′ ∈ S ′ , ∀i ′ ∈ r in (In)

) = op(C 1 , . . . , C n ) is over T(Out × ) In , then (r in , r out )op(C 1 , . . . , C n ) is the component (S ′ , init ′ , α ′ ) over T(r out (Out) × ) r in
η ′-1 (α ′ (s ′ )(i ′ )) | 1 = r out (η ′-1 (α(s ′ )(r -1 in (i ′ ))) | 1 and η ′-1 (α ′ (s ′ )(i ′ )) | 2 = η ′-1 (α(s ′ )(r -1 in (i ′ )) | 2
-if op 1 ⊗ op 2 is a complex operator of arity n = n 1 + n 2 , then for every sequence

(C 1 , C 2 , . . . , C n 1 , C n 1 +1 , . . . , C n ) z of components in C with each C i over H i = T(O i × ) I i , if
) × • • • × Comp(H n ) -→ Comp(H).

Examples

In the following, we present some concrete examples illustrating our framework. -An encoder that takes in an incoming bit sequence and produces an encoded value which is then transmitted on the link. This encoder is considered as a component E = ({s 0 , s 1 }, s 0 , α 1 ) where the transition function α 1 : {s 0 , s 1 } -→ ({0, 1} × {s 0 , s 1 }) {0,1} is graphically shown in the left of Figure V.17.

-A decoder that takes the values from the link and produces the original value. This decoder is considered as a component D = ({q 0 , q 1 }, q 0 , α 2 ) where the transition function α 2 : {q 0 , q 1 } -→ ({0, 1} × {q 0 , q 1 }) {0,1} is graphically shown in the right of Figure V. 17. Let us now construct the encoder/decoder as a composition of the encoder and the decoder by means of the sequential composition over a synchronous feedback. First of all, let us apply the sequential composition ⊲ s (⊗(E , D)) over the synchronous feedback interface I defined for every (i

, i ′ ) ∈ In 1 × In 2 and (o, o ′ ) ∈ Out 1 × Out 2 by: f ((i, i ′ ), (o, o ′ )) = (i, o), π i ((i, i ′ )) = i and π o ((o, o ′ )) = o ′
We first define the cartesian product C = ⊗((E , D)) of E and D. It is easy to see that C is a well-formed feedback composition over I. Let us check this for (s 0 , q 0 ), we then have: [START_REF] Hower | Software quality assurance and testing resource center[END_REF] -Encoder (on the left) and Decoder (on the right)

s 0 s 1 0|0 0|1 1|1 1|0 {0, 1} ω {0, 1} ω q 0 q 1 0|0 1|0 1|1 0|1 {0, 1} ω {0, 1} ω Figure V.
-(0, 0) ∈ η ′ (α C ((s 0 , q 0 ))( f ((0, 0), (0, 0)))) | 1 -(1, 1) ∈ η ′ (α C ((s 0 , q 0 ))( f ((1, 1), (1, 1)))) | 1 -(0, 0) ∈ η ′ (α C ((s 0 , q 0 ))( f ((0, 1), (0, 0)))) | 1 -(1, 1) ∈ η ′ (α C ((s 0 , q 0 ))( f ((1, 0), (1, 1)))) | 1
Then, we can apply the synchronous feedback operator I on C. This leads to a minimal component {F } where F : {0, 1} ω -→ {0, 1} ω is the transfer function defined for every x ∈ {0, 1} ω and every k, 0 ≤ k < ω, by:

F (x)(k) = x(k)
Let us explain how F was obtained using a running example. For this, let us consider the bit sequence (01) ω , and try to find a bit sequence y ∈ {0, 1} ω satisfying:

∃(s 0 , . . . , s k , . . . ) ∈ S | ∀n, 0 ≤ n < ω, y(n) ∈ η ′ Out×S (α(s n )( f (x(n), y(n)))) | 1
Let us suppose that the current state and the current input are the initial state s(n) = (s 0 , q 0 ) and x(n) = (0, 0) respectively. There is a y(n) = (0, 0) such that:

(0, 0) ∈ η ′ (α C ((s 0 , q 0 ))( f ((0, 0), (0, 0))))
That is to say, the component C reacts by updating its state to (s 0 , q 0 ) and producing the output (0, 0). More precisely, the output of E becomes the input of D. So, we can conclude that the input of the encoder/decoder is π 1 (0, 0) = 0 and its output is π o (0, 0) = 0. Suppose next that the current input is (1, 1). Again, there is a y

(n) = (1, 1) such that (1, 1) ∈ η ′ (α C ((s 0 , q 0 ))( f ((1, 1), (1, 1))))
That is to say, the component C reacts by updating its state to (s 1 , q 1 ) and producing the output (1, 1). So, we can conclude that the input of the encoder/decoder is π 1 (1, 1) = 1 and its output is

π o (1, 1) = 1.
Hence, the composite machine alternates states on each reaction and produces the output bit sequence (01) ω for the input bit sequence (01) ω .

Finally, the minimal component {F } that represents F is given by: s 0|0 1|1 Example 3.2 The purpose of this example is to shed light on how new components can be built hierarchically from elementary basic components involving various integration operators. The example is a simple model of a system that checks whether two gates are well-closed (respectively well-opened) when they receive an order to close (respectively to open). It consists of three parts: a controller C, two gates G 1 and G 2 and a special component O testing behaviour of G 1 and G 2 . When the controller receives an order to close the gates (i.e. when "close" button is pressed), it sends to G 1 and G 2 a signal "close" which is simultaneously placed to G 1 and G 2 . Hence, each one produces either a "closed" signal or fails to do so. We assume reactions of G 1 and G 2 are instantaneous, i.e. they take no time to be closed or opened. Then, O does nothing if both G 1 and G 2 are well-closed or opened, and raises an alarm otherwise. It can be thought of as a checker of closing 12 and opening gates.

The global model S of this system is then built from three basic components: Controller C: it produces a signal "close" when the close button is pressed and a signal "open" when the open button is pressed (see Figure V.18). Both "close" and "open" signals are supposed to be submitted simultaneously to G 1 and G 2 . In our framework, C is specified as the coalgebra C = ({closed, opened}, closed, α C ) over the signature ({close, open} × ) {buttonO,buttonC} where α C : {closed, opened} × {buttonO, buttonC} -→ ({close, open} × {closed, opened}) is defined as follows: Now, using our renaming operation, G 1 and G 2 can be seen as instances of the gate component G. Then, G 1 = G] r 1in ,r 1out and G 2 = G] r 2in ,r 2out where both r 1in and r 2in are identities on {close, open} and r 1out and r 2out are defined as follows:

α C (closed)(buttonC) = (close, opened) α C (opened)(buttonO) = (open, closed)
r 1out : {opened, closed} → {opened 1 , closed 1 } opened → opened 1 closed → closed 1 r 2out : {opened, closed} → {opened 2 , closed 2 } opened → opened 2 closed → closed 2
Checker system O: it receives the outputs of G 1 and G 2 and raises an alarm if there is a gate that is not completely closed.

In our framework, O is specified as the following transfer function: where α K is defined as follows: Hence, the global system S can be given as a sequential composition of the controller C and K. Thus, S is the component S = ⊲ s (C, K) = ({s 0 , s 1 , s 2 }, s 0 , α S ) over the signature P fin ({abs, alarm} × ) {buttonC,buttonO} where α S is defined as follows:

F O : {closed 1 , abs} × {closed 2 , abs} -→ {alarm, abs} (o, o ′ ) → abs i f (o, o ′ ) = (
   α K (k 0 )(close) = {(abs, k 1 ), (alarm, k 2 )} α K (k 1 )(open) = {(abs, k 0 )} close open (closed 1 , closed 2 ) (opened 1 , opened 2 ) (closed 1 , abs) (abs, closed 2 ) (abs, abs) b 0 b 1 b 2 b 3 b 4 close|(closed 1 , closed 2 ) open|(opened 1 ,
   α S (s 0 )(buttonC) = {(abs, s 1 ), (alarm, s 2 )} α S (s 1 )(buttonO) = {(abs, s 0 )} Figure V.
⊲ s (C, ⊲ s (⊛(G 1 , G 2 ), O))
The two basic components G 1 and G 2 are composed together using the synchronous product and the resulting component B = ⊛(G 1 , G 2 ) is composed sequentially with O. Finally, the basic component C is composed sequentially with the result of the second composition K = ⊲ s (C, B).

Example 3.3 (Pedestrian crossing again)

We have presented in Example 1.3 the "traffic light system" M that constitutes the first part of the "pedestrian crossing system". In this example, we first consider the other part of the pedestrian crossing that is the "crosswalk system" and then show the pedestrian crossing global system obtained as a synchronous parallel composition of these two parts. The crosswalk system consists of two colored lights (see Figure IV.3): green and red. Illumination of the green light means that the road is vehicle-free and so pedestrians can cross safely. Illumination of the red light means there is a flow of vehicles at the road and so the pedestrians cannot cross. Such a typical crosswalk system M ′ can be modeled by the transition diagram shown in Figure V. [START_REF] Beizer | Software testing techniques[END_REF]. The behaviour of M ′ is the following: from its initial state s ′ 0 , when the pedestrian pushes the request button to request the green light, M ′ receives the request and goes to the s ′ 1 state. Then, it emits a signal to the traffic light system M to stop the flow of vehicles while going to the s ′ 2 state. When it receives the confirmation signal from the traffic light system, it illuminates the green light and sets in the pending state s ′ 4 . Once the road is free of pedestrians, it illuminates the red light and sends a signal to the traffic light system to allow the vehicles to pass.

s ′ 0 s ′ 1 s ′ 2 s ′
We model the crosswalk system as a component

M ′ = (S ′ , s ′ 0 , α M ′ ) over the signature (Out ′ × ) In ′ with S ′ = {s ′ 0 , s ′ 1 , s ′ 2 }
is the state space, In ′ = {request, pedestrianOk, abs} is the set of inputs and Out ′ = {stopLight, lightOk, pedestrianGreen, pedestrianRed, abs} is the set of outputs. The transi- tion function: α M ′ : S ′ -→ ({stopLight, lightOk, pedestrianGreen, pedestrianRed, abs} × S ′ ) {request,pedestrianOk,abs} is defined as follows:

             α M ′ (s ′ 0 )(request) = (stopLight, s ′ 0 ) α M ′ (s ′ 0 )(pedestrianOk) = (pedestrianGreen, s ′ 1 ) α M ′ (s ′ 1 )(abs) = (pedestrianRed, s ′ 2 ) α M ′ (s ′ 2 )(abs) = (lightOk, s ′ 0 )
The pedestrian crossing model S can be seen as a composition of the crosswalk component M ′ and the traffic light component M, in which the "stopLight" action, the "pedestrianOk" action and the "lightOk" action are hidden as one can see in Figure V. [START_REF] Dijkstra | Notes on structured programming[END_REF]. The behaviour of S is then obtained as the synchronous parallel composition ⊙((M ′ , M)) of the individual components M ′ and M. Output actions of one component that are in the input set actions of another component are synchronized i.e. the "stopLight", "pedestrianOk" and "lightOk" actions.

s ′ 0 s ′ 1 s ′ 2 s ′

(Level crossing)

We consider a simplified model of a level crossing. This model mainly consists of three parts: a single track railroad, a train, three detectors: "approach", "entry" and "exit" to detect the position of the train during its crossing of the road and the barrier.

Figure V.26 -Level crossing

The behaviour of the global system of the level crossing is the following: when the "approach" detector detects an approaching train, it sends a signal to the barrier in order to go down. Once the train enters into the security zone, the "entry" detector detects the presence of the train and then sends a signal to the controller. Finally, once the train is crossed the railroad, the "exit" detector detects the train and sends a signal to the barrier in order to go back up. The model considered here does not take into consideration the errors produced during both the barrier raising and lowering in order to avoid any complications. It focuses only on safety properties such as "there is a train in the security zone while the barrier is not completely closed".

The system of the level crossing as it is explained above, is then built from two basic components:

A controller C that produces a signal "close" when a train approaches, a signal "entry" when a train enters into the security zone and a signal "open" when a train exits the railroad. Both "close" and "open" signals are supposed to be submitted to the barrier. The controller is supposed to raise an alarm if there is a train in the security zone and the barrier is not completely closed. In our framework, C is specified as the coalgebra C = ({in, out, preparing, alarm, safe}, out, α C ) over the signature

({close, open, alarm, abs} × ) {approach,exit,entry,closed} where α C : {in, out, preparing, alarm, safe} × {approach, exit, entry, closed} -→

({close, open, alarm, abs} × {in, out, preparing, alarm, safe}) is defined as follows: A barrier system B that behaves as follows: when it receives the "close" signal from C, it begins to lower and when it receives the "open" signal from C, it begins to rise. We assume that the opening of the barrier is done instantaneously to make the example representation simple. ({alarm, abs} × ) {approach,entry,exit,abs} where α S : {s 0 , s 1 , s 2 , s 3 , s 4 } × {approach, entry, exit, abs} -→ ({alarm, abs} × {s 0 , s 1 , s 2 , s 3 , s 4 })

                   α C (out)(approach) = (close,
is defined as follows:

                 α S (s 0 )(approach) = (abs, s 1 ) α S (s 1 )(entry) = (alarm, s 3 ) α S (s 1 )(abs) = {abs, s 2 ) α S (s 2 )(entry) = (abs, s 4 ) α S (s 4 )(exit) = (abs, s 0 ) s 0 s 1 s 2 s 3

Compositionality

An important question we must address concerns compositionality: is the behaviour of a system the composition of its components' behaviours? In our framework, this will be expressed as follows: let op be a complex operator of arity n, C 1 , . . . , C n be n components and

C = op(C 1 , . . . , C n ), then beh C (init) = op(beh C 1 (init 1 ), . . . , beh C n (init n )) (V.9)
where init (resp. init i , i = 1, . . . , n) is the initial state of C (resp. C i ) and op is the adaptation of op on sets of transfer functions. Before establishing Equation V.9, we first need to define complex operators op on behaviours. Components' behaviours being sets of transfer functions, op has to be defined on a set of transfer functions. Moreover, it has to respect the same induction structure as op. We first have to adapt the cartesian product and the feedback on components' behaviours.

Definition 3.2 (Cartesian product on behaviours

⊗ f ) Let H 1 = T(Out 1 × ) In 1 and H 2 = T(Out 2 × )
In 2 be two signatures. Let Γ 1 and Γ 2 be two sets of transfer functions over H 1 and H 2 respectively. Then, Γ 1 ⊗ f Γ 2 is the set:

Γ 1 ⊗ f Γ 2 = {F 1 × F 2 | F 1 : In 1 ω -→ Out 1 ω , F 2 : In 2 ω -→ Out 2 ω }
It is obvious to prove that the cartesian product of two transfer functions is a transfer function.

Definition 3.3 (Relaxed feedback on transfer function)

Let H = T(Out × ) In be a signature and I = ( f , π i , π o ) be a feedback interface over H. Let F : In ω -→ Out ω be a transfer function. Let us define for every x ∈ In ω , the couple ( x, y x ) ∈ In ω × Out ω by induction on ω as follows:

-x = x(0) and y x (0) = F (x)(0)

-∀n, 0 < n < ω, x(n) = f (x(n), y x (n -1)), y x (n) = F (x)(n) where x ∈ In ω is any dataflow such that ∀j ≤ n, x(j) = x(j).
Then, ←֓ I f (F ) : In ′ω -→ Out ′ω is the mapping that associates to x ′ ∈ In ′ω , y ′ ∈ Out ′ω such that there exists x ∈ In ω satisfying:

∀i < ω, x ′ (i) = π i ( x(i)) and y ′ (i) = π o (y x (i))
Let us observe that Definition 3.3 is noticeably similar to Definition 1.3 except that the choice of y x (n) is unique in Definition 3.3 because directly giving by the transfer function F . ←֓ I f (F ) needs some conditions on projections π i and π o to be a transfer function. Indeed, π i and π o are surjective but by no means they are supposed to be injective. This can then question the causality conditions of ←֓ I f (F ). Imposing π i and π o to be injective would lead to condition which is too strong (π i and π o would then be bijective) and which is seldom satisfied (e.g. the sequential composition defined in Section 2.1). Here, we propose a weaker condition that is satisfied by most of the integration operators based on feedback (all those defined in this thesis).

Assumption 1: ∀x 1 , x 2 ∈ In ω , ∀j, j ≤ n, π i (x 1 (j)) = π i (x 2 (j)) =⇒    π o (F (x 1 )(0)) = π o (F (x 2 )(0)) if j = 0 π o (F ( f (x 1 (j), F ( x1 )(j -1))) = π o (F ( f (x 2 (j), F ( x2 )(j - 1
≤ n ≤ ω, x ′ 1 (n) = x ′ 2 (n), then ←֓ I f (F )(x ′ 1 (n)) =←֓ I f (F )(x ′ 2 (n)).

By induction over ω:

-

Basic Step: n = 0 By definition, x ′ 1 , x ′ 2 ∈ In ′ω , then there exists x 1 , x 2 ∈ In ω such that x ′ 1 (0) = π i (x 1 (0)) and x ′ 2 (0) = π i (x 2 (0)), and ←֓ I f (F )(x ′ 1 (0)) = π o (F (x 1 (0))). By hypothesis, since x ′ 1 (0) = π i (x 1 (0)) and x ′ 2 (0) = π i (x 2 (0)), then π i (x 1 (0)) = π i (x 2 (0)). Then, by Assumption 1, we have that π o (F (x 1 )(0)) = π o (F (x 2 )(0)). Hence, ←֓ I f (F )(x ′ 1 (0)) = π o (F (x 2 (0))) which by definition equals to ←֓ I f (F )(x ′ 2 (0)). -Induction Step: By definition of ←֓ I f (F )(x ′ 1 (n + 1)), we know there exists ( x1 , F ( x1 )) ∈ In ω × Out ω such that ∀k, 1 ≤ k ≤ n + 1, x ′ 1 (k) = π i ( x1 (k)) and ←֓ I f (F )(x ′ 1 (k)) = π o (F ( x1 )(k)) where x1 (k) = f (x(k), F ( x1 )(k -1)).

By definition of ←֓ I

f (F )(x ′ 2 (n + 1)), we know there exists ( x2 , F ( x2 )) ∈ In ω × Out ω such that ∀k, 1 ≤ k ≤ n + 1, x ′ 2 (k) = π i ( x2 (k)) and ←֓ I f (F )(x ′ 2 (k)) = π o (F ( x2 )(k)) where x2 (k) = f (x(k), F ( x2 )(k -1)).
By hypothesis, we know that ∀k,

0 ≤ k ≤ n, x ′ 1 (k) = x ′ 2 (k) =⇒←֓ I f (F )(x ′ 1 (k)) =←֓ I f (F )(x ′ 2 (k)). It remains to prove that if x ′ 1 (n + 1) = x ′ 2 (n + 1), then ←֓ I f (F )(x ′ 1 (n + 1)) =←֓ I f (F )(x ′ 2 (n + 1)). Since ∀k, 1 ≤ k ≤ n + 1, x ′ 1 (k) = π i ( x1 (k)), x ′ 2 (k) = π i ( x2 (k)) and x ′ 1 (k) = x ′ 2 (k), then by Assumption 1, ∀k, 1 ≤ k ≤ n + 1. π o (F ( x1 )(n + 1)) = π o (F ( x2 )(n + 1)). This last result then yield ←֓ I f (F )(x ′ 1 (n + 1)) =←֓ I f (F )(x ′ 2 (n + 1)).

End

∀x ∈ In ω , (∀n < ω, x(n) = f (x(n), F (x)(n))) =⇒ F ( x) = F (x)
Definition 3.5 (Synchronous feedback for transfer functions) Let I = ( f , π i , π o ) be a feedback interface over a signature H. Let F : In ω -→ Out ω be a transfer function. I f (F ) : In ′ω -→ Out ′ω is the mapping that associates to x ′ ∈ In ′ω , y ′ ∈ Out ′ω such that there exists x ∈ In ω satisfying

∀i < ω, x ′ (i) = π i ( f (x(i), F (x)(i))) and y ′ (i) = π o (F ( f (x(i), F (x)(i))))
Similarly to ←֓ I f (F ), I f (F ) is a transfer function if the following assumption is satisfied by F .

Assumption 2: ∀x 1 , x 2 ∈ In ω , ∀j, j ≤ n,

π i (x 1 (j)) = π i (x 2 (j)) =⇒ π o (F ( f (x 1 (j), F (x 1 )(j))) = π o (F ( f (x 2 (j), F (x 2 )(j))) Proposition 3.2 I f is a transfer function.
Proof The technical proof is noticeably similar to the proof given for ←֓ I f . End

Let us note that both Assumption 1 and Assumption 2 are satisfied by all operators defined in this thesis that use the feedback operator. Indeed, if we take the sequential operator, we can see that these assumptions are verified according to the underlying feedback. This is also true for all other complex operators defined by the sequential operator. Definition 3.6 (Feedback on behviours) Let Γ be a set of transfer functions over a signature H = T(Out × ) In . Then, ⊙Γ is the set of transfer functions:

⊙Γ = {⊙F | F : In ω -→ Out ω } where ⊙ is either ←֓ I f or I f .
Complex operators can be easily extended to behaviours by replacing in Definition 2.1, the symbols ⊗, ←֓ I and I by ⊗ f , ←֓ I f and I f , respectively. In the following, given a complex operator on components we will note op its equivalent on behaviours.

Similarly, Definition 3.1 can be easily extended to complex operators on behaviours by replacing each component C i by a set of transfer functions Γ i , and ⊗, ←֓ I and I by ⊗ f , ←֓ I f and I f , respectively. Theorm 3.1 (Compositionality) Let op be a complex operator on components of arity n. Let C 1 , . . . , C n be n components.

If C = op(C 1 , . . . , C n ), then beh C (init) = op(beh C 1 (init 1 ), . . . , beh C n (init n ))
Proof In order to prove this theorem, we need to prove the following lemmas:

Lemma 3.1 Let C 1 and C 2 be two components over H 1 = T(Out 1 × ) In 1 and H 2 = T(Out 2 × ) In 2 . Let C = ⊗(C 1 , C 2 ) be the product component over H = T((Out 1 × Out 2 ) × ) In 1 ×In 2 . Then we have: beh C 1 ⊗C 2 ((init 1 , init 2 )) = beh C 1 (init 1 ) ⊗ f beh C 2 (init 2 ) Proof By definition, beh C 1 ⊗C 2 ((init 1 , init 2 )) contains all the transfer functions F : (In 1 × In 2 ) ω -→ (Out 1 × Out 2 ) ω that associates to every (x 1 , x 2 ) ∈ In 1 × In 2 , a (y 1 , y 2 ) ∈ Out 1 × Out 2 such that there exists an infinite sequence ((o 11 , o 21 ), (s 11 , s 21 )), • • • ∈ (Out 1 × Out 2 ) × (S 1 × S 2 ) satisfying: ∀j ≥ 1, ((o 1j , o 2j ), (s 1j , s 2j )) ∈ η ′ (Out 1 ×Out 2 )×(S 1 ×S 2 ) (α((s 1j-1 , s 2j-1 ))(x 1 (j -1), x 2 (j -1)))
with (s 10 , s 20 ) = (init 1 , init 2 ), and for every k < ω,

y i (k) = o i for i = 1, 2.
Hence, for i = 1, 2, there exists an infinite sequence (o i1 , s i1 ),

• • • ∈ Out i × S i satisfying ∀j ≥ 1, (o ij , s ij ) ∈ η ′ Out i ×S i (α i (s ij-1 )(x i (j -1)))
We can then define a transfer function F i :

x i → y i . Hence F = F 1 ⊗ f F 2 and then F ∈ beh C 1 (init 1 ) ⊗ f beh C 2 (init 2 )
By following the same reasoning, we can show that given

F i ∈ beh C i (init i ), F 1 ⊗ f F 2 ∈ beh C 1 ⊗C 2 ((init 1 , init 2 )) End Lemma 3.2 Let C ′ be a component over H = T(Out ′ × ) In ′ and C =←֓ I (C ′ ) be a component over H = T(Out × ) In . Let I = ( f , π i , π o ) where f : In ′ × Out ′ -→ In ′ , π i : In ′ -→ In and π o :
Out ′ -→ Out be a feedback interface. Then we have:

beh ←֓ I (C ′ ) (init) =←֓ I f (beh C ′ (init ′ ))
where init is the initial state of C =←֓ I (C ′ ).

Proof Le F ∈ beh ←֓ I (C ′ ) (init). By definition, F associates to x ′ ∈ In ω , y ′ ∈ Out ω (when such y ′ exists) such that there exists x ∈ In ′ω and ( x,

y x ) ∈ In ′ω × Out ′ω satisfying ∀i < ω, x ′ (i) = π i ( x(i)) and y ′ (i) = π o (y x (i))
By definition of x and y x, there exists an infinite sequence (init ′ , s ′ 1 , . . . , s ′ k , . . . ) ∈ S ′ such that: -x = x(0) and y x (0)

∈ η ′ Out ′ ×S ′ (α ′ (init ′ )( x(0)) -∀n, 0 < n < ω, x(n) = f (x(n), y x (n -1)), y x (n) ∈ η ′ Out ′ ×S ′ (α ′ (s ′ n )( x(n))).
Hence, we can extract a transfer function F ′ that associates to x, y x such that ←֓ I f (F ′ ) = F , and then

←֓ I f (F ′ ) ∈←֓ I f (beh C ′ (init ′ )).
To prove the other inclusion, we can follow the same reasoning. End

Lemma 3.3 Let C ′ be a component over H = T(Out ′ × ) In ′ and C = I (C ′ ) be a component over H = T(Out × ) In . Let I = ( f , π i , π o ) where f : In ′ × Out ′ -→ In ′ , π i :
In ′ -→ In and π o : Out ′ -→ Out be a feedback interface. Then we have:

beh I (C ′ ) (init) = I f (beh C ′ (init ′ ))
where init is the initial state of C = I (C ′ ).

Proof The technical proof is noticeably similar to the proof given for ←֓ I . End

Now, Theorem 3.1 is proven by induction on the structure of op as follows:

-Basic Step: op is of the form . Its equivalent for sets of transfer functions is also defined by (Γ) = Γ. The conclusion is then obvious.

-Induction Step: Three cases have to be considered -op = ⊗(op 1 , op 2 ) with arity of op 1 is n 1 , arity of op 2 is n 2 and n 1 + n 2 = n By induction hypothesis, we have:

(1) beh op 1 (C 1 ,...,C n 1 ) (init) = op 1 (beh C 1 (init 1 ), . . . , beh C n 1 (init n 1 )) where init is the initial state of op 1 (C 1 , . . . , C n 1 ). (2) beh op 2 (C n 1 +1 ,...,C n ) (init ′ ) = op 2 (beh C n 1 +1 (init n 1 +1 ), . . . , beh C n (init n )) where init ′ is the initial state of op 2 (C n 1 +1 , . . . , C n ).
and by the definition of both op 1 and op 2 , we have

(3) op 2 (C n 1 +1 , . . . , C n ) and op 2 (C ′ n 1 +1 , . . . , C ′ n ) are components.
Then, (

+ (2) + (3) + Lemma 3.1 implies that beh op 1 (C 1 ,...,C n 1 )⊗op 2 (C n 1 +1 ,...,C n ) ((init, init ′ )) = op 1 (beh C 1 (init 1 ), . . . , beh C n 1 +1 (init n 1 )) ⊗ f op 2 (beh C n 1 +1 (init n 1 +1 ), . . . , beh C n (init n )) -op is of the form ←֓ I (op ′ ) and is of arity n. Let C 1 , . . . , C n be n components such that C ′ = op ′ (C 1 , . . . , C n ). By induction hypothesis, beh C ′ (init ′ ) = op ′ (beh C 1 (init 1 ), . . . , beh C n (init n )). It remains to prove that beh ←֓ I (C ′ ) (init) =←֓ I f (beh C ′ (init ′ )) (1)
where init is the initial state of C =←֓ I (C ′ ). This last point is naturally proved by Lemma 3.2.

-op is of the form I (op ′ ) and is of arity n.

Let C 1 , . . . , C n be n components such that

C ′ = op ′ (C 1 , . . . , C n ). By induction hypothesis, beh C ′ (init ′ ) = op ′ (beh C 1 (init 1 ), . . . , beh C n (init n )). It remains to prove that beh I (C ′ ) (init) = I f (beh C ′ (init ′ ))
where init is the initial state of C = I (C ′ ). This last point is naturally proved by Lemma 3. 3.

End

In this section, we present a brief overview of contributions which are technically close to our approach, by discussing the difference between the problematics addressed by those contributions and those addressed by our approach. There are several coalgebraic works in the literature which regard the combination of components using some sort of integration mechanism. The closet to our work is the set of integration operators proposed by Barbosa in [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Meng | Components as coalgebras: the refinement dimension[END_REF]. Four component integration operators have been proposed to reason about component-based designs: pipeline "series" operator, external choice operator, parallel composition and concurrent operator. These operators are defined as special functors in some bicategory of components. The pipeline operator is similar to our synchronous sequential operator ⊲ r . The external choice operator corresponds to a composition where both components C 1 and C 2 are executed independently, depending on the input submitted to the integrated component: when interacting with the composed system, the environment will be allowed to choose either C 1 or C 2 inputs, but not both. Input then triggers the corresponding component (i.e. C 1 or C 2 ), producing the associated output. This operator is then similar to our synchronous product ⊛ when the intersection of input sets In 1 and In 2 is the empty set. The parallel composition is embodied in the cartesian product, and finally the concurrent operator is similar to the operator defined in Section 2. 4. Thus, Barbosa's operators can be all deduced from our two basic operators by choosing the suitable and the minimal combination of them. In this setting, our approach offers advantages relative to [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Meng | Components as coalgebras: the refinement dimension[END_REF], that is it makes larger systems as a composition of only two operators, rather than as a combination of a set of separated operators. This makes it easier to reason about system functionalities in the sense that every correct property under these basic operators is also a correct property under other complex operators. This yields general theorems that are true of all operators defined in our frameworks, and thus it is not required to be re-proved every time for a new operator described as a combination of our basic operators: the proofs of results done on our basic operators are made once and for all.

Meng in [89] redefined Barbosa's operators to combine two components C 1 and C 2 over the signatures (Out 1 × T(Out 2 × ) In ) and (Out ′ 1 × T ′ (Out ′ 2 × ) In ′ ) respectively. Hence, the difference between Meng's and Barbosa's work is the form of the functor over which components are defined, and the possibility of combining components with different computational models (i.e. T and T ′ ), rather than using a single monad.

In this chapter, we have also shown how to define larger systems by composing subsystems from two basic integration operators: product and feedback. This led us to inductively define a set of complex operators (see Definition 2.1), the semantics of which are partial functors on categories of components. This part can then be compared to works in [START_REF] Hasuo | The microcosm principle and concurrency in coalgebras[END_REF][START_REF] Hasuo | Coalgebraic components in a manysorted microcosm[END_REF]. Indeed, from a set of complex operators we can easily generate an algebraic signature that can be seen as an FPtheory L over a basic set of sorts S ⊆ Set × Set where for (In, Out) ∈ S, In and Out denote input and output sets, respectively, and operations are complex operators (a monad T is supposed identical for every couple (In, Out) in the FP-theory L). Outer models can then be defined along the functor C : L -→ Cat that associates to any couple (In, Out) the category Comp(H) with H = T(Out × ) In and to any operator the partial functor defined in Definition 2.1. Finally, inner models are defined by the natural transformation X : 1 =⇒ C where 1 is the constant functor that associates to any S ∈ L the trivial object category 1, which to any couple (In, Out) associates the final object in Comp(H) and to any complex operator op, the mapping on behaviours noted [[op]] in [START_REF] Hasuo | The microcosm principle and concurrency in coalgebras[END_REF][START_REF] Hasuo | Coalgebraic components in a manysorted microcosm[END_REF] that contains op semantics on both components and transfer functions.

The difference between our works and those mentioned above is that we have defined integration operations by composing two basic operators: product and feedback. The objective was then to demonstrate a set of general properties on these integration operators such as the results of compositionality (see Theorem 3.1), by showing that these properties are valid for the product and feedback and are preserved by composition.

Hence, Theorem 3.1 is similar to Theorem 4.7 in [START_REF] Hasuo | Coalgebraic components in a manysorted microcosm[END_REF] at least in these goals to establish a generic result of compositionality independent of a given integration operator.

There is a long list of other works addressing components composition without involving coalgebraic denotations. It is difficult to collect them all; however, the common basis of most of them is that the system is described as a structural decomposition into components (or subsystems) by separating the notion of component behaviour and that of interaction (or communication) between components, which is considered essential to overcome system design complexity [2,3,[START_REF] Burch | Overcoming heterophobia: Modeling concurrency in heterogeneous systems[END_REF]. Approaches based on so-called model of computations, such as [START_REF] Burch | Overcoming heterophobia: Modeling concurrency in heterogeneous systems[END_REF][START_REF] Lee | Taming heterogeneity -the ptolemy approach[END_REF][START_REF] Brooks | Ptolemy ii -heterogeneous concurrent modeling and design in java[END_REF][START_REF] Hardebolle | Modhel'x: A component-oriented approach to multiformalism modeling[END_REF][START_REF] Hardebolle | Multi-formalism modelling and model execution[END_REF][START_REF] Jantsch | Models of embedded computation[END_REF], have been proposed to connect all components of the system globally. Roughly speaking, a model of computation can be seen as a set of primitive rules that govern the interactions between the components of a system. Such rules should explicitly encompass (1) the global behaviour of a system during its execution (e.g. cyclic, reactive, concurrent or sequential way);

(2) the communication protocol used to allow the system to interact with its environment (e.g. rendezvous, message passing, exchange events) and (3) the data format that can be used during communication (e.g. events, queries, flux). These approaches suffer from the disadvantage that the semantics of the model of computations used and the interactions between them are given implicitly, which makes it hard or even impossible to incorporate, beyond modeling and simulation, other techniques such as testing and verification.

Other approaches have been proposed for describing component behaviour and their coordinations, such as [START_REF] Arbab | Reo: a channel-based coordination model for component composition[END_REF][START_REF] Basu | Modeling heterogeneous real-time systems in BIP[END_REF][START_REF] Gößler | Composition for component-based modeling[END_REF]. Reo [START_REF] Arbab | Reo: a channel-based coordination model for component composition[END_REF] is a coordination language for the composition of distributed software components and services based on connectors. Primitive connectors such as synchronous channels or FIFO queues are structured to build complex component connectors which exhibit complex behaviours. A number of formal models describing the behaviour of Reo connectors and their composition exists, for instance models based on constraint automata [START_REF] Arbab | Modeling Component Connectors In Reo By Constraint Automata[END_REF] or models based on coalgebraic denotations [START_REF] Arbab | A coinductive calculus of component connectors[END_REF]. Thus, algebraic reasoning and simulation are supported for analysis. Reo does not focus on component behaviour, it presents components only by their interfaces. In this way, Reo's components can be seen as transfer functions taking input data at given moments and providing its associated output, and Reo's connectors as relations between a couple of an input data stream and a time stream (In ω , TS ω ) and a couple of an output data stream and a time stream (Out ω , TS ω ). Thereby, associating time to component dataflows makes Reo's connectors rich, where by imposing suitable timing constraints on them, many styles of communication can be obtained such as synchronous, asynchronous, bounded, unbounded, lossy, lossless, etc. Thus, Reo's connector can be thought of as the sequential operator defined in Section 2.1, which does not only make components connection synchronously, but also encompasses other connection aspects such as asynchronous, unbounded, etc. Hence, by extending In and Out of the 13 signature T(Out × ) In with a complex data structure, Reo's connectors would be embodied in our framework. [START_REF] Basu | Modeling heterogeneous real-time systems in BIP[END_REF][START_REF] Gößler | Composition for component-based modeling[END_REF] provides a formal composition framework for describing based-component systems with heterogeneous interactions. This framework is known as BIP: B stands for Behaviour, I for Interaction and P for Priority. Thus, as its name indicates, a BIP model (or component) is composed of three layers: a layer defines the behaviour of the component encoded as transition systems extended with variables, a layer defines the connectors (i.e. the interactions) between components executed via communication ports and a layer defines priority rules which reduce non-determinism between interactions. BIP's models can be composed to yield larger models. This is done using a binary composition operator on components which is supposed to com- 13. Extension of the signature T(Out × ) In over which components are defined with data structure is a part of our future work. pose layers separately. This means that when composing two components C 1 and C 2 , their corresponding layers are composed indifferently and separately: C 1 's behaviour is composed with C 2 's, C 1 's interactions are composed with C 2 's, and C 1 's priority rules are composed with C 2 's. Furthermore, BIP is able to ensure correctness-by-construction for essential system properties such as mutual exclusion, deadlock freedom and progress. It also enables formal verification. Such a representation of components and connectors allows BIP to provide multitude heterogeneous interactions such as rendezvous and broadcast communication mechanisms. We believe that these styles of communications would be described in our framework, by extending the component signature T(Out × ) In with complex data structure (for instance, rendez-vous style can be embodied in sequential communication, broadcast in sequential following by synchronous product).

Conclusion

In this chapter, we have proposed a generic framework for modeling complex modern systems viewed as state-based systems. We have shown how a basic component (see Chapter IV, Definition 1.1) can be combined with another by means of some integration operators to yield a bigger, more complicated component. We have then defined two generic integration operators for combining the behaviour of components: an extended version of the well-known cartesian product, and the feedback operator. The feedback operator relies on three mappings: a mapping f to specify how components are linked and which parts of their interfaces are involved in the composition process, and two mappings π i and π o that allow us to hide inputs and outputs involved in the feedback composition process and thus help both encapsulation and compositionality. We have shown that other integration operators such as the sequential operator, the double sequential operator, the synchronous product, the concurrent operator and the synchronous parallel composition operator can be considered as compositions of these two basic operators by a suitable choice of f , π i and π o . In this setting, we can see both the cartesian product and the feedback operator as two patterns from which other integration operators can be deduced as sequences of composition patterns. These patterns can also be used to build larger patterns. Our two basic operators are then minimal operators used to derive operators representing an interaction between components by choosing a suitable and a minimal combination. Such a combination is given according to the semantic that we want to associate to the integration operator of interest i.e. how the components communicate and share their actions. Hence, the objective is to demonstrate a set of general properties on these integration operators such as the results of compositionality, by showing that these properties are valid for the product and the feedback and are preserved by composition. Thereby, every correct property under the basic operators is also a correct property under complex operators.

Part III

Validation of component-based systems by testing

This part provides the second main contribution of this thesis. It presents a formal compositional theory for testing complex-software systems viewed as component-based systems. Our approach in the first part was to define a generic formalism dedicated to modeling systems, generally state-based formalisms. The work proposed here can then be seen as a proposal for a generic theory of conformance testing. It intends to contribute to the following topics:

-The development of a conformance testing approach enabling us to ensure correctness of the components defined in Chapter IV. This approach is mainly inspired from the theory of conformance testing developed by A. Touil and al. in [44,[START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF].

-The definition of a compositional testing framework enabling us to ensure the correctness of systems obtained as an assembling of a set of components, as was shown in Chapter V.

The underlying idea consists in establishing correctness of the global system by using correctness of each component.

-The definition of a framework enabling us to strengthen the correctness of each component involved in a global system, by choosing suitable test purposes for them. The underlying idea is to use a projection mechanism, as in [START_REF] Faivre | Symbolic model based testing for component oriented systems[END_REF], to identify from any trace tr of the global system, the trace of any component involved in tr. These projected traces can be then seen as test cases that should be tested on individual components.

This part consists of three chapters. The first one presents an overview of the conformance testing theory. The second one introduces our conformance testing theory allowing us to test components separately. The third one is devoted to defining our compositional testing approach based on projection mechanisms.

Chapter VI

Conformance testing theory: a general overview The meaning of conformance . .

Formal framework for conformance testing . .

Conformance testing [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF][START_REF] Beizer | Black-box testing: techniques for functional testing of software and systems[END_REF] is a technique for checking the functional correctness of an implementation with respect to its specification by means of experiments on the implementation. It consists in deriving test cases algorithmically from a system specification, executing them on the real system and finally making sure that the latter behaves correctly by comparing its outputs with those required in the specification.

A common methodology and framework for the specification and execution of conformance testing for implementations of standard communication protocols such as ISO protocols, ISDN protocols, etc. was proposed by the International Organization for Standardization (ISO). This methodology is known as the international standard IS-9646: "Conformance Testing Methodology and Framework" [START_REF]Information technology, Open Systems Interconnection. International standard IS 9646[END_REF][START_REF]Information Retrieval, Transfer and Management for OSI, Formal Methods in Conformance Testing[END_REF]. The goal of the standard IS-9646 originally was to unify the process of developing methods for conformance testing between protocols or open systems interconnection (OSI) and their specifications. But, it has rapidly turned out that this standard can also be suitable to test reactive systems [START_REF] Clarke | Automated test and oracle generation for smart-card applications[END_REF][START_REF] Kahlouche | Hardware testing using a communication protocol conformance testing tool[END_REF]. It is consequently now considered as the basis of conformance testing where it allows us to define how to specify conformance tests and to provide guidance to developers of test systems.

Nevertheless, the standard IS-9646 is limited in practice to automatized testing due to the absence of a formal description of its elements. Concepts are indeed written in natural language which makes the automation of the conformance testing process hard. Hence, this limitation activated the research and development of a formal framework, in which conformance testing concepts, such as conformance requirement, conformance meaning, correctness of an implementation, test cases, test execution, verdict, etc. were defined in a formal setting. This led to a joint project between ISO and the International Telecommunication Union (ITU) called "Formal Methods in Conformance Testing" (FMCT) [52]. This project was the main topic of Tretmans's thesis [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF] whose goal was the formalization of the testing methodology IS-9646, giving a formal interpretation to most concepts in this standard.

In this chapter, we outline the main concepts of conformance testing which are introduced in the standard IS-9646, and formalized by Tretmans in [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF]. These concepts will be the theoretical background of formal testing, which serves us as a fundamental basis to define our method for automatic generation of abstract1 tests for generic components. The first phase is called test generation (or test derivation) and consists in deriving test cases algorithmically from a formal description of the system's behaviour using an algorithm of test case generation. A collection of generated test cases is called a test suite. Test cases are indeed not directly executable on the implementation because they are developed at some abstract level independently of any implementation of the system. Thus, they are called abstract tests. The second phase is known as test implementation and consists in transforming the generated test cases during the first phase into concrete tests which therefore can be run on the real system. In fact, a mechanism that maps abstract tests to concrete ones is needed. This mechanism is usually referred to as an adapter. The last phase is called test execution and consists in executing concrete tests on a particular implementation. The underlying idea is to provide test cases to the implementation and then observe its outputs which should be compared with the expected outputs indicated in the test case. If the outputs do not match the specified outputs, a verdict Fail is assigned to the test indicating non-conformance between the implementation and the specification. Otherwise, a verdict Pass is assigned to the test indicating the conformance between the implementation and the specification (only for the submitted test case).

Formal Method in Conformance Testing

Note that in this thesis, we will not talk about the phase of test implementation. In fact, as the test cases generated from the first phase are abstract, they must be then made concrete before executing them on the implementation. As well, when a test is executed, outputs from the implementation, being concrete, tests have to be transformed into abstract tests before comparing them with the expected outputs that are specified in the abstract test cases. We will not focus on this phase, and as you will see in the next section, we consider implementations as black boxes in order to deal with them by a formal reasoning.

The meaning of conformance 1.2.1 Specification model

A formal specification describes system behaviour using a specialized description formalism. In general, it is a formal representation that captures the properties of a system precisely and unambiguously.

In the following part of this section, to be independent of any specification formalism, we will note SPECS the set of all possible formal specifications independently of any formalism, and spec a specification belonging to SPECS.

Implementation model

An implementation under test generally consists of a combination of hardware and software. It usually has physical connectors or interfaces to communicate with its environment. As previously, we will note the set of all possible implementations by IMPS and an implementation (for instance Java program or hardware components) belonging to IMPS by iut. An implementation is then a concrete executable object we cannot deal with it by a formal reasoning. The only way to observe its behaviour is to interact via its interfaces, submitting inputs and observing outputs. Hence, a formal description for such an implementation is needed to build a conformance testing theory whose aim is to check whether the behaviour of a real implementation is correct with respect to a formal specification. Hence, every implementation iut ∈ IMPS has to be modeled by a formal object m iut called a model of iut. The universe of the models of all implementations under test is denoted by MODS. Consequently, we have the following testing hypothesis [START_REF] Bernot | Testing against formal specifications: A theoretical view[END_REF]:

∀iut ∈ IMPS, ∃m iut ∈ MODS, ∀i ∈ In, Out(iut, i) = Out(m iut , i)
where Out(iut, i) (respectively Out(m iut , i)) is the output yielded by iut (respectively m iut ) for the input i.

Note that it is not assumed that the model of an implementation is known, only its existence is required.

Conformance relation

The theory of conformance testing defines the conformance of an implementation to a specification thanks to conformance relations. The objective of these relations is to provide a way to specify conformance of an implementation with its specification. Several kinds of relations have been proposed according to both test purposes and application domains. For instance, models described by specialized description languages such as LOTOS [START_REF] Iso/Iec | LOTOS-a formal description technique based on the temporal ordering of observational behaviour[END_REF] or SDL [107], or those directly described as operational formalisms such as finite state machine or labeled transition systems have different implementation relations embodying the conformance.

The conformance is formally expressed as a relation between the class of implementations IMPS and the class of specifications SPECS. This relation, the so-called implementation relation, is denoted by imp ⊆ MODS × SPECS and expressed as follows:

An implementation iut ∈ IMPS is in conformance to a specification spec ∈ SPECS if the existing model m iut ∈ MODS of iut is imp-related to spec, i.e. iut conforms to spec iff m iut imp spec.

A specification can have many implementations conforming to it and then many conforming implementation models. The different relations between IMPS, MODS and SPECS are depicted in Figure VI.2. For a specification spec ∈ SPECS and an implementation relation imp, one has the set I iut ⊆ IMPS of all implementations that can be modeled by models in M iut ⊆ MODS. Therefore, I iut represents the set of all implementations that implement the specification spec correctly according to imp, and M iut represents the set of all models that conform to spec in MODS. Thus, M iut is given by {m ∈ MODS | m imp spec}. Hence, an implementation iut ∈ IMPS conforms to the specification spec ∈ SPECS if it is modeled by m iut belonging to the set M iut , and the model m iut implements spec according to the implementation relation imp.

Formal framework for conformance testing 1.3.1 Test execution

The behaviour of an implementation under test iut ∈ IMPS is checked by means of test experiments on it: we choose an appropriate input and submit it to the iut. Then, we observe the reaction of the iut and compare it with the one expected in its specification spec ∈ SPECS. This comparison gives rise to a verdict about the correctness of the concrete implementation iut with respect to the specification spec. A specification of each such experiment is called a test case. The set of all possible test cases is denoted by TESTS and a test case belonging to TESTS by tc.

When specifications are written in formal languages, test cases can then be generated automatically using algorithms for test case derivation from the specification. Given an implementation relation imp and an implementation under test iut ∈ IMPS, an algorithm of test case generation then provides a set of test cases TC ⊆ TESTS for a specification spec ∈ SPECS of iut.

This process of derivation of tests is known as test case generation. An execution of a test case is then the process of stimulating an implementation under test iut ∈ IMPS by: -executing the specified test events of a test case tc ∈ TESTS; -observing the produced reactions from the given iut; -generating a test verdict based on these reactions.

We define exec(tc, iut) as the concrete execution of a test case on a real implementation leading to a subset of observations. Now, to continue our formal reasoning, we need to formalize exec(tc, iut), then we introduce the observation function:

obs : TESTS × MODS -→ P (OBS)
where OBS denotes the domain of all possible observations from the iut.

This function computes, for each test case tc ∈ TESTS and each concrete implementation under test iut ∈ IMPS modeled by m iut ∈ MODS, the observations in OBS that result from exe- cuting tc on iut i.e. a subset of observations O ⊆ OBS. Hence, obs(tc, m iut ) models the execution of test cases exec(tc, iut) formally.

Each observation obtained after a test execution is assigned to a verdict which may vary depending on the test case tc. This gives rise to a function:

verdict tc : OBS -→ {Fail, Pass}
A Fail verdict means that a non-conformance between the implementation iut and its specification spec is detected (the behaviour of the implementation observed by the tester is not the one expected in the specification). A Pass verdict means that the implementation iut behaves in conformance to the specification spec for the given observation i.e. for the executed test case.2

Test case properties

So far we have only seen how test cases are generated from specification and how they are executed on implementations. But, we have not studied the coherence between both notions of test cases execution and conformance applied to an implementation under test and its formal specification. For this purpose, two properties have to be studied: correctness and completeness.

-Correctness: this property states that if an implementation iut is in conformance to a specification spec then it passes all generated tests.

-Completeness: this property states that if the implementation passes all generated test cases, then it conforms to its specification.

Intuitively the correctness property is achievable for practical testing. It allows us to ensure the conformance of an implementation with respect to its specification, but it may not be able to detect implementations that are not in conformance to a specification. That is because some nonconforming implementations may pass the set of test cases. On the contrary, the completeness property allows us to exactly distinguish between all conformant and non-conformant implementations. However since a test is not exhaustive, this means we cannot reach the set of all tests generated from the specification, this property is only achievable in theory.

In order to formalize the property of correctness and completeness, we introduce the following two notations:

passes: means that an implementation iut modeled by m iut ∈ MODS passes a test case tc successfully. This is formalized by: iut passes tc = def verdict(obs(tc, m iut )) = Pass f ails: means that an implementation iut modeled by m iut ∈ MODS does not pass a test case tc. This is a situation of failure.

iut f ails tc = def ¬(iut passes tc)

These notions can be extended to a set of test cases TC ⊆ TESTS as follows:

iut passes TC = def ∀tc ∈ In this sense, we are in a testing framework similar to both [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF] and [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Frantzen | Test generation based on symbolic specifications[END_REF].

Conformance relation

In this section, we examine how we can define the conformance of the implementation of a component to its specification. In order to compare the behaviour of the implementation to the specification, we need to consider both as components over a same signature. However, the behaviour of the implementation is unknown and can only be observed through its interface. We therefore need a conformance relation between what we can observe on the implementation and what the specification allows.

To define the conformance between the implementation iut and its specification spec, a formal relation of conformance between iut and spec is classically given between the models of iut and spec. However, the specification spec of a system is the formal description of its behaviour. On the contrary, the implementation iut of a system is an executable component, which is considered as a black box [START_REF] Bernot | Testing against formal specifications: A theoretical view[END_REF][START_REF] Tretmans | A formal approach to conformance testing[END_REF]. Hence, modeling iut requires some assumptions that we state in the following.

Specification model

The conformance testing is a black-box test technique i.e. it is only based on a description of system functionalities in terms of its inputs and outputs. Such a description does not make reference to the internal structure of a system under test. It only contains the desired behaviours that stand only for what the system should do, not how it is done. Then, the first step to define conformance testing theory is to give a specification model of the system in which both its input and output are well represented and the internal behaviour is not considered. Furthermore, this specification model has to make clear the difference between the input and the output of the system due to the fundamental role of this distinction in practical testing process [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF][START_REF] Lynch | An introduction to input/output automata[END_REF][START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF][START_REF] Tretmans | Testing labeled transition systems with inputs and outputs[END_REF][START_REF] Jéron | Contribution à la génération automatique de tests pour les systèmes réactifs[END_REF]. Indeed, the inputs are the actions used by the tester to stimulate the system under test while the outputs are the expected reactions observed after the stimulation. From this point of view, our components defined over the signature T(Out × ) In give answers to these testing requirements where they explicitly differentiate input and output actions.

Implementation model

An implementation iut is commonly a reactive program intending to interact permanently with its environment. During the test process, it is assumed that the source code of the implementation is not available and null knowledge about it is provided. That means it is considered a black box [START_REF] Bernot | Testing against formal specifications: A theoretical view[END_REF][START_REF] Tretmans | A formal approach to conformance testing[END_REF], whose internal structure cannot be directly accessed. We interact with it through its interface, by providing inputs to stimulate it and observing its behaviour through its outputs. Then, to be able to treat the implementation iut, we make the following two assumptions about it:

1. The implementation iut can be modeled as a coalgebra (S ′ , init ′ , α ′ ) over the signature T(Out ′ × ) In ′ with In ⊆ In ′ and Out ⊆ Out ′ (In and Out are the input and output sets of the specification respectively). This assumption is imposed to allow the specification spec to accept all responses of the implementation.

We also denote by iut the coalgebra modeling the implementation to avoid any excessive denotations;

2. The iut is input-enabled, i.e. at any state, it must produce answers for all inputs provided by the environment.

The following definition formalizes these two assumptions: Definition 1.2 (iut model) Let spec be a specification over T(Out × ) In . A system under test or implementation of spec is a component (S ′ , init ′ , α ′ ) over the signature T(Out ′ × ) In ′ where α ′ is considered as a total function:

∀(s ′ , i ′ ) ∈ S ′ × In ′ , ∃(o ′ , s ′′ ) ∈ Out ′ × S ′ such that (o ′ , s ′′ ) ∈ η ′ Out ′ ×S ′ (α(s ′ )(i ′ ))
and In ⊆ In ′ and Out ⊆ Out ′ .

Conformance

An overview

The notion of conformance is usually based on the comparison between the behaviour of a specification and an implementation using a conformance relation. The goal of this relation is to specify what the conformance of an implementation is to its specification. Several kinds of relations have been proposed in the literature. They differ mainly in both the formalism used to model system behaviour and the testing aspects considered. Let us informally review some of them.

The original conformance testing relation proposed for finite state machines (FSM) is defined as the testing equivalence of states whose goal is to determine the equivalence of two machines [START_REF] Lee | Testing finite-state machines: State identification and verification[END_REF]. Two state machines are said to be equivalent if they produce exactly the same sequence of outputs when offered the same sequence of inputs. There is a list of other conformance relations that can be found in the literature. The definitions of these relations depend mainly on the underlying properties of the finite state machines we use. Table VII.1 reviews some of them without going into details. For more detailed explanations, see [START_REF] Petrenko | Conformance tests as checking experiments for partial nondeterministic fsm[END_REF][START_REF] Petrenko | Testing from partial deterministic fsm specifications[END_REF][START_REF] Petrenko | Confirming configurations in efsm testing[END_REF][START_REF] Bourhfir | Automatic test generation for efsm-based systems[END_REF].

Relation

Informal definition Properties

Equivalence ∼ = equality of traces set complete deterministic, or complete nondeterministic It turns out that the conformance relations to test state equivalence are too strong, in practice, for conformance testing. There is a number of common assumptions (e.g. specification is strongly connected, minimized or complete) that are usually made in the literature to make test processes at all possible [START_REF] Lee | Testing finite-state machines: State identification and verification[END_REF][START_REF] Lee | Principles and methods of testing finite state machines-a survey[END_REF][START_REF] Hennie | Fault detecting experiments for sequential circuits[END_REF][START_REF] Yannakakis | Testing finite state machines[END_REF]. Test generation algorithms based on them are also expensive in time and memory [START_REF] Lee | Principles and methods of testing finite state machines-a survey[END_REF][START_REF] Lee | Testing finite-state machines: State identification and verification[END_REF][START_REF] Gönenç | Conformance testing methodologies and architectures for osi protocols. chapter A method for the design of fault detection experiments[END_REF][START_REF] Gill | Introduction to the theory of finite-state machines[END_REF][START_REF] Chow | Testing software design modeled by finite-state machines[END_REF][START_REF] Chung | Improved on UIO sequence generation and partial UIO sequences. Testing, and Verification[END_REF], contrary to test cases generation techniques for inclusion relations (e.g. reduction and quasi reduction relations) [START_REF] Petrenko | Conformance tests as checking experiments for partial nondeterministic fsm[END_REF][START_REF] Petrenko | Testing from partial deterministic fsm specifications[END_REF][START_REF] Petrenko | Confirming configurations in efsm testing[END_REF][START_REF] Bourhfir | Automatic test generation for efsm-based systems[END_REF].

Quasi

The test relations proposed for labeled transition systems (LTS) are usually equivalence and preorder relations relying on the notion of observable behaviours. Many works have been done on establishing the relations between LTSs. The relation trace preorder ≤ tr requires the inclusion of sets of traces. That means an implementation iut may show only behaviour which is specified in the specification. The testing preorder ≤ te [START_REF] De Nicola | Testing equivalences for processes[END_REF][START_REF] De | Extensional equivalence for transition systems[END_REF] means that if the implementation iut makes a trace which corresponds to a computation of iut after which no more action is possible, then the specification spec has to make the same trace. The conf [START_REF] Brinksma | A theory for the derivation of tests[END_REF] is a variant of ≤ te in which all possible observations (i.e. Σ * ) are restricted to only traces contained in the specification.

In other words, it requires that the implementation behaves according to a specification, but allows behaviours on which the specification puts no constraint. The refusal preorder ≤ r f [START_REF] Phillips | Refusal testing[END_REF] is a variant of ≤ tr . The main difference between them is that ≤ r f is able to detect possible deadlock states i.e. states from which the system cannot go further. This is done by extending the definition of a labeled transition system with refusal transitions.

Testing methods for LTS models are based on symmetric communication between the system and its environment. Both environment and system actions are indeed treated in the same way. There is no notion of input or output. However, it turns out such a classification of actions into inputs and outputs leads to a closer link to testing process reality [START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF][START_REF] Lynch | An introduction to input/output automata[END_REF][START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF][START_REF] Tretmans | Testing labeled transition systems with inputs and outputs[END_REF][START_REF] Jéron | Contribution à la génération automatique de tests pour les systèmes réactifs[END_REF]. This is due to the fact that outputs (respectively inputs) have to be considered as actions that are initiated by, and under control of the system (respectively that are initiated by, and under control of the environment). That distinction between input and output actions then has a fundamental role in testing practice in which the tester chooses an input action i, provides it to the implementation under test, and then observes output actions produced by the implementation after i. We refer to the state of arts of the thesis [START_REF] Phalippou | Relations d'implementation et hypothèses de test sur des automates à entrées et à sorties[END_REF][START_REF] Zinovieva | Symbolic Test Generation for Reactive Systems with Data[END_REF][START_REF] Heerink | Ins and Outs in Refusal Testing[END_REF] as well as to the articles [START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF][START_REF] Brinksma | Testing transition systems: An annotated bibliography[END_REF] for further details.

Hence, most of the relations based on LTS have been extended to IOLTS models. Both the testing preorder ≤ te and the refusal preorder ≤ r f were redefined to allow to take into account inputs and outputs of systems [START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF][START_REF] Tretmans | Testing techniques[END_REF]. The con f relation was also adapted for the IOLTS models, and called iocon f [START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF][START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF]. Indeed, the relation iocon f is similar to con f , but distinguishes inputs from outputs, and restricts all possible observations to the traces of the specification. It checks only whether a given implementation does what it should do, without regard to unspecified behaviours. The implementation then has the freedom to do more that what is specified. The relation ioco [START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF][START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF] is similar to ioconf, but it uses suspension traces (i.e. traces generated from suspension models whose quiescence2 is specified) instead of proper traces (i.e. traces generated from models whose quiescence is not handled) to check the conformance between iut and spec. There are many other types of relations [START_REF] Milner | Communication and concurrency[END_REF][START_REF] Hoare | Communicating sequential processes[END_REF][START_REF] Langerak | A testing theory for LOTOS using deadlock detection[END_REF].

The relations conf, ioconf and ioco have received much attention by the community of formal testing because they have shown their suitability for conformance testing and automatic test derivation [START_REF] Tretmans | Conformance testing with labelled transition systems : Implementation relations and test generation[END_REF]. The reason is that the objective of conformance testing is mainly to check whether the implementation behaves as required by the specification i.e. to check if the implementation does what it should do. Hence, a conformance relation has to allow implementations not only to do what is specified, but also to do more than what is specified (for instance, when an annoyed user hits or kicks the coffee machine, or does other strange things that we are not usually considered in the specification). This requirement of testing conformance is well satisfied by conf, ioconf and ioco contrary to other relations [START_REF] Milner | Communication and concurrency[END_REF][START_REF] De Nicola | Testing equivalences for processes[END_REF][START_REF] De | Extensional equivalence for transition systems[END_REF][START_REF] Phillips | Refusal testing[END_REF][START_REF] Langerak | A testing theory for LOTOS using deadlock detection[END_REF] that require testing behaviours that are not in the specification i.e. the implementation does not have the freedom to produce outputs for any input not considered in the specification.

Since we are dealing with components with input and output and quiescence is implicitly defined in our component models, we choose ioco and extend it to fit our framework taking into account that other relations previously presented could also have been defined in our framework. There are several extensions to ioco according to both the transition system type and the aspect considered to be tested. For instance, sioco for symbolic transition systems [START_REF] Frantzen | A Symbolic Framework for Model-Based Testing[END_REF], sioco for input-output symbolic transition systems [START_REF] Rusu | An approach to symbolic test generation[END_REF], tioco for timed labeled transition systems [START_REF] Briones | A test generation framework for quiescent real-time systems[END_REF], cspio for CSP process algebra [START_REF] Nogueira | Guided Test Generation from CSP Models[END_REF], dioco for distributed systems [START_REF] Heerink | Refusal testing for classes of transition systems with inputs and outputs[END_REF], uicoco for hybrid system [START_REF] Van Osch | Hybrid input-output conformance and test generation[END_REF], etc.

Definition

We redefine the ioco conformance testing relation that we will call here cioco 3 in terms of components as defined in Chapter IV. We make some modifications to the original definition of ioco to fit our component definition. That is, after each trace tr of a specification spec, instead of considering that the possible outputs of the corresponding implementation iut after executing tr on it is a subset of the possible outputs of spec, we consider that the corresponding implementation iut, after executing tr on it and then submitting any input i of the specification to it, does not produce outputs that are not allowed by spec.

The formal definition of cioco uses the following definition: -(iut 1 cioco spec) as after executing any finite trace of spec on iut, the outputs of iut 1 are included into the outputs of spec, when any specified input of spec is submitted to iut. For instance, after the finite trace tr = coin|abs, coffee|served, coin|abs of spec, for the "coffee" input, one has:

Out(iut 1 after (tr, coffee)) = {served, refund} ⊆ Out(spec after (tr, coffee)) = {served, refund} 3. c for component -¬(iut 2 cioco spec). This is because the output "refund" from the state FAILED of iut 2 after the finite trace coin|abs, coffee|refund is not allowed by spec when iut 2 receives the input "repair" (see the red transition repair|refund), while the specification only allows the output abs:

Out(iut 2 after ( coin|abs, coffee|refund , repair)) = {refund}

Out(spec after ( coin|abs, coffee|refund , repair)) = {abs} -¬(iut 3 cioco spec). This is because the output abs of iut 3 after the trace coin|abs is not allowed by the specification spec when iut 3 receives the input "coffee" (see the red transition coffee|abs):

Out(iut 3 after ( coin|abs , coffee)) = {served, refund, abs}

M 1 ioco M 2 iff φ(M 1 ) cioco φ(M 2 ) Proof =⇒ Let (M 1 ioco M 2 ), tr ∈ Trace(φ(M 2 )), i

End

Similarly to iocon f , verifying that a Mealy machine implementation iut quasi-reduction4 a Mealy machine specification spec is not the same as checking whether cioco holds for the components resulting by instancing iut and spec in our framework. Figure VII.2 shows a counterexample: the implementation iut conforms to the specification spec w.r.t. quasi-reduction, that is because for all input sequences of spec, iut'outputs are allowed by spec. For instance, after the input sequence i 1 , i 2 , i 3 , i 4 , the output o 5 of iut is specified. On the other hand, iut does not conforms to spec w.r.

Formal definition

In this subsection, we define the finite computation tree of a component C which captures all its finite traces. Definition 2.1 (C-paths) Let C = (S, s 0 , α) be a component over T(Out × ) In . A C-path is defined by two finite sequences of states and inputs (s 0 , . . . , s n ) and (i 0 , . . . , i n-1 ) such that:

∀j, 1 ≤ j ≤ n, s j ∈ η ′ Out×S α(s j-1 )(i j-1 ) | 2
Definition 2.2 (Finite computation tree of component) Let (S, s 0 , α) be a component over the signature T(Out × ) In . The finite computation tree of depth n of C, noted FCT(C, n), is the coalgebra (S FCT , s 0 FCT , α FCT ) defined by: -S FCT is the whole set of C-paths -s 0 FCT is the initial C-path s 0 , () α FCT is the mapping which for every C-path (s 0 , . . . , s n ), (i 0 , . . . , i n-1 ) and every input i ∈ In associates η ′-1 Out×S FCT (Γ) where Γ is the set:

Γ = o, (s 0 , . . . , s n , s ′ ), (i 0 , . . . , i n-1 , i) | (o, s ′ ) ∈ η ′ Out×S α(s n )(i)
In this definition, S FCT is the set of the nodes of the tree. s 0 FCT is the root of the tree. Each node is represented by the unique C-path (s 0 , . . . , s n ), (i 0 , . . . , i n-1 ) which leads to it from the root:

s 0 i 0 -→ s 1 i 1 -→ . . . i n-2 --→ s n-1 i n-1 --→ s n
α FCT gives, for each node p and for each input i, the set of nodes Γ that can be reached from p when the input i is submitted to the component.

Unfolding algorithm

In this subsection, we show that Definition 2.2 is computable by showing how to build a tree FCT(C) algorithmically that captures all the possible finite computation paths of the component C = (S, s 0 , α) over the signature H = T(Out × ) In . This tree can be thought of as a data structure representing the component computations obtained after a finite unfolding of C. Starting from the initial state s 0 of C, a tree t containing all the elementary paths is built by running a depthfirst search (DFS) as well as a set H(C) containing the heads (i.e. the first explored state) of all elementary circuits which exist in C. To be more accurate, we assign a unique name to each explored state and we also maintain the original state in C for every explored state in H(C). The FCT(C) is therefore built recursively by binding to t in every state in H(C), the tree obtained by applying the depth-first search to its original state in C. This means that if the component has a circuit, then its unfolding is an infinite tree. To prevent this algorithm from running indefinitely (the unfolding contains infinitely many visits to each state), we can enrich it with the option of specifying the maximum time to go through the circuit. Briefly, unfolding the component using this algorithm gives rise to a tree that contains isomorphic subtrees, describing redundant computations, and each state can be reached via a unique execution from the initial state. It allows us to capture all possible behaviours of the component at once. If we need to examine a subset of the behavior of the system, then we use a stopping (or coverage) criteria which determines the maximum number of passes through each circuit of C.

Hence, our mechanism of unfolding can be described by two algorithms. The first one, called Enumerate, is a simple depth-first search that gives rise, as results, to the tree containing all the elementary paths of C, and the first explored state of every circuit existing in C. The second algorithm, called Unfolding, allows one to construct recursively the entire computation tree taking into account how many times we go through every circuit of C.

Algorithm 1: Enumerate(C, (S ′ , init ′ , α ′ ), s, LS, HC, P)

while ∃i ∈ In, (o, s ′ ) ∈ Out × S | (o, s ′ ) ∈ η ′ (α(s)(i)) do nb ′ ← GiveNumber(s ′ ); Add(S ′ , nb ′ ); α ′ (init ′ )(i) ← α ′ (init ′ )(i) ∪ η ′-1 ({(o, nb ′ )}); if Color(s ′ ) = W or
T(m) =    3 + 8 × N i f m = 1 3 + 8 × N + T(m -1) otherwise
To guess at a solution, let's try unrolling the recurrence, by substituting it into itself as follows:

T(m) = T(m -1) + 3 + 8 × N T(m -1) = T(m -2) + 3 + 8 × N . . . T(m -(m -2)) = T(1) + 3 + 8 × N
Then, T(m) satisfies the recurrence:

T(m) = m(3 + 8 × N)
Consequently, Enumerate runs in Θ(mN).

Unfolding: Let T(n) be the number of elementary operations necessary to unfolding a component C over T(Out × ) In with n as the number of times that the algorithm goes through each circuit in C. We can easily see that Unfolding satisfies the following recurrence:

T(n) =    9 + m + m × N i f n = 1 (9 + m + m × N) + 6 × nb × T(n -1) otherwise
To guess at a solution, let's try unrolling the recurrence, by substituting it into itself as follows:

T(n) = 6 × nb × T(n -1) + 9 + m + m × N T(n -1) = 6 × nb × T(n -2) + 9 + m + m × N . . . T(n -(n -2)) = 6 × nb × T(1) + 9 + m + m × N
Then, T(n) satisfies the recurrence:

T(n) = (9 + m + m × N) n ∑ i=0 (6 × nb) i
Consequently, Enumerate runs in Θ(mNnb n ). End Example 2.2 Figure VII.4 shows a graphical representation of a component C (on the left side) and its unfolding FCT(C, 2) as a finite computation tree (on the right side). Unfolding(C, init, 2) calls Enumerate which in turn returns a tree t containing all the elementary paths of C (t is colored red) as well as the set containing the couple (s 1 , 5). s 1 is the first state involved in the circuit (s 1 s 2 s 3 s 1 ) and 5 is the node associated to s 1 in FCT(C, 2). Since we intend to build a tree of depth 2, then Unfolding glues in 5 the tree t ′ (colored blue) built by unfolding C in s 1 .

5.

Operations such that Add, ∪, GiveNumber, etc. are considered as elementary operations i.e. they run in Θ(1).

Test Purpose

As previously mentioned, our model of a specification is described as a coalgebra over T(Out × ) In . Such a model usually contains a growth of exponential states which makes the testing process difficult even impossible to be implemented. To cope with this problem, test purposes can be used. A test purpose is a description of the part of the specification that we want to test and for which test cases are to be generated. In other words, it narrows down the model of the specification into smaller ones from which test cases are later generated. In [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Fernandez | Using on-the-fly Verification Techniques for the Generation of Test Suites[END_REF], test purposes are described independently of the model of the specification. Then, a synchronous product is done between the test purpose and the specification in order to keep only the paths accepted by the specification. In [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF], test purposes are deduced from the specification by construction. More precisely, a test purpose is considered as a finite symbolic subtree of the symbolic execution tree generated from a specification IOSTS using a symbolic execution technique. Then, leaves of this tree are labeled by accept and intermediate nodes are labeled by skip (states leading to states from which it is possible to go to accepting states). All other nodes of the tree not belonging to the test are then labeled by a special label ⊙.

In order to guide the test derivation process in our approach, we prefer, as in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF], to describe test purposes by selecting the part of the specification that we want to explore. We therefore build the finite computation tree FCT(C) of the component C, and consider a test purpose as a tagged finite computation tree of the specification. The leaves of the FCT which correspond to paths that we want to test are tagged accept. All internal nodes on such paths are tagged skip, and all other nodes are tagged ⊙.

In summary, these labels in trees serve either to accept, or to reject the behaviours of specifications as follows: a path that is a part of the test purpose is called path purpose and noted X . The last node of the path in question is tagged accept. All other nodes of this path are tagged skip. They correspond to the fact that it is still possible to transmit additional input i to the implementation and receive its output o to reach an accepted node. Finally, all other nodes that are not part of X are tagged ⊙. -there exists a C-path p ∈ S FCT such that TP(p) = accept -if TP( (s 0 , . . . , s n ), (i 0 , . . . , i n-1 ) ) = accept, then: ∀j, 1 ≤ j ≤ n -1, TP( (s 0 , . . . , s j ), (i 0 , . . . , i j-1 ) ) = skip -TP( s 0 , () ) = skip -if TP( (s 0 , . . . , s n ), (i 0 , . . . , i n-1 ) ) = ⊙, then: TP( (s 0 , . In order to build a test purpose on a finite computation tree, we choose the leaves of the tree that we accept as correct finite behaviours and tag them with accept. We then tag every node which represents a prefix of an accepted behaviour with skip. The other nodes, which lead to behaviours that we do not want to test, are tagged with ⊙.

Note a test purpose can be characterized by one path purpose X , two path purposes X , even all the finite computation tree.

In the following, we use the notation TP to refer to an arbitrary test purpose. TP 1 : this test purpose allows us to ignore the behaviours of M related to failure and repair and to concentrate on its interaction with a user. When the machine fails, we reach node p 4 , p 5 or p 11 which are tagged with ⊙. This indicates that we are not interested in further behaviour from these nodes. p 2 , p 9 and p 10 are tagged with accept because they are nodes corresponding to the expected behaviour. All nodes leading from the root p 0 to these nodes are tagged with skip.

TP 2 : this test purpose describes the behaviours of M where it delivers coffee and goes into a blocked state. When the machine fails after delivering coffee, we only reach node p 5 which we tag with accept. Then, p 0 , p 1 and p 2 are tagged skip and all other nodes are tagged with ⊙.

TP 3 : this test purpose describes the behaviours of M where it fails to deliver coffee to the user but refunds him. When the machine refunds the user and goes into a blocked state, we reach node p 4 or p 11 which we tag with accept. Then, p 0 , p 1 , p 3 and p 6 are tagged skip and all other nodes are tagged with ⊙.

Test generation guided by test purposes

Conformance testing is based on a conformance relation between the component modeling the implementation iut and the component denoting the specification spec. The conformance relation we use is cioco, which requires that the iut's outputs are among the outputs allowed by spec for every specified input sequence. A test execution is then the process of feeding the iut with a test case, observing its response and giving some test verdicts.

-Test purposes of the coffee machine

There exist several different techniques to generate test cases systematically from a specification in such a way these test cases can distinguish correct implementations, and incorrect ones. These techniques differ by both specification model and conformance relation used for testing. They can be classified in two main categories: random techniques and techniques guided by test purposes. Random techniques, such as in [START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF][START_REF] Tretmans | A Formal Approach to Conformance Testing[END_REF], are used to generate test cases based on non-deterministic choices. This is done by exploring the specification randomly and selecting new actions until a certain user-defined bound on steps is reached, or no match is found between the outputs of the implementation and of the specification. Techniques guided by test purposes, such as in [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF], are based on the definition of a test purpose which is used to allow the tester to select a property to be tested. In [START_REF] Jéron | TGV: theory, principles and algorithms[END_REF], a test case can be generated by computing the synchronized product of the specification and the test 6 purpose. In [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF], test cases are generated from a finite symbolic tree obtained according to a test purpose which can be either chosen manually by the user or computed automatically by means of inclusion 7 criteria.

Similarly to [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF], we propose an approach for test case selection according to a test purpose. The advantage of the testing theory proposed in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] is that it is based on the conformance relation ioco that we adopt in our framework and as previously stated, has received much attention by the community of formal testing thanks to its suitability for both conformance testing and automatic test derivation. Furthermore, test generation algorithms proposed in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF] are simple in their implementation and efficient in their execution.

Figure VII.6 illustrates graphically the elements of the approach. A test case is generated from the finite computation tree FCT(spec) of a specification spec enriched with a test purpose TP. It is considered as a sequence of input-output actions built progressively by interacting with the implementation iut, and which examines one of the behaviours of the specification spec selected by the test purpose TP (i.e. the last node of the path is tagged accept). The underlying idea to building such a sequence is the following: we choose an input action i according to the interactions with the iut previously computed and the set of reachable states that can lead to accepting states of TP. Then, the reaction (output) o received from the implementation is compared to the specified ones, and depending on the result of this comparison, our algorithm continues its computation, or stops by generating a verdict. We therefore distinguish four verdicts:

-Fail: means that the output o does not match the specification, and then the interaction sequence does not form the trace of any path purpose. Hence, the goal of the test case is not reached;

-Pass: means that no observable difference between the specification and the implementation is detected;

-Inconc: means that no error is detected but, the test purpose is not achieved;

-WeakPass: means that the implementation behaves correctly but, due to the fact of nondeterministic specification, we are not sure whether the test purpose has been achieved. [START_REF] Jacobs | A tutorial on coalgebras and coinduction[END_REF]. Test purposes are usually supposed to be given by an expert. [START_REF] Reichel | An approach to object semantics based on terminal co-algebras[END_REF]. It is stated in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF], that inclusion criterion can be used to answer industrial needs where engineers are not always able to define which behaviour they want to test.

Preliminaries

In this section, we introduce some notations and definitions that will be used in describing our algorithm for generating conformance tests for components.

As mentioned above, a test case is a sequence generated by a test purpose TP interacting with iut. This is denoted by: [ev 0 , ev 1 , . .

. , ev n |V]

where for all j ∈ [0, . . . , n], ev j = i|o is an elementary input-output with i ∈ In, o ∈ Out and V ∈ {Fail, Pass, Inconc, WeakPass}.

We note stimobs(i|o) the output o from iut when stimulating it with input i.

In order to compute the set of reachable states that lead to accept states after a given inputoutput sequence, we define a current set of states denoted by CS that contains a subset of the states of the test purpose. It is initialized to the initial state of TP. We also introduce three functions to help explore TP by selecting paths that lead to accept states:

-Next(CS, ev) is the set of directly reachable states from the current set of states CS after executing ev;

-NextSkip(CS, ev) is the set of states in Next(CS, ev) which are labeled by skip;

-NextPass(CS, ev) is the set of states in Next(CS, ev) which are labeled by accept.

More formally, these three sets are defined as follows:

Definition 4.1 Let TP : S FCT -→ {accept, skip, ⊙} be a test purpose for a component C, ev = i|o an event, and S ′ a subset of S FCT :

-

Next(S ′ , ev) = s ′ ∈S ′ ({s | (o, s) ∈ η ′ Out×S FCT (α FCT (s ′ )(i))}); -NextSkip(S ′ , ev) = Next(S ′ , ev) TP(S ′ ) | skip ; -NextPass(S ′ , ev) = Next(S ′ , ev) TP(S ′ ) | accept . with TP(S ′ ) | tag = {s ′ ∈ S ′ | TP(s ′ ) = tag}

Inferences rules

We define our test case generation algorithm as a set of inferences rules. Each rule states that under certain conditions on the next observation of output action from iut or the next stimulation of iut by an input action, the algorithm either performs an exploration of the other states of TP, or stops by generating a verdict.

We structure these rules as

CS

Results

cond(ev)

where -CS is a set of current states;

-Results is either a set of current states or a verdict;

cond(ev) is a set of conditions including stimobs(ev).

Each rule must be read as follows:

Given the current set of states CS, if cond(ev) is satisfied, then the algorithm may achieve a step of execution, with ev as input-output elementary sequence.

This algorithm can be seen as an exploration of the finite computation tree starting from the initial state. It switches between sending stimuli to the implementation and waiting for output of the implementation according to the inference rules as long as a verdict is not reached. We distinguish two kinds of inference rules : exploring rules and diagnosis rules. The first kind is applied to pursue the computation of the sequence as long as Result is a set of states. The second kind leads to a verdict and stops the algorithm. The algorithm is applied as follows:

rule 0 CS 0 = {p 0 } coin|abs rule 1 CS 1 = {p 1 } coffee|served rule 1 CS 2 = {p 2 , p 3 } CS 2 coin|abs rule 1 CS 3 = {p 6 } coffee|served rule 4 Pass
The verdict Pass is due to the following equality:

NextPass(CS 3 , coffee|served) = Next(CS 3 , coffee|served), Next(CS 3 , coffee|served) = ∅
WeakPass To get the verdict WeakPass, we consider the following trace:

[coin|abs, coffee|served WeakPass]

The algorithm is applied as follows:

rule 0 CS 0 = {p 0 } coin|abs rule 1 CS 1 = {p 1 } coffee|served rule 5 WeakPass
The verdict WeakPass is due to the two equalities:

-

NextPass(CS 1 , coffee|served) ⊂ Next(CS 1 , coffee|served) -NextPass(CS 1 , coffee|served) = {p 2 } = ∅

Test cases for TP 2

Fail To get the verdict Fail, we consider the following trace:

[coin|abs, coffee|served, repair|refund Fail]

The algorithm is applied as follows:

rule 0 CS 0 = {p 0 } coin|abs rule 1 CS 1 = {p 1 } coffee|served rule 1 CS 2 = {p 2 , p 3 } CS 2 repair|refund rule 2 Fail
The verdict Fail is due to the following equality:

Next(CS 2 , repair|refund) = ∅ Inconc To get the verdict Inconc, we consider the following trace:

[coin|abs, coffee|served, coin|abs Inconc]

The algorithm is applied as follows:

rule 0 CS 0 = {p 0 } coin|abs rule 1 CS 1 = {p 1 } coffee|served rule 1 CS 2 = {p 2 , p 3 } CS 2 coin|abs rule 3 Inconc
The verdict Inconc is due to the following two equalities:

- The algorithm is applied as follows:

rule 0 CS 0 = {p 0 } coin|abs rule 1 CS 1 = {p 1 } coffee|served rule 1 CS 2 = {p 2 , p 3 } CS 2 repair|abs

rule 4 Pass

The verdict Pass is due to the following equality:

NextPass(CS 2 , repair|abs) = Next(CS 2 , repair|abs), Next(CS 2 , repair|abs) = ∅ WeakPass There is no test cases ending by the verdict WeakPass for TP 2 .

Properties

A test case informs us of the conformance of the implementation to its specification. The non-existence of a Fail verdict leads to a conformance, and any non-conformance should be detected by a test case ending by a Fail verdict. In order to study the coherence between the notion of conformance applied to an implementation under test and its specification, and the notion of a test case generated by our algorithm, we denote by CS and EV respectively the whole set of current state sets and the whole set of input-output elementary sequences used during the application of the set of inference rules on an implementation iut according to a test purpose TP. We then introduce a transition system whose states are the sets of current states and four special states labeled by the verdicts. Two states are linked by a transition labeled by an input-output elementary sequence. This transition system is formally defined as follows: Definition 4.2 (Execution) Let TP be a test purpose for a specification spec, let iut be an implementation, let CS be the whole set of current state sets and let EV be the whole set of input-output elementary sequences. Then, the execution of the test generation algorithm on iut according to TP denoted by TS(TP, iut) (see its explanation in Section 4.2) is the coalgebra (S TS , α TS ) over the signature ( ) EV defined by: More precisely, according to the definition of cioco, we have to prove that: there exists a finite trace tr ∈ Trace(FCT), an input i ∈ In such that Out iut (iut after (tr, i)) Out FCT (FCT after (tr, i)) This is proved by the following proposition: Proposition 4. 1 If there exists a test purpose TP such that [i 0 |o 0 , . . . , i n |o n |Fail] ∈ st(TP, iut), then:

1. i 0 |o 0 , i 1 |o 1 , . . . , i n-1 |o n-1 ∈ Trace(FCT). 2. i n ∈ In 3. o n ∈ Out iut (iut after ( i 0 |o 0 , . . . , i n-1 |o n-1 , i n )). 4. o n ∈ Out spec (spec after ( i 0 |o 0 , . . . , i n-1 |o n-1 , i n )).
First of all, let us denote i 0 |o 0 . . . i n-1 |o n-1 by ev 0 . . . ev n-1 .

Proof of (1).

In order to show that the sequence i 0 |o 0 . . . i n-1 |o n-1 ∈ Trace(FCT), we are going to reason on the way of computation of this sequence by using the inference rules. First of all, let TS(TP, iut) be the execution of the test generation algorithm and st(TP, iut) be the set of generated test cases. Since [i 0 |o 0 , . . . , i n |o n |Fail] ∈ st(TP, iut), then there exists ∀j, 0 ≤ j < n, S j ∈ CS such that S 0 = {s 0 TS }, S j+1 = α TS (S j )(ev j ) and Fail = α TS (S n )(ev n )

Hence, for every j, 0 ≤ j < n, S j+1 which equals to Next(S j , ev j ) is not empty by Definition 4.2. Hence, by Definition 4.1, for every j, 0 ≤ j < n, every state belonging into S j+1 is a state of FCT. This means that for every j, 0 ≤ j < n, every state s ∈ S j is related to a state s ′ ∈ S j+1 by ev j . Then, the sequence ev 0 . . . ev j . . . ev n-1 ∈ Trace(FCT).

Proof of (2).

We have proved above that i 0 |o 0 . . . i n-1 |o n-1 ∈ Trace(FCT) and S n = ∅. We have that [i 0 |o 0 . . . i n |o n |Fail] ∈ st(TP, iut) i.e. submitting the input i n to the implementation under test will produce the output o n that is not specified in FCT(C). Then, it is clear that i ∈ In is an input of FCT(spec).

Proof of (3).

It is obvious because

[i 0 |o 0 , i 1 |o 1 , . . . , i n |o n |Fail] ∈ st(TP, iut).

Proof of (4).

We know that i 0 |o 0 . . . i n-1 |o n-1 ∈ Trace(FCT) and S n = ∅. We have that [i 0 |o 0 . . . i n |o n |Fail] ∈ st(TP, iut) i.e. applying i n |o n has to lead to a Fail verdict. This means that α TS (S n )(i n |o n ) = Fail. Hence by Definition 4.2, Next(S n , i n |o n ) has to be empty. But we know that Next(S n , i n |o n ) ⊆ S FCT . Hence, i 0 |o 0 , . . . , i n-1 |o n-1 , i n |o n does not belong to Trace(FCT).

Proof of the completeness :

Let spec = (S, s 0 , α) be a specification over a signature H = T(Out × ) In and FCT = (S FCT , s 0 FCT , α FCT ) be its finite computation tree. Let us prove that the completeness holds.

For this, let us assume that iut does not conform to spec and let us prove that there exists a test purpose TP such that there exists [ev 0 , . . . , ev n |Fail] ∈ st(TP, iut).

First of all, iut does not conform to spec. According to the definition of cioco, there exists a trace tr = ev 0 . For this, it is enough to show that ∃(S j ) 0≤j≤n such that ∀j, 0 ≤ j < n, S j+1 = α TS (S j )(ev j ) ∈ CS and Fail = α TS (S n )(ev ′ n ) We have that ev 0 . . . ev n-1 ∈ Trace(FCT), then, for every j, 0 ≤ j < n, S j exists because for every j, 1 ≤ j < n, α TS (S j )(ev j ) = Next(S j , ev j ) and S 0 = {s 0 FCT }.

Instantiating of the approach

From the genericity of our framework, the testing technique proposed in this chapter, can also be applicable to any-state formalisms which are instances of our framework. Figure VII.8 illustrates the different steps to generate correct test cases for any model instance of our framework. First, we define the function φ which transforms the model in which a specification is given (for example, an IOLTS or Mealy automaton) into our framework. This function has to be bijective to allow us to go back to the original formalism. This transformation is illustrated on the left side in Figure VII.8. Second, we need to prove the equivalence between the conformance relation rel used between iut and spec and the cioco defined on their images φ(iut) and φ(spec). Third, we apply our proposed algorithm for test case derivation on φ(spec) to generate correct test cases. Finally, we transform the obtained test cases into test cases described in the original formalism. Hence, testing systems, whose specification models can be viewed as instances of our component definition, require us to define the bijective transformation φ and to prove that the following property holds:

iut rel spec ⇐⇒ φ(M In Chapter VII, we have shown how component implementations are tested to be ciococorrect to their component specifications separately. This is classically known as unitary testing. The present chapter intends to validate the complex systems made by assembling a set of statebased components. This is classically known as compositional testing (or component based testing). Due to the growing complexity of the space state of the complex systems, it is difficult even impossible to use the black-box testing approach that we proposed in Chapter VII. Therefore, there is a need to systematically derive test cases based on the structure of the complex system. We believe that it is natural and easier to test a system by testing only its subsystems.

Hence, in this chapter we intend to contribute in two ways:

1. By defining a compositional testing approach. The main idea is to test an integrated system assuming that its underlying components have already been tested in isolation and are correct [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF]. The operators used to compose components are assumed to be wellimplemented and to preserve their specifications. Thus, the problem of compositional testing that we address can be seen as follows: if single components of a system conform to their specifications, can we conclude that the whole system is in conformance to its specification? As a consequence of positive answer to this question, we can test the global system by testing in isolation its components that may be done at various steps of development and potentially developed by different teams.

2.

By strengthening the quality of components by taking into account their involvement in the global system that encapsulates them. The main idea consists in showing how to strengthen the correctness of each component involved in a global system, by choosing suitable test purposes for them. This will be done by defining a projection mechanism that, from a behaviour of the global system, will help to generate test purposes capturing behaviours of sub-systems that typically occur in the whole system [START_REF] Faivre | Symbolic model based testing for component oriented systems[END_REF].

In Section 1, we study the compositional testing problem in our framework by explaining and formalizing this problem. In Section 2, we study the projection mechanism by showing how to define test purposes from global behaviour of a system and how to project them on any sub-system of it. Finally, in Section 3, comparisons with existing works close to our modeling framework will be done.

Compositional testing

Compositional testing consists in testing communicating components that have been tested separately. It aims to guarantee the correctness of the integration of a set of components S = op(C 1 , . . . , C n ) from the correctness of each components C i in isolation where op is the integration operator of interest. Thus, such a compositional testing theory provides a way to test the integrated system only by testing its sub-systems i.e. there is no need to re-test its conformance correction. It is formally expressed as follows:

Given implementation models iut 1 , . . . , iut n and their specifications spec 1 , . . . , spec n ∀i, 1 ≤ i ≤ n, (iut 1 rel spec 1 ), . . . , (iut n rel spec n ) =⇒ op(iut 1 , . . . , iut n ) rel op(spec 1 , . . . , spec n )

where rel and op denote the conformance relation and the integration operator of interest respectively.

Hence, once this property is verified, the correctness of the integrated system is obtained from the correctness of the individual components. To test the integrated system, it is not necessary to consider it as a whole, but it is enough to consider its sub-systems and test them separately. Indeed, the contraposition of this property is the following: ¬ op(iut 1 , . . . , iut n ) rel op(spec 1 , . . . , spec n ) =⇒ ∃i, 1 ≤ i ≤ n, ¬(iut i rel spec i ) Thus, by looking at this new property, we can easily see that non-correctness of the integrated system under test op(iut 1 , . . . , iut n ) implies that at least one of its components iut 1 , . . . , iut n is incorrect. In other words, that means to test op(iut 1 , . . . , iut n ), it suffices to test iut 1 , . . . , iut n in isolation.

Compositional testing with cioco

In this subsection, we study the compositional testing problem in our framework. Then, we intend to address the following question:

Given that the components C 1 , . . . , C n over the signatures H 1 = T(Out 1 × ) In 1 , . . . , H n = T(Out n × ) In n respectively, are cioco-correct 1 separately, may we conclude that their integration C = op(C 1 , . . . , C n ) using a complex operator 2 op is also cioco-correct?

The response to this question amounts to first addressing both for cartesian product and feedback operator, and then by showing cioco correctness is stable for its composition. Hence, in this following we intend to give answers to the following three questions: Question 1:

Given (iut k cioco spec k ) for k = 1, 2, is it the case of ⊗(iut 1 , iut 2 ) cioco ⊗(spec 1 , spec 2 )?
1. For instance using our conformance testing approach defined in Chapter VII. 2. See Chapter V, for the definition of a complex operator.

Question 2:

Given (iut cioco spec), is it the case of ←֓ I (iut) cioco ←֓ I (spec)?

Question 3:

Given (iut cioco spec), is it the case of I (iut) cioco I (spec)?

In the following subsections we will show that the answer to Question 1 is positive without imposing any conditions i.e. cioco is naturally compositional for the cartesian product. However, the answer to both Question 2 and Question 3, in general, is negative. To a get positive answer, the specification should be input-enabled. In other words, compositionality does not hold for cioco with respect to the feedback operators, unless the specification model is input-enabled. Without this condition, even if both iut 1 and iut 2 are cioco-correct, the resulting implementation obtained by means of feedback operators may not be.

Example 1.1 To illustrate our compositional testing, we consider two components3 of a coffee machine: a "money component" M that handles the inserted coins and "drink component" D that produces the drinks. when it receives a coffee coin "coinC" (resp. a tea coin "coinT") from the user, it gives an order "makeC" (resp. "makeT") to the drink component D to make coffee (resp. tea).

Drink component specification spec D :

when it receives the order "makeC" (resp. "makeT") to make coffee (resp. tea) from the money component M, if there is nothing wrong during the drink preparation process, it directly delivers the coffee (resp. tea) to the user, or else it sends an error message to the money component in order to refund the user.

Money component implementation iut M :

it behaves as the money component4 specification spec M , but in addition it does some extra functionalities, that is if an error occurs during the drink preparation process, it refunds the inserted coin to the user.

Drink component implementation iut D :

it behaves exactly as the drink component specification spec D .

In our framework, spec M , iut M , spec D and iut D are modeled as follows:

spec M is the coalgebra ({q 0 }, q 0 , α 1 ) over the signature ({makeC, makeT} × ) {coinC,coinT} where α 1 is depicted in Figure VIII.2a.

iut M is the coalgebra ({q ′ 0 , q ′ 1 }, q ′ 0 , α ′ 1 ) over the signature ({makeC, makeT, refund} × ) {coinC,coinT,error} where α ′ 1 is depicted in Figure VIII.2c.

spec D is the coalgebra ({s 0 , s 1 , s 2 , s 3 , s 4 }, s 0 , α 2 ) over the signature ({error, tea, coffee, preparing} × ) {makeC,makeT} where α 2 is depicted in Figure VIII.2b.

iut D is the coalgebra ({s ′ 0 , s ′ 1 , s ′ 2 , s ′ 3 , s ′ 4 }, s ′ 0 , α ′ 2 ) over the signature ({error, tea, coffee, preparing} × ) {makeC,makeT} where α ′ 2 is depicted in Figure VIII.2d.

The components M and D may communicate separately (for instance D may execute the transition labeled with abs|coffee while M does nothing) or jointly in synchronization (for instance when M execute the transition labeled with coinC|makeC, M receives instantaneously the output makeC and then produces the output coffee). Then, the suitable composition of M and D is the synchronous parallel composition ⊙ defined in Chapter V, Section 2. [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF].

As far as the compositional testing is concerned, we have that (iut M cioco spec M ) and (iut D cioco spec D )

Our goal is to know if this is enough to ensure whether the global implementation ⊙(iut M , iut D ) is in conformance with respect to cioco to the global specification ⊙(spec M , spec D ). Hence, to test ⊙(iut M , iut D ), it suffices to test if (iut M cioco spec M ) and (iut D cioco spec D

). An answer to this question is given later in this chapter.

Compositionality for cartesian product

We show here that cioco is naturally preserved by the cartesian product.

Theorm 1.1 Let H 1 = T(Out 1 × ) In 1 and H 2 = T(Out 2 × ) In 1 be two signatures. Let H = T((Out 1 × Out 2 ) × ) In 1 ×In 2 be the cartesian product interface for H 1 and H 2 . Let iut j , spec j ∈ Comp(H j ) for j = 1, 2 and ⊗((iut 1 , iut 2 )), ⊗((spec 1 , spec 2 )) ∈ Comp(H). Then, we have:

iut 1 cioco spec 1 iut 2 cioco spec 2    =⇒ ⊗((iut 1 , iut 2 )) cioco ⊗ ((spec 1 , spec 2 ))
Proof Let us assume that:

(iut 1 cioco spec 1 ) and (iut 2 cioco spec 2 ) and let us then prove that: ⊗((iut 1 , iut 2 )) cioco ⊗ ((spec 1 , spec 2 ))

Let us use the contradiction principle. For this, let us assume that ¬(⊗((iut 1 , iut 2 )) cioco ⊗ ((spec 1 , spec 2 )))

i.e. there exists a finite trace tr = (i

1 , i ′ 1 )|(o 1 , o ′ 1 ), . . . , (i n , i ′ n )|(o n , o ′ n ) ∈ Trace(⊗((spec 1 , spec 2 )
)) and (i, i ′ ) ∈ In 1 × In 2 such that there exists an output (o, o ′ ) ∈ Out 1 × Out 2 among the outputs obtained after executing (tr, (i, i ′ )) on ⊗((iut 1 , iut 2 )) not belonging to the ones obtained after executing (tr, (i, i ′ )) on ⊗((spec 1 , spec 2 )). are respectively the traces involved in iut 1 and iut 2 to obtain tr. We also know by hypothesis that tr 1 ∈ Trace(spec 1 ) and tr 2 ∈ Trace(spec 2 ).

Since (o, o ′ ) ∈ Out(⊗((iut 1 , iut 2 )) after (tr, (i, i ′ ))) and tr 1 and tr 2 are used to obtain tr, then o ∈ Out(iut 1 after (tr 1 , i)) and o ′ ∈ Out(iut 2 after (tr 2 , i ′ )). Similarly, o ∈ Out(spec 1 after (tr 1 , i)) and o ′ ∈ Out(spec 2 after (tr 2 , i ′ )) because (o, o ′ ) ∈ Out(⊗((spec 1 , spec 2 )) after (tr, (i, i ′ ))) and tr 1 and tr 2 are used to obtain tr. Hence, there exists a trace tr 1 ∈ Trace(spec 1 ), an input i of spec 1 and an output o ∈ Out 1 such that o ∈ Out(iut 1 after (tr 1 , i)) and o ∈ Out(spec 1 after (tr 1 , i)) (respectively there exists a trace tr 2 ∈ Trace(spec 2 ), and input i ′ of spec 2 and an output o ′ ∈ Out 2 such that o ′ ∈ Out(iut 2 after (tr 2 , i ′ )) and o ′ ∈ Out(spec 2 after (tr 2 , i ′ ))). Indeed, this means that ¬(iut 1 cioco spec 1 ) and ¬(iut 2 cioco spec 2 ). Hence, we have a contradiction with our hypothesis. End

Compositionality for feedback operators

We show here that the compositionality of cioco for both synchronous and relaxed feedback operators cannot be obtained without any assumptions made on both specifications and implementations. We first give an example that illustrates the assumptions required to obtain the compositionality of cioco with respect to the feedback operators.

Example 1.2 Figure VIII.3 shows two implementation models iut 1 and iut 2 that have been tested to be cioco-correct according to their respective specification models spec 1 and spec 2 . It is easy to see that (iut 1 cioco spec 1 ) and (iut 2 cioco spec 2 ) Now, using the cartesian product and the feedback operator over the synchronous sequential interface I = ( f , π i , π o ) defined above, the global implementation iut = I (⊗(iut 1 , iut 2 )) can do the trace i 1 |o 3 , i 2 |o 5 . Thus, o 5 ∈ Out(iut after ( i 1 |o 3 , i 2 )) whereas the global specification spec = I (⊗(spec 1 , spec 2 )) can do the trace i 1 |o 3 in such a way o 5 ∈ Out(spec after ( i 1 |o 3 , i 2 )). Hence, we can see that iut does not conform to spec according to cioco.

q 0 q 1 q 2 s 0 s 1 s 2 s 3 spec 1 iut 1 i 1 |o 1 i 2 |o 1 i 2 |o 2 i 1 |o 1 i 2 |o 1 (a) iut 1 cioco spec 1 q ′ 0 q ′ 1 q ′ 2 q ′ 3 spec 2 iut 2 s ′ 0 s ′
This counterexample shows that the feedback operators may give rise to a global implementation that does not conform to its global specification, even if the local implementations conform to their local specifications. This is because the conformance relation cioco does not put any constraint on the traces that are not specified in the specification. It allows implementations to do what they want with the unspecified states. Observe that if the specification specifies for any input what the allowed outputs are, then we do not have this problem. Hence, to cope with this problem, we assume that specifications are input-enabled as in [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF]. That is to say, all states of a specification spec accept all input actions of spec, and for each state s of spec and each input the function α is defined (α is a total function). Then, we have the following theorem for the compositionality for our feedback operators: Theorm 1.2 Let H = T(Out × ) In be a signature. Let I = ( f , π i , π o ) be a relaxed feedback interface. Let C j = (S j , α j ) ∈ Comp(H) such that each C j are input-enabled for every j = 1, 2. Then, we have: The result then follows from the definition of cioco. For this, let us use the proof by induction on the length of a finite trace tr of Trace(←֓ I (C 1 )). Let tr = i 0 |o 0 , . . . , i n |o n be a finite trace of ←֓ I (C 1 ).

-Basic Step: tr = is empty trace. tr = ∈ Trace(←֓ I (C 2 )) trivially holds.

-Induction Step: Let us write tr as concatenation of two finite traces as follows:

tr = i 0 |o 0 , i 1 |o 1 , . . . , i n-1 |o n-1 • i n |o n tr ∈ Trace(←֓ I (C 1 )) implies, according to the relaxed feedback definition (see Chapter V, Definition 1.3), that there exists an input sequence x and a couple ( x, y x ) inductively defined from a finite sequence of states (s 0 , s 1 , . . . , s n ) of S 1 as follows:

x(0) = x(0) and y x (0) ∈ η ′ Out×S 1 (α 1 (s 0 )(x(0))) | 1

-∀j, 0 < j ≤ n, x(j) = f (x(j), y x (j -1)), y x (j) ∈ η ′ Out×S 1 (α 1 (s j )( x(j))) | 1 and s j ∈ η ′ Out 1 ×S 1 (α 1 (s j-1 )( x(j -1))) | 2 and ∀j, 0 ≤ j ≤ n, π i ( x(j)) = i j and π o (y x (j)) = o j .

By induction hypothesis, i 0 |o 0 , . . . , i n-1 |o n-1 ∈ Trace(←֓ I (C 2 )) because i 0 |o 0 , . . . , i n-1 |o n-1 ∈ Trace(←֓ I (C 1 ))

Then, similarly to the above, there exists an input sequence x ′ and a couple ( x′ , y x′ ) inductively defined from a finite sequence of states (s ′ 0 , s ′ 1 , . [START_REF] Rutten | Universal coalgebra: a theory of systems[END_REF], that there exists an input sequence x, an output sequence y and a finite sequence of states (s 0 , s 1 , . . . , s n ) of S 1 such that: ∀j, 0 ≤ j ≤ n, (y(j), s j+1 ) ∈ η ′ Out 1 ×S 1 (α 1 (s j )( f (x(j), y(j))))

mechanism taking a global behaviour p of the whole system and keeping only the part of p being activated in the sub-system that we want to test. Thus, our method for generating test purposes from the global system specification helps to generate good relevant unit test cases to test individual components.

The objective of the approach we propose here is to make component testing more efficient by focusing on the way components are used in global systems. Indeed, as the number of test case combinations is often huge, testing components in isolation would cause test cases important for the global system to be overlooked. As an illustration, let us consider an over simplified system that computes grade averages.

graphical interface calculator makeOperation RequestOperation response

A typical design view of this system consists of two sub-systems:

-an "user interface" I that helps the user to make various operations on grades;

-a "calculator" C that receives operation commands from the user, performs the requested operation, and reports back to the user. Now, testing the component C separately may lead to the consideration of test cases involving arithmetic operations which are irrelevant to computing student grade averages as subtraction, multiplication, square root, etc. This may cause test cases of interest to the system to be missed, i.e. test cases only bringing into play addition and division for grades ranging from 0 to 20. Then, by making a projection of this behaviour on calculator component C, we intend to generate a test purpose that guides the test derivation process of C by only testing operations needed to compute grade averages.

We show here how a trace of a system can be projected on its components. Such projected traces will be the cornerstone to define test purposes dedicated to test components separately. Hence, those test purposes will capture behaviours of sub-systems that typically occur in the whole system. This will be done by combining projection mechanisms and execution mechanisms to generate system computation trees.

Sub-systems and projection

We introduce the definition of a sub-system involved in a given system. This intuitively allows us to characterize the set of all basic sub-systems from which the global system can be built. -if op =←֓ I (op ′ ), then Sub(S ) = {S} ∪ Sub(op ′ (C 1 , . . . , C n )).

For any finite trace tr of a finite computation tree of S and a sub-system sys of S, we characterize the set of finite traces tr ↓ sys of sys involved in tr. -if op = , then tr ↓ sub = {tr};

-if op = op 1 ⊗ op 2 with op 1 and op 2 of arity n 1 and n 2 respectively (i.e. n = n 1 + n 2 ), then 5 :

tr ↓ sub =             
is the projection of i

System-based test purposes

In this subsection, we adapt the notion of test purpose presented in Chapter VII, Section 3 to test, from a global behaviour of a system, the behaviour of its involved sub-systems and then we guide the component testing intelligently by taking into account the way components are used in systems. Thus, taking a behaviour p of a system S, we intend to define test purposes that are able to test the behaviour p i of each sub-system S i ∈ Sub(S ). We identify therefore for each sub-system all its finite paths that are involved in constructing the whole behaviour of S.

We first define the finite computation tree of a subsystem sub of a global system S which captures all its finite traces: Definition 2.3 (Finite computation tree) Let S be a system over T(Out × ) In . Let sub ∈ Sub(S ) be a subsystem of S over T(Out ′ × ) In ′ . The finite computation tree of sub generated by S of depth less than n, noted FCT(sub, n) is the coalgebra (S FCT , s 0 FCT , α FCT ) defined by: -s 0 FCT = -S FCT is the whole set of finite traces defined as follows:

-s 0 = { } -∀j, 1 ≤ j ≤ n, s j = {tr ′ . i|o | ∃tr ′ ∈ s j-1 , ∃i ∈ In ′ , ∃o ∈ Out ′ , ∃tr ∈ Trace(S ) such that tr ′ . i|o ∈ tr ↓ sub } 5. a | i is the projection of the n-tuple a on i th argument.

Hence, S FCT = 0≤j≤n s i α FCT : S FCT × In ′ -→ T(Out ′ × S FCT ) is the mapping which for every i 0 |o 0 , . In this definition, S FCT is the set of the nodes of the tree. s 0 FCT is the root of the tree. Each node is represented by the unique finite trace i 0 |o 0 , . . . , i m |o m (m ≤ n). α FCT gives, for each node p and for each input i, the set of nodes Π that can be reached from p when the input i is submitted to the component. Let S be a system over a signature H = T(Out × ) In . Let sub ∈ Sub(S ) be a sub-system of S over H ′ = T(Out ′ × ) In ′ and FCT(sub, n) = (S, s 0 , α) its finite computation tree generated by S. Let tr be a finite trace of S such that its length is less than n. Let tr ↓ sub be the projection of tr on sub. A test purpose TP for tr and sub is a mapping TP : S FCT -→ {accept, skip, ⊙} such that:

-for every node p = i 0 |o 0 , . . . , i m |o m ∈ tr ↓ sub , TP(p) = accept; -if TP( i 0 |o 0 , . . . , i m |o m ) = accept, then: ∀j, 0 ≤ j ≤ m, TP( i 0 |o 0 , . . . , i j-1 |o j-1 ) = skip -TP( ) = skip -if TP( i 0 |o 0 , . . . , i k |o k ) = ⊙, then: TP(i 0 |o 0 , . In order to build a test purpose for a finite behaviour projection tr ↓ sub on a sub-system sub, we identify all finite paths of its finite computation tree FCT whose traces embody tr ↓ sub and we tag them with accept. We then tag every node which represents a prefix of an accepted behaviour with skip. The other nodes, which lead to behaviours that we do not want to test, are tagged with ⊙. This corresponds intuitively to three requests for making coffee to the component drink D without any error occurring. A test purpose TP for this behaviour would then concentrate on the delivering of coffee and ignore the behaviours of D related both to errors when D fails and to tea delivering. Hence, each state of FCT(D, 6) reachable after tr ↓ D is tagged with accept. Then, p 15 is only tagged with accept because it is the unique leaf which corresponds to an expected behaviour. All nodes leading from the root p 0 to this node p 15 are tagged with skip (i.e p 0 , p 1 , p 3 , p 5 , p 8 and p 11 ). Finally, all other states are tagged with ⊙. Thus, testing of D is re-enforced as far as the coffee delivering is concerned: only behaviours related to correct coffee delivering process are chosen and then sub-system behaviours that are not activated in the global system are not tested. This allows us to restrict the test domain to the one under consideration.

Related works

In this section, we present a brief overview of contributions which are technically close to our proposal, but which focus on various aspects of compositional testing, as well as on componentbased ones. We discuss the differences between problematics addressed by those contributions and those addressed by our approach.

The component-based systems testing framework proposed in [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF] is closer technically to our compositional testing approach. In this paper, the authors address compositionality for ioco conformance relation. Both specification and implementation component models are considered as LTSs. Parallel composition and hiding operators are used to combine LTS models. The parallel composition of two LTSs S 1 and S 2 consists in synchronizing their actions: when both S 1 and S 2 are ready to engage in the same action a, there is a transition in the composed LTS which carries the action a; when one of them is ready to engage in an action not shared with the other one, it may evolve independently and the reaction of the composed LTS consists only of the reaction of the LTS that reacts. The hiding operator consists in hiding the common or synchronized actions by replacing them by an internal action τ, and then restricting observability of internal actions. It has been proved that the conformance testing ioco is only compositional with respect to parallel composition and hiding when specifications and implementations are assumed input-enabled.

Among the works concerning compositional testing as it was defined in [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF] and which were adopted in our framework, we can mention the work proposed by Sampaio in [START_REF] Sampaio | Compositional verification of input-output conformance via csp refinement checking[END_REF]. In this paper the authors extend the testing theory defined in the setting of CSP process algebra whose conformance relation cspio is an adapted version of ioco to CSP formalism [START_REF] Nogueira | Guided Test Generation from CSP Models[END_REF], to be able to address compositional testing proposed by Tretmans in [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF]. Indeed, it has been shown that cspio is compositional not only for parallel composition and hiding operator / but also for other CSP's composition operators such that deterministic and nondeterministic choices, by assuming that input completeness of the specification is in the same alphabet of the implementation. In [START_REF] Faivre | Symbolic model based testing for component oriented systems[END_REF], the authors propose to test each component of a system in isolation by generating accurate test purposes for them from the global specification of the system and assuming that the specification of every component in the system is available. They use the input-output symbolic transition systems (IOSTS) as the behavioural model of components and both synchronized product and hiding operator in order to compose components. Then, the authors propose to derive test purposes for a given component C of the system S from a global behaviour of S. This is done by defining an adequate projection mechanism that allows them to project symbolic behaviour of S on its components. Those projected behaviours are then considered good behaviours to be tested on sub-systems. Thus, they are used to build test purposes.

In [START_REF] Yevtushenko | Sequential synthesis by language equation solving[END_REF][START_REF] Petrenko | Solving asynchronous equations[END_REF], Petrenko and al. see the compositional testing problem differently from our approach and those presented in [START_REF] Van Der Bijl | Compositional testing with ioco[END_REF][START_REF] Sampaio | Compositional verification of input-output conformance via csp refinement checking[END_REF]. They address the following question: "how to design a component that when combined with a known part of the system, called the context, has to satisfy a given overall specification?" To answer this question, the authors of [START_REF] Yevtushenko | Sequential synthesis by language equation solving[END_REF][START_REF] Petrenko | Solving asynchronous equations[END_REF] specify the behaviour of components as finite state machines and the interactions between components by means of two operators: synchronous composition and parallel composition (or asynchronous composition). Then, they associate a class of languages to finite state machines that allow them to define equations over languages. Such a behaviour modeling is made to be the cornerstone of testing complex systems in context. In this setting, the above question is expressed formally by the following equation over FSM languages (C op X) rel spec where C models the context, spec models the global specification, X is unknown, op stands for a composition operator and rel for a conformance relation. It has been proved that the largest solution of this language equation is given by the language S = C op spec when op stands for both parallel composition or synchronous composition and rel stands for languages inclusion ⊆. As previously mentioned, finite state machines and operators used to compose them can be defined in our framework. Then, to extend their results to our framework, it still need to define a class of languages accepted by Barbosa's components. To do that, we can take advantage of the work done in [START_REF] Bonsangue | A kleene theorem for polynomial coalgebras[END_REF] that generalize the classical notion of regular expression to coalgebras over polynomial functors.

In [START_REF] Briones | Assume-guarantee reasoning with ioco testing relation[END_REF], the authors extend the so-called assume-guarantee reasoning [START_REF] Clarke | Compositional model checking[END_REF] used in model checking areas as a means to cope with the state explosion problem of compositional testing. They then proposed to test each component of a system separately, while taking into account assumptions about the context of the component. They use the input-output labeled transition systems as behavioural models of components and the parallel composition to compose components. The conformance relation used in this approach is the ioco relation. The underlying idea behind this approach is to check that, given a assumption A about the environment in which the components are supposed to operate, such that iut 2 ioco A and (iut 1 A) ioco spec then (iut 1 iut 2 ) ioco spec. The authors showed that this property holds if the assumption A is input-enabled. This approach then requires the specification spec to be given as a single model rather than a set of components unlike our approach. They do not impose input-completeness of specifications which gives them an advantage with respect to our result.

engineering, that has been fully tried and tested in the modeling of modern industrial systems, but has not been well-formalized. This will first require that we extend the formalism to take into account components heterogeneity (software, hardware, human) which is mainly characterized by how inputs are handled to provide observable outputs (i.e. discretely or continuously). In the context of B. Golden's thesis [START_REF] Aiguier | Modeling of complex systems: A minimalist and unified semantics for heterogeneous integrated systems[END_REF], he defines a formalism which is abstract enough to unify, by using non-standard analysis techniques, different time treatments of components. On the contrary, systems considered in [START_REF] Aiguier | Modeling of complex systems: A minimalist and unified semantics for heterogeneous integrated systems[END_REF] are deterministic. The idea is then to try to combine our approach with that of [START_REF] Aiguier | Modeling of complex systems: A minimalist and unified semantics for heterogeneous integrated systems[END_REF].

-In systems engineering, mainly two kinds of operators play a crucial role in defining systems:

1. Integration operators 2. Abstraction/simulation operators.

The first kind of operators has been widely discussed in this thesis, but not the second.

Both abstraction and simulation operators aim to structure systems at many levels of description, from the most abstract to the most concrete until realization. These operators are classically brought together into only one which is similar to the operator of refinement classically used in software engineering [START_REF] Goguen | Institutions: abstract model theory for specification and programming[END_REF][START_REF] Hoare | Proof of correctness of data representations[END_REF].

-It would be interesting to take data and not just values In and Out, into account. In order to do that, we first have to extend the signature over which components are defined by data. This would be done by replacing both inputs In and outputs Out sets with data structure specified using equational and algebraic specifications. This would lead us to extend our algorithms for test case generation. This extension will naturally be based on symbolic evaluation techniques as it has been done in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF]. This will also require us to first extend our conformance relation cioco to sicoco [START_REF] Frantzen | A Symbolic Framework for Model-Based Testing[END_REF].

-It would be interesting to address compositional verification in our framework. In order to do that, we would first have to define a logic (temporal) under our formalism, and then establish a certain number of properties on this logic such as defining a calculus and proving that it is correct and complete, showing that the logic is stable with respect to bisimulation, studying preservation of properties along integration operators, etc.

keywords:

  Component-based system, Integration operators, Trace semantics, Transfer function, Compositional testing, Conformance testing, Coalgebra, Monad, Testing in context.

2 .

 2 The need of a generic formal description of component 3. Why use Barbosa's component definition based on coalgebras and monads?

Figure I. 3 -

 3 Figure I.3 -Classification of testing techniques

1 (

 1 Category) A category C consists of: -A collection Obj(C) of objects; -For each pair of objects A, B ∈ Obj(C), a collection Hom(A, B) of arrows (or morphisms or also maps) f : A -→ B from A to B; -A is the domain and B is the codomain of f : A -→ B; -For each object A ∈ Obj(C), an identity arrow id A : A -→ A; -For each pair of arrows f : A -→ B and g : B -→ C, a composite arrow g • f : A -→ C.

Definition 1 . 2 (

 12 Subcategory) Let C and D be two categories. We say that C is a subcategory of D if: -All the objects of C are objects of D: Obj(C) ⊆ Obj(D); -All the arrows of C are arrows of D: for each pair of objects A, B ∈ Obj(C), Hom C (A, B) ⊆ Hom D (A, B); -If A is an object of C then its identity id A in C is in D: for each object A ∈ C, id C A = id D A ; -If f : A -→ B and g : B -→ C in C, then the composite in C f • g is in D and is the composite in

Definition 2 . 1 (

 21 Category diagram) A diagram of a category C is an oriented graph G = (V, E) where:-V ⊆ Obj(C) and V has a finite cardinality; -E is a set of directed edges. The edges of an objectX to an object Y are arrows from X to Y and are finite in number.

Definition 2 . 2 (

 22 Commutative diagram) Let C be a category and G = (V, E) be a diagram in C.

Definition 2 . 5 (

 25 Coproduct) Let C be a category. The coproduct of two objects X and Y of Obj(C) is a new object X + Y ∈ Obj(C) with two coprojection morphisms κ 1 : X -→ X + Y and κ 2 : Y -→ X + Y which are universal: for each pair of arrows f : X -→ Z and g : Y

Definition 3 . 1 (

 31 Functor) Let C and D be two categories. A functor F : C -→ D consists of: -A function F o : Obj(C) -→ Obj(D), called object function, that associates to every object X ∈ Obj(C), an object F o (X) ∈ Obj(D) and -A family of functions F X,Y : Hom(X, Y) -→ Hom(F o (X), F o (Y)) indexed by couples (X, Y) of objects in Obj(C). F X,Y is called arrow function and associates to every arrow f : X

Definition 3 . 4 (

 34 Natural transformation) Let C, D be two categories. Let F, G : C -→ D be two parallel functors between C and D. A natural transformation from F to G is a C-object indexed family of morphisms in D τ = (τ X ) X∈obj(C) : F =⇒ G such that:

Definition 4 . 1 (

 41 Monad) Let C be a category. A monad in C consists of an endofunctor T : C -→ C equipped with two natural transformations η : 1 =⇒ T and µ : T • T =⇒ T (with 1 : C -→ C is the identity functor) which satisfy the conditions µ • Tη = µ • ηT = 1 and µ • Tµ = µ • µT:

Definition 4 . 3 (

 43 Kleisli category) Given a Kleisli triple (T, η, * ) over C. The category of Kleisli Kl T (C) is defined as follows:

Theorm 4 . 3 (

 43 Lambek [70]) Let F be a functor. If F admits a final coalgebra π : Γ

Theorm 4 . 4

 44 Each finite Kripke polynomial functor Set -→ Set has a final coalgebra.

Definition 4 . 4 (

 44 Derivative function) Let F : In ω -→ Out ω be a transfer function. We define:1. the initial output on input i ∈ In by F [i] = F (i.σ)(0) and 2. the derivative function on input i ∈ In by F

2 -

 2 Figure III.2 -Example of a synchronization tree

Example 5 . 2 (

 52 Proof by coinduction) Let us consider a property of the function merge that is: for any sequence σ ∈ A N , merge((odd(σ), even(σ))) = σ and then prove it by conduction. For this, we first coinductively define two functions: odd : A N -→ A N and even : A N -→ A N . The first one, maps each sequence σ ∈ A N to a new sequence odd(σ) containing only elements of σ at odd positions and the second one maps each sequence to a new sequence even(σ) containing only elements of σ at even positions. Similarly to merge, we define two coalgebras

Example 5 . 4

 54 Let a N and b N be two concrete infinite streams and let us show that merge(a N , b N ) = (ab)N . For this, we first define a relation R ⊆ A N × A N containing the following pairs:

Definition 1 . 1 (

 11 Components) Let In and Out be two sets denoting, respectively, the input and output domains. Let T be a monad. A component C is a coalgebra (S, init, α) for the signature H = T(Out ×) In : Set -→ Set where init ∈ S is a distinguished element denoting the initial state of the component C.When the initial state init is removed, C is called a pre-component.

Example 1 . 1 (

 11 Coffee machine) We consider a simple example of a coffee machine M modeled by the transition diagram shown in Figure IV.1.

Figure

  Figure IV.1 -Coffee machine

Figure

  Figure IV.2 -ATM component

  .

4

 4

  .

Figure IV. 4 -

 4 Figure IV.4 -Pedestrian crossing modeling

-→

  Figure IV.5 -Transformation of an IOLTS into a component over P (Out × _) In

Definition 2 . 1 (Definition 2 . 2 (

 2122 Dataflow) A dataflow over a set of values A is a mapping σ : ω → A. The set of all dataflows over A is noted A ω . Derivative dataflow) Let σ be a dataflow over a set A. The dataflow σ ′ derivative of σ is defined by:

Definition 2 . 5 (Definition 2 . 6

 2526 Component finite traces) Let F ∈ beh C (init) be a trace of a component C. Let n ∈ N. The finite trace, noted F | n , of length n associated to F is the whole set of the finite sequence i 0 |o 0 , . . . , i n |o n such that there exists x ∈ In ω where for every j, 0 ≤ j ≤ n:-x(j) = i j -and F (x(j)) = o j Hence, Trace(C) = F ∈beh C (init) n∈NF | n defines the whole set of finite traces over C. Taking advantage of having generically defined components, and having shown that most state-based formalisms are instances of Definition 1.1, by Definition 2.4, we can associate to them semantics from causal functions. We have formally presented in Section 1.2 the mapping φ : IOLT S(Σ) -→ Comp(H) that defines how an IOLTS can be transformed in our framework (see Definition 1.3). Similarly, we define another transformation φ t allowing us to make the link between the set of traces of an IOLTS model M and its associated component φ(M) in our framework. Let M ∈ IOLT S(Σ τ ) be an IOLTS and tr ∈ Trace(M). Let φ(M) ∈ Comp(H) be its associated component. The transformation of Trace(M) into Trace(φ(M)) is the function:

Corollary 2 . 1

 21 For any IOLTS M, φ t (M) is bijective, i.e. Trace(φ(M)) = φ t (Trace(M)).

Theorm 3 . 1

 31 Let H = T(Out × ) In be a signature such that for every pre-component C = (S, α) over H, and for every s ∈ S, |beh C (s)| ≤ κ. Then, the coalgebra (Γ, π) is final in PComp(H).

Definition 3 . 1 (

 31 Component generated by F) Let (Γ, π) be the final model over H = T(Out × ) In . Let F ∈ Γ. The component F generated by F in (Γ, π) is the component ( F , F, α F ) defined as follows:

  and F ∈ G}, for x ∈ In ω chosen arbitrarily It is easy to notice that both components C = (S, init, α) and beh C (init) share the same trace semantics i.e. Trace(C) = Trace( beh C (init) )) = beh C (init). (see Definition 2.4).

Example 3 . 1 (

 31 Minimal component) For a better understanding of the definition of a minimal component, we consider an example of binary Mealy machine M modeled by the transition diagram shown on Figure IV.

Figure V. 2 -

 2 Figure V.2 -Illustration of a system with feedback

Figure V. 3 -

 3 Figure V.3 -Relaxed feedback composite: ←֓ I (C)

-

  For identities, let C ∈ Comp(H), ←֓ I (C) = F , and let us prove by induction on the structure of F that ←֓ I (id C ) = id ←֓ I (C) . Basic Step: By definition of ←֓ I (id C ), one has ←֓ I (id C )(F) = F = id ←֓ I (C) (F) -Induction Step: let G ′ ∈ F j+1 . We know by definition of G ′ that there exists G ∈ F j , i ∈ In and o ∈ Out such that o ∈ F ∈G (F (i.x)(0)) and G ′ = {F (i.x) ′ | F (i.x)(0) = o and F ∈ G} for x ∈ In ω chosen arbitrarily. Then, by definition of ←֓ I (id C ) one has:

Figure V. 4 -

 4 Figure V.4 -Syracuse's sequence component

2 Figure V. 5 -

 25 Figure V.5 -Examples of feedback composition

Proposition 1 . 2 IExample 1 . 3

 1213 : Comp(H) -→ Comp(H ′ ) is a partial functor only defined for component C whose the synchronous feedback composition over I is well-formed.ProofThe proof is noticeably similar to the proof given for ←֓ I . End Consider again the component C 1 shown in Figure V.5a and let us built the composite component that hides the feedback, as suggested by the last definition. We then choose the component f : In × Out -→ In as the "and" operator, π i and π o as the identities on In and Out respectively.

Figure V. 9 - 1 1 1 ⊛ C 2 2 2 C 1 ∪ 2 Out 1 × 2 Figure V. 10 -

 9111222121210 Figure V.9 -Example: illustration of ⊗ e

  Figure V.16 -Example: illustration of ⊕ e

Example 3 . 1 (

 31 Encoder/decoder) An encoder/decoder is usually used to guarantee certain characteristics (for example, error detection) when transmitting data across a link. A simple example of such an encoder/decoder is represented in Figure V.17. It consists of two parts:

Figure V. 18 -

 18 Figure V.18 -Controller system C

Figure V. 19 -

 19 Figure V.19 -Gate system G

closed 1 ,

 1 Figure V.20 illustrates graphically the component B.

opened 2 )Figure V. 21 -

 221 Figure V.20 -Synchronous product B = ⊛(G 1 , G 2 ) of G 1 and G 2

  Figure V.22 illustrates the component S.

Figure V. 22 -

 22 Figure V.22 -Sequential composition S = ⊲ s (C, K) of C and K

Figure V. 23 -

 23 Figure V.23 -Model of a crosswalk, to be composed in a synchronous parallel composition with the traffic light model of Figure IV.4

Figure V. 24 -

 24 Figure V.24 -Pedestrian crossing modeling

Figure V. 25 -

 25 Figure V.25 -⊙(M ′ , M)

  Figure V.26 illustrates a typical view of these elements.

Figure V. 27 -

 27 Figure V.27 -Controller system C

Figure V. 28 -

 28 Figure V.28 illustrates graphically the behaviour of B.

Figure V. 29 -

 29 Figure V.29 -Crossing level global model S

1. 1 Figure VI. 1 -

 11 Figure VI.1 -Conformance testing process

Figure VI. 2 -

 2 Figure VI.2 -Relations between IMPS, MODS and SPECS

Definition 1 . 1 (

 11 Specification model) A specification of a system S is modeled as a component spec = (S, init, α) over a signature T(Out × ) In .

Definition 1 . 3 (Example 1 . 1

 1311 Out after (tr, i)) Let C be a component over T(Out × ) In . Let tr be a finite trace of C and i ∈ In. The set of the possible outputs for input i after executing tr on C is: Out(C after (tr, i)) = {o | tr. i|o ∈ Trace(C)} Hence, the relation cioco is formally redefined in terms of coalgebras as follows: Definition 1.4 (cioco) Let spec be the component over the signature T(Out × ) In and iut be the component over T(Out ′ × ) In ′ such that iut satisfies the assumptions stated in Definition 1.2. cioco is defined as follows: iut cioco spec ⇐⇒ ∀tr ∈ Trace(spec), ∀i ∈ In, Out(iut after (tr, i)) ⊆ Out(spec after (tr, i)) Consider the specification spec of the coffee machine illustrated in Figure IV.1 and three implementations under test iut 1 , iut 2 and iut 3 depicted in Figure VII.1a, Figure VII.1b and Figure VII.1c respectively. Then, one has:

Proposition 1 . 1

 11 Figure VII.1 -Illustration of cioco

i 4 |o 5 Figure VII. 2 -

 52 Figure VII.2 -Counter example for quasi-reduction

Example 2 . 1

 21 Figure VII.3 gives the finite computation tree of depth 4 of the coffee machine M whose specification is shown in Figure IV.1.

Figure VII. 3 -

 3 Figure VII.3 -Finite computation tree for the coffee machine

3 Figure VII. 4 -

 34 Figure VII.4 -Example of finite computation tree

Definition 3 . 1 (

 31 Test Purpose) Let FCT(C, n) be the finite computation tree of depth n associated to a component C. A test purpose TP for C is a mapping TP : S FCT -→ {accept, skip, ⊙} such that:

Example 3 . 1

 31 From the finite computation tree FCT(M, 4) shown in Figure VII.3, one defines three test purposes:

  Figure VII.5 -Test purposes of the coffee machine

Rule 1 Rule 2 Rule 3 Rule 4 Rule 5

 12345 Figure VII.7 -Communication between the iut and the algorithm

CS 2 coin|abs rule 1 CS 3 = {p 6 } coffee|refund rule 3

 133 InconcThe verdict Inconc is due to the following two equalities:-Next(CS 3 , coffee|refund) = {p 11 } = ∅ -NextPass(CS 3 , coffee|refund) = NextSkip(CS3 , coffee|refund) = ∅ Pass To get the verdict Pass, we consider the following trace: [coin|abs, coffee|served, coin|abs, coffee|served Pass]

  Next(CS 2 , coin|abs) = {p 6 } = ∅ -NextPass(CS 2 , coin|abs) = NextSkip(CS 3 , coin|abs) = ∅ Pass To get the verdict Pass, we consider the following trace: [coin|abs, coffee|served, repair|abs Pass]

Figure VIII. 1 Figure VIII. 1 -

 11 Figure VIII.1 illustrates the architecture of these two components.

  Figure VIII.2 -Illustration of cioco's compositionality

  Now, we have tr = (i1 , i ′ 1 )|(o 1 , o ′ 1 ), . . . , (i n , i ′ n )|(o n , o ′ n ) ∈ Trace(⊗((iut 1 , iut 2 ))).According to the cartesian product definition, it is easy to show that the two traces:tr 1 = i 1 |o 1 , .. . , i n |o n ∈ Trace(iut 1 ) and tr 2 = i ′ 1 |o ′ 1 , . . . , i ′ n |o ′ n ∈ Trace(iut 2 )

1 s 2 o 1 |o 3 o 2 |o 4 o 1 |o 3 o 1 |o 5 o 2 |o 4 (b) iut 2 cioco spec 2 Figure VIII. 3 -

 12343423 Figure VIII.3 -Counterexample of compositionality

C 1 2 )Lemma 1 . 1 Proof 1 .

 12111 cioco C 2 =⇒ ←֓ I (C 1 ) cioco ←֓ I (C 2 ) (VIII.1) C 1 cioco C 2 =⇒ I (C 1 ) cioco I (C 2 ) (VIII.Proof We first need to prove the following lemma: Consider two components C 1 and C 2 , then we have:1. Trace(C 1 ) ⊆ Trace(C 2 ) implies (C 1 cioco C 2 ) 2. If C 2 is input-enabled, then (C 1 cioco C 2 ) implies Trace(C 1 ) ⊆ Trace(C 2 ). Let tr = i 1 |o 1 , .

2 .--

 2 By induction on the structure of a trace tr of C 1 . Let tr = i 1 |o 1 , . . . , i n |o n ∈ Trace(C 1 ). Basic Step: tr = is empty trace. tr = ∈ Trace(C 2 ) trivially holds. Induction Step: Let us write tr as concatenation of two finite traces as follows: tr = i 1 |o 1 , i 2 |o 2 , .

Trace(C 1 )--

 1 ⊆ Trace(C 2 ) =⇒ Trace( I (C 1 )) ⊆ Trace( I (C 2 ))For this, let us use the proof by induction on the length of a finite trace tr of Trace( I (C 1 )).Let tr = i 0 |o 0 , . . . , i n |o n be a finite trace of I (C 1 ). Basic Step: tr = is empty trace. tr = ∈ Trace( I (C 2 )) trivially holds. Induction Step: Let us write tr as concatenation of two finite traces as follows: tr = i 0 |o 0 , i 1 |o 1 , . . . , i n-1 |o n-1 • i n |o n tr ∈ Trace( I (C 1 )) implies, according to the synchronous feedback definition (see Chapter V, Definition 1.

Definition 2 . 1 (

 21 Sub-systems) Let S = op(C 1 , . . . , C n ) be a system over a signature H. The set of sub-systems of S, noted Sub(S ), is inductively defined on the structure of op as follows:-if op = , then Sub(S ) = {S};-if op = op 1 ⊗ op 2 withop 1 and op 2 of arity n 1 and n 2 respectively (i.e. n = n 1 + n 2 ), then Sub(S ) = {S} ∪ Sub(op 1 (C 1 , . . . , C n 1 )) ∪ Sub(op 2 (C n 1 +1 , . . . , C n )); -if op = I (op ′ ), then Sub(S ) = {S} ∪ Sub(op ′ (C 1 , . . . , C n ));

Definition 2 . 2 (

 22 Projection of a finite trace) Let S = op(C 1 , . . . , C n ) be a system over a signature H = T(Out × ) In . Let sub ∈ Sub(S ) be a sub-system of S over H ′ = T(Out ′ × ) In ′ . Let tr = i 1 |o 1 , i 2 |o 2 , . . . , i m |o m ∈ Trace(S ). The projection of tr on sub, denoted by tr ↓ sub , is the subset of Trace(sub) inductively defined as follows:

i 0

 0 |o 0 , . . . , i 1m |o 1m i 0 |o 0 , . . . , i m ′ m |o m ′ m i 0 |o 0 , . . . , i km |o km i 0 |o 0 , . . . , i k ′ m ′ |o k ′ m ′ . . . i 0 |o 0 i k |o k i 1m |o 1m i km |o km i m ′ m |o m ′ m i k ′ m ′ |o k ′ m ′ Definition 2.4 (Test Purpose)

Example 2 . 1

 21 Let us consider a finite trace tr = coinC|preparing, abs|coffee, coinC|preparing, abs|coffee, coinC|preparing, abs|coffee of the coffee machine obtained by a synchronous parallel composition of the money component M and the drink component D whose specifications are illustrated in Figure VIII.2a and Figure VIII.2b respectively, and then, from it, build a test purpose dedicated to test the behaviour of the drink component D.

First, we build

  the finite computation FCT(D, 6) tree of D generated by ⊙(spec M , spec D ) that we represent in Figure VIII.4. Second, we compute the projection of tr on D tr ↓ D = { makeC|preparing, abs|coffee, makeC|preparing, abs|coffee, makeC|preparing, abs|coffee }

Figure VIII. 4 -

 4 Figure VIII.4 -Test purpose of the drink component

accessibilité du code

  la littérature, on trouve une multitude de techniques de test qui différent principalement selon les trois critères suivants: : deux techniques de test sont généralement distinguées. Dans le test structurel (appelé aussi test boîte blanche) [23], la structure interne du système est connue. Le testeur a le droit d'accéder à des informations comme la structure de code, les valeurs possibles de certaines variables du programme, etc. Dans le test fonctionnel (appelé aussi test boîte noire) [26], la structure interne du système sous test est cachée. Le testeur ne dispose pas du code source du système sous test. Il ne peut accéder qu'aux descriptions des fonctionnalités du système. 2. niveau d'abstraction : trois méthodes de test sont communément distinguées. Pour le test unitaire, les systèmes examinés ne peuvent pas être subdivisés en d'autres sous-systèmes. Pour le test d'intégration, un système construit comme une combinaison d'un ensemble de sous-systèmes (or composants) est examiné. Pour le test du système, le système complet est testé.

	1. niveau d'
	niveau de détails
	système
	intégration
	unitaire
	fonctionnalité	boîte blanche boîte noire	accessibilité
	robustesse
	sécurité
	caractéristiques
	FIGURE 3 -Classification des techniques de test

2 Universal properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  . . Category definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constructions of categories . . . . . . . . . . . . . . . . . . . . . . . . . . Properties of arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commutative diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initial and terminal objects . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Product . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 2.4 Coproduct .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Exponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	1.1
	1.2
	1.3
	2.1
	2.2

3 Functors and natural Transformations . . . . . . . . . . . . . . . . . . . . . . . .

  Functors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Natural transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heterogeneous Compositions . . . . . . . . . . . . . . . . . . . . . . . . .

	3.1
	3.2
	3.3

4 Monads in category theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Definition

  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . More examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Category of Kleisli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	4.2 A working example 4.3
	4.4

Example 1.2

  TableII.1 shows some mathematical structures that can be perceived as special types of examples of categories. All of these examples are categories whose objects are sets with particular mathematical structure and whose arrows are functions preserving that structure, so-called morphisms.

	Category Objects	Arrows
	Set	sets	applications
	Poset	ordered sets	monotone applications
	Grp	groups	homomorphisms
	Top	topological spaces continuous applications
	Vect k	vectorial K-spaces linear applications
		Table II.1 -Examples of categories
	A category is small if its objects and arrows constitute sets; otherwise it is large.

  Set is bijective if for every element y ∈ Y, there is exactly one element x ∈ X such that f (x) = y. Alternatively, a function f is bijective if and only if there exists function f -1

2 Initial and terminal objects Definition 2.3 (Initial et terminal objects) Let C be

  a category. An object I of C is called initial if there is exactly one arrow I -→ X for each object X of C. An object T of C is called terminal if there is exactly one arrow X -→ T for each object X of C. An object that is both initial and terminal is called a zero.

	Proposition 2.1
	1. If a category has an initial object, it is unique up to isomorphism.
	2. If a category has a terminal object, it is unique up to isomorphism.

5 Exponents Definition 2.6 (

  Exponent) Let C be a category with products ×. The exponent 2 of two objects X, Y ∈

	Obj(C) is a new object Y X ∈ Obj(C) with an evaluation morphism:
	ev : Y X × X -→ Y
	such that: for each morphism (sometimes called currying)

. . , x n } This operation is indeed natural because the following diagram commutes for any function f : X

  {{{x 11 },...{x 1j },...}, {{x 21 },...{x 2j },...}, ... ... } {{x 11 },...{x 1j },..., {x 21 },...{x 2j }, ...

			{x 1i ,x 1j ,...,x 2i ,x 2j ,...}
	...	...	}

  . . , i n ) ∈ In + the same sequence of outputs (o 1 , o 2 , . . . , o n ) that is obtained by the function φ when the input sequence

  is the set all languages over the alphabet A, and o L , d L is the cartesian product of o L and d L that are defined for a ∈ A and L ∈ L by:

  : {s 0 , s 1 , s 2 , s 3 , s 4 } × {amount, check, sold, screen, cash, τ} -→ {abs} × {s 0 , s 1 , s 2 , s 3 , s 4 }

1

as a component M = (S, init, α) over the signature (Out × ) In . The state space is S = {s 0 , s 1 , s 2 , s 3 , s 4 } and init = s 0 . The sets of inputs and outputs are In = {amount, check, sold, screen, cash, τ} and Out = {abs} respectively. Finally, the transition function: α is defined as follows:

  .1, Table IV.2 and Table IV.

Table IV .

 IV 1 suggests a possible 2 taxonomy of coalgebras that can be obtained when T is the identity functor id.

	How to model it	Resulting component	Typical example
	In	Out
	{}	{abs}	X -→ X	run forever
	{}	set of actions Act	X -→ X × Act	infinite streams
	set of inputs I	{abs}	X -→ X I	systems with input
	set of inputs I	set of outputs O	X -→ (X × O) I	Mealy machines
	Table IV.1 -The deterministic computational features

Table IV .

 IV 2 suggests a possible taxonomy of coalgebras that can be obtained when T is the partial functor (id + 1).

	How to model it	Resulting component	Typical example
	In		Out
	{}		{abs}	X -→ X + 1	systems with interruption run
	{}		set of actions Act X -→ (X × Act) + 1	finite streams
	set of actions Act	{abs}	X -→ X Act + 1	systems with input
	set of inputs I	set of outputs O
	How to model it	Resulting component	Typical example
	In		Out
	{}		{abs}	X -→ P (X)
	{}	action set Act	X -→ P (Act × X)	LTS as in Milner's CSS
	action set Act		{abs}	X -→ P (X) Act	LTS as in process algebra
	input set I	output set O	X -→ P (O × X) I	extended Mealy machines

X -→ (X × O) I + 1 partial Mealy machines

Table IV.2 -The partial computational features

Table

IV

.3 suggests a possible taxonomy of coalgebras that can be obtained when T is the powerset functor P.

  The behaviour beh M (s 0 ) of the coffee machine M presented in Example 1.1 is defined by all the functions F σ : {coin, coffee, repair} ω -→ {abs, served, refund} (abs.served) n 1 .(abs.refund.abs) n ′ 1 . . . (abs.served) n i .(abs.refund.abs) n ′

	Example 2.2

ω where σ = n 1 .n ′ 1 .n 2 .n ′ 2 . . . n i .n ′ i • • • ∈ N ω defined by F σ : (coin.coffee) n 1 .(coin.coffee.repair) n ′ 1 . . . (coin.coffee) n i .(coin.coffee.repair) n ′ i . . . → i . . .

  6 -Binary Mealy automatonIt is not difficult to see that applying Definition 2.4 to the initial state s 0 leads to the minimal set of transfer functions beh M (s 0 ) = {F 1 } where F 1 : {0, 1} ω -→ {0, 1} ω is the transfer function of Example 2.1 i.e. the one defined for every σ ∈ {0, 1} ω and for every k ∈ ω by:

  Then, let us define ←֓ I ( f ) :←֓ I (C 1 ) -→←֓ I (C 2 ) where ←֓ I

	Proof It only remains for us to make a correspondence between homomorphisms in Comp(H) and
	homomorphisms in Comp(H

Proposition 1.1 ←֓ I : Comp(H) -→ Comp(H ′ ) is a functor. ′ ). Let f : C 1 -→ C 2 be an homomorphism in Comp(H).

  = ( f , π i , π o ) is the feedback interface defined for every (i, i ′ ) ∈ In 1 × In 2 and (o, o ′ ) ∈ Out 1 × Out 2 as follows:

	In 1	C 1	C 2	Out 2
		Figure V.6 -Sequential composition
	where I

8

. stutter indicates that no progress of the component execution is made.

  both op 1 and op 2 are defined for C 1 , C 2 , . . . , C n 1 and C n 1 +1 , . . . , C n respectively, then op1 ⊗ op 2 (C 1 , . . . , C n ) = op 1 (C 1 , . . . , C n 1 ) ⊗ op 2 (C n 1 +1 , . . . , C n ) is a system over H = T(∏ n i=1 O i × ) ∏ n i=1 I i and op 1 ⊗ op 2 is defined for (C 1 , . . . , C n ), else op 1 ⊗ op 2 is undefined for (C 1 , . . . , C n ); -if I (op)is a complex operator of arity n, then for every sequence (C 1 , . . . , C n ) of components in C, if op is defined for (C 1 , . . . , C n ) with S = op(C 1 , . . . , C n ) is over H, I is a feedback interface over H and the feedback composition of S is well-formed, then I (op)(C 1 , . . . , C n ) = I (S) is a system over H ′ and 10 I (op) is defined for (C 1 , . . . , C n ), else I (op) is undefined for (C 1 , . . . , C n ); -if ←֓ I (op) is a complex operator of arity n, then for every sequence (C 1 , . . . , C n ) of components in C, if op is defined for (C 1 , . . . , C n ) with S = op(C 1 , . . . , C n ) is over H and I is a feedback interface over H, then ←֓ I (op)(C 1 , . . . , C n ) =←֓ I (S) is a system over H ′ and 11 ←֓

I (op) is defined for (C 1 , . . . , C n ), else ←֓ I (op) is undefined for (C 1 , . . . , C n ).

From Proposition 1.1 and Proposition 1.2, it is not difficult to see that any complex operator op of arity n defines a partial functor from Comp(H 1

  Out ω be a transfer function over H and ←֓ I f (F ) : In ′ω -→ Out ′ω be the function defined in Definition 3.3. Let x ′ 1 , x ′ 2 ∈ In ′ω be two inputs dataflows for ←֓ I f (F ) and let us prove that if for every n, 0

))) otherwise Proposition 3.1 ←֓ I f (F ) : In ′ω -→ Out ′ω is a transfer function. Proof Let F : In ω -→

  Definition 3.4 (Well-formed feedback composition for transfer function) Let I = ( f , π i , π o ) be a feedback interface over a signature H. Let F : In ω -→ Out ω be a transfer function. The synchronous feedback composition of F over I is well-formed if, and only if

  TC, iut passes tc iut f ails TC = def ∃tc ∈ TC, iut f ails tc Definition 1.1 (Correctness and Completeness) Let iut ∈ IMPS be an implementation and spec ∈ SPECS be its specification. Let TC be a set of generated test cases. Then we have: -TC is correct if: ∀iut ∈ IMPS, iut imp spec =⇒ iut passes TC -TC is complete if: ∀iut ∈ IMPS, iut imp spec ⇐⇒ iut passes TC The following table describes the required elements for conformance testing: Table VI.1 -Conformance testing elements test is through sequences of simulations-observations. In other words, systems under test are considered as black boxes.

	Physic elements implementation	iut ∈ IMPS
		test case execution	exec(tc, iut)
	Formal elements specification	spec ∈ SPECS
		implementation model	m iut ∈ MODS
		implementation relation	imp ⊆ MODS × SPECS
		test case	tc ∈ TESTS
		observations	OBS
		execution model of test case obs : TESTS × MODS -→ P (OBS)
		verdict	verdict tc : OBS -→ {Fail, Pass}
	Assumptions	test hypothesis	m iut models iut
			obs(tc, m iut ) models exec(tc, iut)

  an input of φ(M 2 ) and o ∈ Out(φ(M 1 ) after (tr, i)) and let us prove that o ∈ Out(φ(M 2 ) after (tr, i)). o ∈ Out(φ(M 1 ) after (tr, i)) implies that tr. i|o ∈ Trace(φ(M 1 )). By Corollary 2.1 (in Chapter IV), we have that tr. i|o ∈ φ t (Trace(M 1 )). Then, ∃tr ′ .a ∈ Trace(M 1 ) | tr. i|o = φ t (tr ′ ).φ t (a) (VII.1) Similarly, tr ∈ Trace(φ(M 2 )) implies that tr ′ ∈ Trace(M 2 ). Since M 1 ioco M 2 , then a ∈ Out(M 2 after tr ′ ). That amounts to say tr ′ .a ∈ Trace(M 2 ). Thus, φ t (tr ′ .a) ∈ φ t (Trace(M 2 )). Hence, by Corollary 2.1 (in Chapter IV) and Equation VII.1, we can conclude that tr. i|o ∈ Trace(φ(M 2 )). Consequently, o ∈ Out(φ(M 2 ) after (tr, i)). ) cioco φ(M 2 )), tr ∈ Trace(M 2 ) and o ∈ Out(M 1 after tr) and let us prove that o ∈ Out(M 2 after tr). o ∈ Out(M 1 after tr) implies that tr.o ∈ Trace(M 1 ) and tr ∈ Trace(M 2 ). Then, φ t (tr).φ t (o) ∈ φ t (Trace(M 1 )) and φ t (tr) ∈ φ t (Trace(M 2 ). By Corollary 2.1 (in Chapter IV), we have then that φ t (tr). abs ? |o ∈ φ(Trace(M 1 )) and φ t (tr) ∈ Trace(φ(M 2 )). But we know by hypothesis that (φ(M 1 ) cioco φ(M 2 )), then o ∈ Out(φ(M 2 ) after (φ t (tr), abs ? )). That implies φ t (tr). abs ? |o ∈ Trace(φ(M 2 )). Then, by Corollary 2.1 (in Chapter IV) we have that φ t (tr). abs ? |o ∈ φ t (Trace(M 2 )). Hence, by applying φ -1 t , tr.o ∈ (Trace(M 2 )). Consequently, we have that o ∈ Out(M 2 after tr).

	⇐=
	Let (φ(M 1

  t. cioco. That is because, after the trace i 1 |o 1 , i 2 |o 3 , i 3 |o 4 , there exists an input i 4 such that Out(iut after ( i 1 |o 1 , i 2 |o 3 , i 3 |o 4 , i 4 ) = {o 6 } Out(spec after ( i 1 |o 1 , i 2 |o 3 , i 3 |o 4 , i 4 ) = {o 5 }.

	s 0		q 0
	i 1 |o 1		i 1 |o 1
	s 1		q 1
	i 2 |o 2	i 2 |o 3	i 2 |o 3
	s 2	s 3	q 2
	i 3 |o 4	i 3 |o 4	i 3 |o 4
	s 4	s 5	s 4
	i 4 |o 5	i 4 |o 6
	s 6	s 7	s 6
	spec		iut

  READY, FAILED), (coin, coffee) p 5 = (STDBY, READY, FAILED, STDBY), (coin, coffee, repair) p 6 = (STDBY, READY, STDBY, READY), (coin, coffee, coin) p 7 = (STDBY, READY, FAILED, STDBY), (coin, coffee, repair) p 8 = (STDBY, READY, FAILED, STDBY, READY), (coin, coffee, repair, coin) p 9 = (STDBY, READY, STDBY, READY, STDBY), (coin, coffee, coin, coffee) p 10 = (STDBY, READY, STDBY, READY, FAILED), (coin, coffee, coin, coffee)

			p 0
			coin|abs
			p 1
		coffee|served	coffee|served	coffee|refund
	p 2		p 3	p 4
	repair|abs		coin|abs		repair|abs
	p 5		p 6		p 7
	coin|abs	coffee|served	coffee|served	coffee|refund	coin|abs
	p 8	p 9	p 10	p 11	p 12
			p 0 = STDBY, ()
		p 1 = (STDBY, READY), coin
		p 2 = (STDBY, READY, FAILED), (coin, coffee)
		p 3 = (STDBY, READY, STDBY), (coin, coffee)
	p 4 = (STDBY, p 11 = (STDBY, READY, STDBY, READY, FAILED), (coin, coffee, coin, coffee)
	p 12 = (STDBY, READY, FAILED, STDBY, READY), (coin, coffee, repair, coin)

  R then Push(P, s ′ ); ModifyColor(LS, s ′ , G); Enumerate(C, (S ′ , nb ′ , α ′ ), s ′ , LS, HC, P); else Add(HC, (s ′ , nb ′ )); ′ , init ′ , α ′ ), HC) Enumerate runs in Θ(mN) while Unfolding in Θ(mNnb n ) with:-m is the number of states of the component to be unfolded; -N is the cardinality of the input set In; -nb is the number of circuits detected in C; -n is the number of passes of the algorithm through each circuit. = (S, init, α) over T(Out × ) In , a state s ∈ S and positive number n output: a finite tree FCT(C, n) containing all paths of C outgoing from s. Each one of these paths does not go through more n circuit ′ , α ′ ), HC ← Enumerate(C, (S ′ , α ′ ), s, LS, HC, P);if n == 1 then return (S ′ , init ′ , α ′ )) ′′ , init ′′ , α ′′ ) ← Unfolding(C, x, n -1); nb ← init ′′ ; S ′ ← S ′ ∪ S ′′ ;Let T(m) be the number of elementary operations 5 necessary to enumerate all elementary paths of a component C over T(Out × ) In whose state number is m. We can easily see that Enumerate satisfies the following recurrence:

	Enumerate:
	Algorithm 2: Unfolding(C, s, n)
	input : a component C initialization ;
	(S ′ , init ′ , α ′ ) ← CreateEmptyComponent();
	LS ← CreateEmptyListOfColoredStates();
	P ← CreateEmptyStack();
	HC ← CreateEmptyListOfStateState();
	Push(P, s);
	for state ∈ S do
	Add(LS, (state, W))
	nb ← GiveNumber(s);
	init ′ ← nb;
	Add(S ′ , nb);
	ModifyColor(LS, s, G);
	(S else
	for (x, nb) ∈ HC do
	Pop (P); ModifyColor(LS, s, R); α ′ (y)(i) i f (S α ′ (y)(i) → α ′′ (y)(i) otherwise	y ∈ S ′
	return ((S Proposition 2.1 Proof

  . . , s n , s ′ n+1 , . . . , s ′ m ), (i 0 , . . . , i n-1 , i ′ n , . . . , i ′ m-1 ) ) = ⊙ for all m > n and for all (s ′ j ) n<j≤m and (i ′ k ) n≤k<m

  . . ev n-1 ∈ Trace(FCT) and an input i ∈ In such that Out iut (iut after (tr, i)) Out FCT (FCT after (tr, i)) Out iut (iut after (tr, i n )); -o ′ n ∈ Out FCT (FCT after (tr, i n )).Since i n ∈ In, then there also exists an output o n such that o n ∈ Out FCT (FCT after (tr, i n )) i.e. ev 0 , . . . , ev n-1 , i n |o n ∈ Trace(FCT) (VII.4) Let us denote i n |o n by ev n and i n |o ′ n by ev ′ n . Now, let us denote by TP a test purpose of FCT such that there exists a state s ∈ S FTC such that s belongs to the set of reachable states from the initial state of FCT after executing the trace ev 0 . . . ev n-1 ev n on FCT, and TP(s) = accept i.e. ev 0 . . . ev n-1 ev n forms a path of TP. Let us prove that there exists [ev 0 . . . ev n-1 ev ′

	i.e. there exists an output o ′ n of iut such that -o ′ n ∈ That means:
	ev 0 , . . . , ev n-1 , i n |o ′ n ∈ Trace(iut)	(VII.2)
	and
	ev 0 , . . . , ev n-1 , i n |o ′ n ∈ Trace(FCT)	(VII.3)

n |Fail] ∈ st(TP, iut).

  Thus, what remains is to prove that there is a verdict state Fail such that Fail = α TS (S n )(ev n ). By Equation VII.3, ev 0 . . . ev ′ n ∈ Trace(FCT) and by Equation VII.2 ev 0 . . . ev n ∈ Trace(iut), hence Next(S n , ev ′

n ) = ∅, and consequently α TS (S n )(ev n ) = Fail. End

  . . , i n |o n be a finite trace of C 2 , i an input of C 2 and o ∈ Out(C 1 after (tr, i)) and let us prove that o ∈ Out(C 2 after (tr, i)). Out(C 1 after (tr, i)) implies tr ′ = tr. i|o = i 1 |o 1 , i 2 |o 2 , . . . , i n |o n , i|o ∈ Trace(C 1 ). Since Trace(C 1 ) ⊆ Trace(C 2 ), then tr ′ ∈ Trace(C 2 ). Thus, o ∈ Out(C 2 after (tr, i)), and consequently, Out(C 1 after (tr, i)) ⊆ Out(C 2 after (tr, i))

o ∈

prove the first point of Theorem 1.2.

  . . , i n-1 |o n-1 • i n |o n tr ∈ Trace(C 1 ) implies o n ∈ Out(C 1 after ( i 1 |o 1 , . . . , i n-1 |o n-1 , i n )). Since C 2 is inputenabled, i nis inevitably an input of C 2 at any state s. By induction hypothesis, we havei 1 |o 1 , . . . , i n-1 |o n-1 ∈ Trace(C 2 ) and o n ∈ Out(C 1 after ( i 1 |o 1 , . . . , i n-1 |o n-1 , i n )) then o n ∈ Out(C 2 after ( i 1 |o 1 , . . . , i n-1 |o n-1 , i n )) because C 1 cioco C 2 . Thus i 1 |o 1 , . . . , i n-1 |o n-1 , i n |o n ∈ Trace(C 2 ).Consequently, Trace(C 1 ) ⊆ Trace(C 2 ). According to Lemma 1.1, we have to prove: Trace(C 1 ) ⊆ Trace(C 2 ) =⇒ Trace(←֓ I (C 1 )) ⊆ Trace(←֓ I (C 2 ))

	End
	Let us now

prove the second point of Theorem 1.2.

  . . , s ′ n ) of S 2 as follows:-x′ (0) = x ′ (0) and y x′ (0)∈ η ′ Out×S 2 (α 2 (s ′ 0 )(x ′ (0))) | 1 -∀j, 0 < j ≤ n -1, x′ (j) = f (x ′ (j), y x′ (j -1)), y x′ (j) ∈ η ′ Out×S 2 (α 2 (s ′ j )( x′ (j))) | 1 and s ′ j ∈ η ′ Out×S 2 (α 2 (s ′ j-1 )( x′ (j -1))) | 2 and ∀j, 0 ≤ j ≤ n -1, π i ( x′ (j)) = i j and π o (y x′ (j)) = o j . Since Trace(C 1 ) ⊆ Trace(C 2 ), i 0 , . . . , i n is inevitably an input sequence of C 2 . Then, η ′ Out×S 2 (α 2 (s ′ n )( f (i n , y x′ (n -1))) | 1 is well defined. Now, we know that η ′ Out×S 1 (α 1 (s n )( f (x(n), y x (n -1)))) | 1 ⊆ η ′ Out×S 2 (α 2 (s ′ n )( f (i n , y x′ (n -1))) | 1This is because Trace(C 1 ) ⊆ Trace(C 2 ). This implies thaty x (n) ∈ η ′ Out×S 2 (α 2 (s ′ n )( f (i n , y x′ (n -1)))) | 1Hence according to the relaxed feedback definition, i 1 |o 1 , . .. , i n-1 |o n-1 , i n |o n ∈ Trace(←֓ I (C 2 )). Consequently, Trace(←֓ I (C 1 )) ⊆ Trace(←֓ I (C 2 )). According to Lemma 1.1, we have to prove:

	Let us now

  1| 1 |o 1| 1 , i 2| 1 |o 2| 1 , . . . , i m| 1 |o m| 1 on sub if sub ∈ Sub(op(C 1 , . . . , C n 1 )) is the projection of i 1| 2 |o 1| 2 , i 2| 2 |o 2| 2 , . . . , i m| 2 |o m| 2 on sub otherwise -if op = I (op ′ ) with I = ( f , π i , π o ), then tr ↓ sub = S ′ = op ′ (C 1 , . . . , C n ) and tr ↓ S ′ = i ′ 1 |o ′ 1 , . . . , i ′ m |o ′ m | ∀j, 1 ≤ j ≤ m, ∃s j ∈ S ′ , o ′ j ∈ η ′ Out ′ ×S ′ (α S ′ (s j )( f (i ′ j , o ′ j ))) | 1 i j = π i (i ′ j ) and o j = π o (o ′ j )

	tr ′ ∈tr ↓ S ′	tr ′ ↓ sub

where

  . . , i m |o m ∈ S FCT and every input i ∈ In ′ associates η ′-1Out ′ ×S FCT (Π) where Π is the set:Π = {(o, i 0 |o 0 , . . . , i m |o m , i|o ) | ∃o ∈ Out ′ , ∃tr ∈ Trace(S ) such that i 0 |o 0 , . . . , i m |o m , i|o ∈ tr ↓ sub }

  . . , i k |o k , i ′ k+1 |o ′ k+1 , . . . , i ′ k ′ |o ′ k ′ ) = ⊙ for all k < k ′ ≤ n and for all (i ′ l ) k≤l<n ∈ In ′ and (o ′ l ) k≤l<n ∈ Out ′ .

  = makeC|preparing p 2 = makeT|preparing p 3 = makeC|preparing, abs|coffee p 4 = makeC|preparing, abs|error p 5 = makeC|preparing, abs|coffee, makeC|preparing p 6 = makeC|preparing, abs|coffee, makeT|preparing p 7 = makeC|preparing, abs|error, {makeC, makeT} p 8 = makeC|preparing, abs|coffee, makeC|preparing, abs|coffee p 9 = makeC|preparing, abs|error, makeC|preparing, abs|error p 10 = makeC|preparing, abs|error, {makeC, makeT}, abs|error p 11 = makeC|preparing, abs|coffee, makeC|preparing, abs|coffee, makeC|preparing p 12 = makeC|preparing, abs|coffee, makeC|preparing, abs|coffee, makeT|preparing p 13 = makeC|preparing, abs|coffee, makeC|preparing, abs|error, {makeC, makeT} p 14 = makeC|preparing, abs|error, {makeC, makeT}, abs|error, {makeC, makeT} p 15 = makeC|preparing, abs|coffee, makeC|preparing, abs|coffee, makeC|preparing, abs|coffee p 16 = makeC|preparing, abs|coffee, makeC|preparing, abs|coffee, makeC|preparing, abs|error p 17 = makeC|preparing, abs|coffee, makeC|preparing, abs|error, makeT|preparing, abs|tea p 18 = makeC|preparing, abs|coffee, makeC|preparing, abs|coffee, makeT|preparing, abs|error p 19 = makeC|preparing, abs|coffee, makeC|preparing, abs|error, {makeC, makeT}, abs|error p 20 = makeC|preparing, abs|error, {makeC, makeT}, abs|error, {makeC, makeT}, abs|error

									skip
							makeC|preparing	p 0	makeT|preparing
							skip	p 1	⊙	p 2
									abs|error
					abs|coffee		abs|tea	abs |error
					skip	p 3		makeT |preparing	p 4	⊙
				makeC|preparing
									makeC,makeT
				skip	p 5				⊙	p 6	p 7	⊙
			abs|coffee			abs |error
								abs|tea	abs |error	abs |error
			skip	p 8			p 9	⊙	p 10	⊙
	makeC|preparing			makeT |preparing	makeC,makeT	makeC,makeT
	skip	p 11			p 12	⊙		p 13	⊙	p 14	⊙
	abs|coffee			abs |error	abs|tea	abs |error		abs |error	abs |error
	p 15		p 16	p 17	p 18		p 19	p 20
	accept	⊙		⊙	⊙			⊙	⊙
	p 0 =
	p 1

The dashed notation is used to express the uniqueness of morphisms.

The object Y X is read: Y is exponent of X.

See Sections 2.3, 2.4 and 2.5 for the definitions of product, coproduct and exponent respectively.

See Subsections 3.1.1 and 3.1.2 for the definitions of powerset and monoid respectively.

Note that we restrict ourselves to the category of sets. Hence, we work with coalgebras for an endofunctor F on the category of sets and functions.

τ is called internal action.

The dotted notation is used to express the uniqueness of the morphism.

In + denotes the set of finite non-empty sequences over In.

We deliberately omitted the abs action to make the representation easier. Hence, transitions are labeled with (a|abs) are simply represented as transitions labeled with a.

i.e component-wise projections

We require that the environment provides an artificial input ⊥ to make the component react.

We deliberately used α 1 (s)( f (x(n), y(n))) instead of η ′ (α 1 (s)( f (x(n), y(n)))) | 1 forsake of simplicity because η ′ considered here stands for the identify.

Note it is easy to see that the double sequential composition is a particular case of the synchronous parallel composition.

It is important to notice that all concepts introduced in this chapter are given at a generic level, i.e. they are independent of any particular formal method.

There exist another verdicts. For instance, the inconclusive verdict, noted Inconc, that is used if the implementation iut behaves correctly according to the specification spec, but its responses do not satisfy the test purpose.

The word "quiescence" is used to refer to blocking situations in states.1 -Conformance relation

See Table VII.1 for quasi-reduction definition.

This example is inspired from the example presented in[START_REF] Van Der Bijl | Compositional testing with ioco[END_REF].

For the sake of readability, input completeness (implementations) are not depicted in Figure VIII.2c and Figure VIII.2d.

Acknowledgments

I thank my parents for encouraging and supporting me during my whole study.

Chapter VII

Testing of components

5

Instantiating of the approach .

In this chapter, we develop a formal theory of conformance testing which allows us to test our components defined in the first part of this thesis. The work presented here is mainly inspired by the formal testing theory developed by A. Touil et al. in [44,[START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF]. In our conformance testing theory, behaviours of specifications and implementations under test are considered as coalgebras of the functor T(Out × ) In presented in Chapter IV. The conformance relation we consider is an adapted version of the well-known relation ioco proposed in [START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF], and that is defined as a partial inclusion of implementation traces into specification ones. Our work uses the notion of a test purpose as it was defined in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF]. In [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF], a test purpose provides an operative way to extract test cases by selecting from the specification model, described 1 as an IOSTS, the functionalities that we want to test. This is done by relying on a symbolic execution technique. In our approach, since we do not handle data but just values in both In and Out, we use a simple unfolding technique to define our test purposes instead of a symbolic execution technique. Then, our test purposes are directly derived from specifications using unfolding and marking algorithms, and look like labeled trees capturing all specification traces for a given length. We also propose in this chapter a test case generation algorithm as in [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF]. The underlying idea consists in choosing a possible input i and submitting it to the implementation under test, and then observing the outputs produced from it and compare them with the possible outputs in the specification. Hence, the only way to observe the reaction of the system under 1. IOSTS stands for Input-Output Symbolic Transition system. It is a variant of IOLTS including and handling explicitly the data system [START_REF] Gaston | Symbolic execution techniques for test purpose definition[END_REF][START_REF] Touil | Exécution symbolique pour le test de conformité et le test de raffinement[END_REF].

Let us note that three forms of ev are distinguished: i|o, i|ǫ o and ǫ i |o. Hence, each of these rules except rule 0 can be used in several ways according to the form of ev:

stimobs(ev = i|o) means o is produced by iut when it is stimulated with i; -stimobs(ev = i|ǫ o ) means the stimulation of iut with i does not produce any output; -stimobs(ǫ i |o) means o is produced spontaneously by iut.

These possibilities for ev therefore give rise to a generic algorithm that can be applied to a wide variety of state-based systems ( [START_REF] Tretmans | Test generation with inputs, outputs and repetitive quiescence[END_REF][START_REF] Jéron | TGV: theory, principles and algorithms[END_REF][START_REF] Lee | Principles and methods of testing finite state machines-a survey[END_REF]) by choosing the appropriate monad T and input and output sets.

Example

We illustrate the algorithm previously proposed with concrete examples. We consider the test purposes TP 1 and TP 2 defined in Figure VII.5a where:

event denotes the current element of the considered trace, and is of the form input|output;

rule stands for the rule applied to get the next set of states CS ′ .

Test cases for TP 1

Fail To get the verdict Fail, we consider the following trace:

The algorithm is applied as follows:

The verdict Fail is due to the following equality:

Inconc To get the verdict Inconc, we consider the following trace:

The algorithm is applied as follows:

-S TS = CS ∪ V where V is the set whose elements are Fail, Pass, Inconc and WeakPass; α TS is the mapping which for every CS ∈ CS and for every ev ∈ EV is defined as follows:

We note st(TP, iut) the set of all possible test cases for TP.

We can now introduce the notation: -Correctness: If iut conforms to spec, then for any test purpose TP, Fail ∈ vdt(TP, iut).

-Completeness: If iut does not conform to spec, then there exists a test purpose TP such that Fail ∈ vdt(TP, iut).

Proof

Proof of the correctness: Let spec = (S, s 0 , α) be a specification over a signature H = T(Out × ) In and FCT = (S FCT , s 0 FCT , α FCT ) be its finite computation tree. Let us prove the correctness using the contraposition principle. This means that to prove: if iut conforms to spec, for any test purpose TP, Fail ∈ vdt(TP, iut).

we have to prove: if there exists a test purpose TP such that Fail ∈ vdt(TP, iut), then iut does not conform w.r.t cioco to spec. and ∀j, 0 ≤ j ≤ n, π i (x(j)) = i j and π o (y(j)) = o j .

By induction hypothesis,

Then, similarly to the above, there exists an input sequence x ′ , an output sequence y ′ and a finite sequence of states (s ′ 0 , s ′ 1 , . . . , s ′ n ) of S 2 such that:

and ∀j, 0 ≤ j ≤ n -1, π i (x(j) ′ ) = i j and π o (y(j) ′ ) = o j .

Since Trace(C 1 ) ⊆ Trace(C 2 ), i 0 , . . . , i n is inevitably an input sequence of C 2 . Then,

Now, since Trace(C 1 ) ⊆ Trace(C 2 ), we have that:

Hence according to synchronous feedback defini- tion, i 1 |o 1 , . . . , i n |o n ∈ Trace( I (C 2 )). Consequently, Trace( I (C 1 )) ⊆ Trace( I (C 2 )). Proof By induction on the the structure of the complex operator op d'arity n.

End

Compositionality for complex operator

-Basic Step: op is of the form . The property mentioned in Theorem 1.3 trivially holds. -Induction Step: we distinguish the following cases:

1. op = ⊗(op 1 , op 2 ) with arity of op 1 is n 1 , arity of op 2 is n 2 and n 1 + n 2 = n by induction hypothesis and the definition of both op 1 and op 2 , we have:

Then, (1) + ( 2)

2. op = I (op ′ ) by induction hypothesis and the definition of op ′ , we have:

3. op =←֓ I (op ′ ) by induction hypothesis and the definition of op ′ , we have:

End By Theorem 1.3, we directly have that sequential, double sequential, synchronous parallel and concurrent compositions as well as synchronous product are compositional for cioco.

Our first attempt to answer this question is to check if the assumptions imposed in Theorem 1.3 are satisfied. Observe that neither spec M nor spec D are input-enabled. Hence, Theorem 1.3 fails to hold the compositinality of cioco for the components M and D. However, it is easy to see that the global implementation iut = ⊙(iut M , iut D ) can do the trace tr = coinC|preparing, abs|coffee, coinC|preparing, abs|refund Thus, refund ∈ Out(iut after ( coinC|preparing, abs|coffee, coinC|preparing , abs))

whereas the global specification spec = ⊙(spec M , spec D ) can also do the trace coinC|preparing, abs|coffee, coinC|preparing in such a way refund ∈ Out(spec after ( coinC|preparing, abs|coffee, coinC|preparing , abs))

Hence, we can see that iut does not conform to spec according to cioco.

Test purposes for sub-systems

In this section, we propose an approach to testing components that are typically involved in the whole system by defining dedicated test purposes for them, from the global behaviour of the whole system. Such test purposes are given in an accurate way by defining a projection Chapter IX Conclusion

. . 181

In this chapter, we conclude this thesis by describing the main objectives of the work, the goals we have achieved and the direction of future work.

Summary

Building correct systems has been the most difficult challenge for engineers and still continues to be so nowadays, due to the fact of growing system complexity and size. In this thesis, we explained the importance of component-based models to meet this challenge, and proposed an unified framework for both modeling and reasoning about the correctness of component-based systems formally. Hence, this thesis has been placed in the area of both modeling and testing of component-based systems.

We then defined a formalism based on Barbosa's component definition [START_REF] Barbosa | Towards a calculus of state-based software components[END_REF][START_REF] Meng | Components as coalgebras: the refinement dimension[END_REF]. For this formalism, a trace semantics from causal functions was proposed as is usually done in control theory and dynamic systems design. The resulting formalism is then generic enough to subsume a large family of state-based formalisms. A number of theoretical results were also obtained. First, in order to deal with large systems, we defined the notion of an integration operator as the composition of two basic operators: the product and feedback. We then showed the generic results of compositionality independently of a given integration operator. We also obtained results related to the construction of a final object in the category of components. Taking advantage of the genericity of the formalism, we then defined both conformance and compositional testing theories, which by definition can be applied to any formalism instance of our framework.

Future research

The main direction of our work can be categorized according to the following:

-The proposed formalism is just an initial proposal of formalism to model complex systems. For its application in concrete cases, experience is needed in the case of real size systems. Another goal is to give a mathematical framework for a discipline, called systems

List of Tables