2.4 Spéci cations formelles pour composants
2.4.2 Typage comportemental
Un type comportemental est une abstraction du comportement de l'entité consi- dérée (objet, composant ou autre). Le service proposé par le type est alors appelé non uniforme, car il varie selon le contexte. Le typage comportemental permet donc de prendre en compte ces aspects dynamiques. La syntaxe des types est en général inspirée des algèbres de processus comme CCS [Mil83] ou le π-calcul [Mil93].
A notre connaissance, la première notion de comportement liée aux types se trouve dans [TJ92], où Talpin et Jouvelot associent un eet aux types de données, c'est-à-dire un ensemble d'interactions dé ni pour le type en question. Les auteurs dé nissent tout d'abord les régions qui représentent des structures de données : la région est une abstraction de l'emplacement mémoire alloué à ces données. Ensuite, le comportement d'une expression est exprimé par un eet, symbolisé en termes d'initialisation, de lectures et d'écritures sur les régions. En n, le type décrit les eets possibles sur les régions concernées, ainsi que leur évolution.
Mais le typage comportemental tel qu'on l'entend aujourd'hui a d'abord été ca- ractérisé par O. Nierstrasz, dans ses types réguliers [Nie95] (c'est-à-dire qu'ils spé- ci ent des processus représentables par une machine à état nis). Par exemple, le type Buf=(b1, {b1=put.b2, b2=get.b1}) spéci e le comportement d'un buer à une place : à l'initialisation, le buer est de type b1, et accepte la seule méthode put ; une fois cette méthode activée, le type change en b2 où la seule méthode ac- cessible est get. La plupart des langages de type comportementaux suivent le même principe. Nierstrasz dé ni aussi une relation de sous-typage, ou de substitution des
requêtes : le sous-type doit proposer au moins les mêmes services que le super-type, avec moins d'erreurs. La relation est donnée en termes de transition, et un équivalent en termes de traces (les traces du super-type sont inclues dans celle du sous-type, et les traces échecs du sous-type sont inclues dans celles du super-type).
Il existe deux écoles quant au typage comportemental. L'une dérive des types réguliers de Nierstrasz, en général pour typer les ports ; notre approche appartient à cette école. L'autre utilise les algèbres de processus pour typer les processus eux- mêmes.
Les travaux découlant des types réguliers sont assez proches de notre proposi- tion. Nous passons en revue rapidement les principaux ; la section 7.1.1 page 124 du chapitre 7 donne plus de détails.
Colaço, Colin, Dagnat, Pantel et Sallé travaillent sur l'inférence de type pour le langage d'acteur CAP [CTP03, Col02, DPCS00]. Ils s'intéressent tout comme nous au problème de la consommation des messages : assurer qu'un message envoyé sera nalement consommé. Contrairement à notre approche, les auteurs ont des les d'attente qui ne sont pas ordonnées. Concernant le type des ports du composant, nous pensons qu'il est préférable de se baser sur une sémantique qui conserve l'ordre des messages. Mais cela soulève le problème d'interblocage entre les composants.
Il est à noter que notre travail est la poursuite des travaux de Najm et Ni- mour [NNS99b, NNS99a, NN97], qui proposent un calcul d'objet pour interfaces non uniformes. Leur système de type assure que tout message envoyé sera compris (et consommé) par le récepteur. Ce système de type ne convient pas pour les compo- sants, car d'une part la communication est synchrone, et d'autre part les types ne permettent pas de mélanger émissions et réceptions. Nous avons cependant gardé les notions d'interfaces publiques (accessibles par plusieurs clients), et privées (acces- sibles par un seul client). Un autre travail très proche de celui de Najm et Nimour, est celui de Ravara et Vasconcelos[RRV02, RV00]. Les auteurs s'intéressent aussi aux erreurs de type message non compris, mais leur notion d'erreur est trop lâche : il n'y a pas d'erreur si le message est consommé ou si l'objet auquel il était destiné est éphémère. Ce dernier point nous semble être un point faible pour appliquer leur travail directement sur les composants.
En n, récemment, Gay et Vasconcelos, dans [GH99, VVR02, GH03] ont repris l'idée des types de session (session types) de Honda et al. [THK94, HVK98]. Les types de session sont associés aux canaux de communication, et spéci ent le protocole d'interaction qui a lieu sur ce canal. Mais les auteurs ne démontrent pas l'absence d'interblocage, et n'ont pas de modalités sur les actions.
La deuxième école des types comportementaux s'intéresse aux processus. La plu- part des travaux proposent un système de type pour le π-calcul, principalement parce que ce langage a un pouvoir d'expression assez élevé.
La proposition de Gérard Boudol [Bou97a] est ciblée sur le calcul bleu [Bou97b] (une variante du π-calcul), en s'inspirant de la logique linéraire ; son approche permet de détecter les interblocages, mais d'une part sa notion est trop large (des processus ne sont pas typables), et il ne détecte qu'une partie des messages non compris.
Puntigam propose dans [PP99, Pun97] un modèle de type basé sur le modèle d'acteur [AMST93]. Les types sont décrits à partir d'un ensemble de messages (signa- tures, conditions, changements d'état), et d'états. Le type dé nit donc les séquences
de messages qu'un objet est capable de traiter. Puntigam étend son système de type dans [Pun99] pour autoriser les séquences de messages non réguliers. Les états dé- nissent des jetons qui peuvent être déposés ou retirés par les processus lors d'une interaction. Le contrôle se fait à la fois sur le nombre de jetons restant, mais aussi sur le nombre de processus pouvant y accéder.
Les types proposés par Pierce et Sangiorgi [PS93] permettent de restreindre, selon le contexte, les canaux de communications aux émissions, réceptions, ou les deux. Ce travail a été repris par Kobayashi et al. [KPT99, IK01] qui proposent un système de type dénotant les séquences d'interaction. Ils assurent que les processus communi- cants n'interfèrent pas avec les autres. Kobayashi a étendu ce travail pour pouvoir prouver l'absence de blocage d'un processus [Kob02]. Le type des canaux de com- munications sont estampillés de capacités et d'obligations (en termes de nombre de transition). Deux types sont compatibles si les capacités de l'un correspondent aux capacités de l'autre. L'inconvénient du système de type de Kobayashi est qu'il est dif- cile d'établir les obligations sans être trop restrictif. Le travail de Kobayashi est très proche du notre ; la section 7.1.1 page 124 du chapitre 7 approfondi la comparaison des deux travaux.
Les types comportementaux que nous venons de voir présentent quelques li- mites en regard du problème qui nous intéresse. D'une part, les modalités sur les actions sont très peu présentes. Nous pensons qu'elles sont primordiales pour im- poser des contraintes sur l'environnement du composant, selon le concept de sup- position/garanties. D'autre part, les travaux ne se positionnent pas vis-à-vis d'un assemblage de composant. En n, peu d'approches distinguent la notion de liaison point-à-point et celle de client/serveur (1-à-n).