Nous illustrerons notre travail par une étude de cas. Nous nous intéresserons à un logiciel de gestion d'articles pour une conférence. Typiquement, plusieurs phases ont lieu entre la soumission des articles et la date de la conférence :
soumission des articles par les auteurs. Les informations à fournir sont le titre de l'article, le titre, les auteurs (nom et a liations), le contact (pour le résultat des rapports), et en n l'article en lui même ( chier PDF ou PS) ;
27Des contrats de qualité de service, comme transmettre un message en 10ms peuvent bien entendu être attachés aux connecteurs.
répartition des articles parmi les rapporteurs. En général eectuée à partir des préférences émises par ces rapporteurs (choix d'un ensemble d'articles, ou de domaines de compétence) ;
relecture par les rapporteurs des articles assignés. Au moins 3 ou 4 rappor- teurs lisent un article ; l'ensemble des rapports émis permettront de décider l'acceptation ou le rejet du papier ;
noti cation aux auteurs des résultats ;
envoi de la version nale des articles par les auteurs ; inscriptions des participants ;
présentations des articles le(s) jour(s) J.
Nous nous intéresserons particulièrement à la phase de relecture. Nous proposons une architecture en trois composants :
Rapporteur
Composant représentant le rapporteur : sa fonctionnalité principale est de per- mettre au rapporteur (personne physique) de remplir le rapport (ou d'avoir un accès aux autres rapports, mais nous ne détaillerons pas cette fonctionnalité) ; Article
Composant permettant de gérer un article (informations fournies par les au- teurs, mais aussi les rapports ; plusieurs soumissions de rapports sont autori- sées). Nous ne donnerons qu'un accès pour les rapporteurs, mais on peut aussi imaginer un accès pour les auteurs ;
Gestion de la conférence
Gère les accès aux autres composants de l'application. Pour notre cas particu- lier, le composant Rapporteur doit demander au composant Gestion un accès au composant Article.
Un autre exemple (non traité) concerne les auteurs : un composant Auteur peut demander un accès à un composant Article (qui peut être nouveau). Le but de cet exemple n'est pas de dé nir une architecture complète, mais plutôt un exemple simple, et qui mette en jeu le maximum des possibilités que nous orons. Plusieurs implantations sont possibles. La première, classique, est celle où le com- posant Rapporteur doit demander au composant Gestion un accès à Article, pour pouvoir rentrer ou modi er un rapport sur l'article en question. Gestion enverra une référence vers un port de Article ; le Rapporteur utilisera cette référence pour envoyer la critique avec un deuxième port.
Nous proposons un protocole plus élégant, décrit par les gures 2.9 et 2.10 page suivante. Le Rapporteur utilisera le même port pour demander l'accès et envoyer la critique. Le composant Gestion identi e dans un premier temps le rapporteur ( - gure 2.9 : le rapporteur est correctement identi é), puis envoie au composant Article la référence vers le port du Rapporteur. Le composant Article utilise la référence reçue pour indiquer au composant Rapporteur d'une part que l'accès est autorisé, et d'autre part que le dialogue se poursuit avec lui (chaque message porte la référence de l'émetteur, ce qui permet de noti er le changement d'interlocuteur28) ; à la réception
du message accordé(...), le composant Rapporteur prend en compte la référence de son nouvel interlocuteur, et lui envoie le rapport.
La gure 2.10 présente le cas où le rapporteur a donné un mauvais mot de passe (ou ne peut pas rapporter sur l'article demandé) ; le composant Gestion refuse de continuer le dialogue.
Ce protocole présente l'avantage que l'ensemble (Gestion et Article) peut être implanté par un seul composant avec un unique port sans qu'il y ait changement du composant Rapporteur. Gestion Article rapporteur (réf.) accordé (formulaire) rapport (...) Rapporteur accès_rapporteur
(nom, MotdePasse, NumArticle)
1.
2. 4.
3.
Fig. 2.9: Exemple d'interaction : accès accordé, et entrée de la critique du rapporteur
Gestion Rapporteur
accès_rapporteur
(nom, MotdePasse, NumArticle)
1.
refusé
2.
Fig. 2.10: Exemple d'interaction : accès pour le rapporteur refusé (composant Article non représenté)
Nous cherchons à pouvoir véri er deux points :
les liens entre les ports des composants sont valides à l'assemblage, c'est-à- dire que les types des ports interconnectés sont compatibles. Par exemple, le type du port du composant Rapporteur indiquera que sa première action est l'envoi du message accès_rapporteur ; ce port doit être mis en relation avec un port dont le type est tel que la première action est la réception de ce message accès_rapporteur. Le langage que nous proposons, ainsi que la relation de compatibilité correspondante, sont décrits dans le chapitre 3 page suivante ; le comportement du composant est conforme à la description donnée par le
type comportemental de ses ports. Par exemple, le composant Rapporteur doit avoir le comportement décrit informellement par les gures ci-dessus : envoyer un message accès_rapporteur, attendre accordé avant de pouvoir envoyer rapport. Le chapitre 4 page 61 décrit la sémantique de notre modèle de composant ; le chapitre 5 page 77 permet de véri er que le composant respecte le type de ses ports.
Types d'interface
Dans ce chapitre nous décrivons le langage utilisé pour dé nir les interfaces. Un composant typé est un composant pour lequel chaque port initial ou créé en cours d'exécution a un type associé, et toute référence vers un port a aussi un type déclaré. Nous adoptons un langage de type comportemental où le type d'un port décrit ses états possibles, et pour chaque état, les actions requises ou permises à travers ce port, et les états après l'exécution d'une action. Une des principales caractéristiques de ce langage est l'utilisation de modalités may et must, et la distinction entre interfaces point-à-point (pair, ou peer) et serveur.
En plus de la syntaxe du langage, ce chapitre présente une relation de sous-typage et une relation de compatibilité. Il se termine pas une étude de cas pour permettre de bien saisir les concepts présentés.
3.1 Présentation informelle autour d'un compte en banque
Notre langage de type décrit l'ensemble des messages échangés entre le port et l'environnement. Cette sémantique de message se rapproche des ADL Darwin [MDK94] (où les interfaces des composants exposent des services requis et fournis qui sont res- pectivement des messages envoyés et reçus) ou Wright [AG96], où le type d'un port est une expression CSP [BHR84].Par exemple, l'accès à un compte en banque peut s'écrire, dans notre langage : accès_compte = may ? [ demande_accès (string, string) ;
must ! [ autorisé (opérations_compte) ; 0 + refusé ; accès_compte ] ]
Ce type se lit comme suit : le type accès_compte spéci e la réception du message demande_accès qui prend en paramètre deux chaînes de caractères (typiquement le nom de l'utilisateur et le mot de passe). Une fois ce message reçu, le type spéci e un envoi obligatoire (must!) à choisir parmi :
envoi du message autorisé avec en paramètre une référence vers un port typé opérations_compte. Une fois ce message envoyé, le type n'a plus d'actions (0) ; envoi du message refusé, et dans ce cas le type devient accès_compte pour un
nouvel essai d'authenti cation. 43
Le type opérations_compte quant à lui, est déclaré en deux fois : opérations_compte =
may ? [ créditer (integer) ; must ! [ solde (integer) ; opérations_compte ] + débiter (integer) ;
must ! [ solde (integer) ; opérations_compte
+ solde_négatif (integer) ; ops_compte_négatif ] ] ops_compte_négatif =
must ? [ créditer (integer) ;
must ! [ solde (integer) ; opérations_compte
+ solde_négatif (integer) ; ops_compte_négatif ]
+ débiter (integer) ; must ! [ solde_négatif (integer) ; ops_compte_négatif ] ] Un port typé opérations_compte peut recevoir deux messages :
créditer augmente le solde du compte du montant indiqué. Ce solde doit être ensuite envoyé par le message solde(...), après quoi le port accepte de nouvelles opérations (type opérations_compte) ;
débiter retire du solde du compte le montant indiqué. Deux cas se présentent : Si le compte reste positif, le solde est retourné et d'autres opérations peuvent
être eectuées (message solde(...) suivi du type opérations_compte) ; Si le compte devient négatif, alors l'utilisateur en est informé par le message
solde_négatif(...), et le type du port devient ops_compte_négatif. Ce type donne le comportement du port lorsque le compte est négatif.
Le type ops_compte_négatif est similaire au type opérations_compte, à une dif- férence fondamentale : la modalité qui porte sur la réception des messages créditer et débiter. Dans le cas où le compte est positif, cette modalité est may?, peut recevoir : elle indique qu'il est possible mais pas obligatoire d'eectuer des opérations de débit et de crédit sur le compte. Dans le cas où le compte est négatif, cette modalité est must?, doit recevoir : elle indique qu'il est obligatoire d'eectuer soit un débit, soit un crédit sur le compte.
La spéci cation opérations_compte que nous venons de décrire autorise l'utilisa- teur du compte à eectuer des opérations qui potentiellement le mettent en négatif ; par contre, tant que le compte n'est pas su samment approvisionné, l'utilisateur doit eectuer des opérations sur ce compte1.
Notre langage de type présente donc la particularité non seulement d'imposer des contraintes sur le comportement du composant, mais aussi d'imposer des contraintes sur son interlocuteur (soit : sur l'environnement du composant). L'introduction des modalités mène à un modèle sous-jacent qui est une sorte de Système de Transition Etiqueté Modal, dans lequel chaque état est soit may soit must [LSW95]. Cela a un impact assez fort sur les règles de compatibilité.
En outre, nous distinguons deux types de ports : les ports pairs (ou peer), et les ports serveurs. Les ports pairs sont engagés dans une communication de type point-à-point (1-à-1). Les ports serveurs sont engagés dans une communication de type client/serveur, au sens où ce sont les seuls à pouvoir servir plusieurs clients. 1un troisième type peut correspondre à la limite d'autorisation de découvert. Ce type interdira alors tout débit : must? [ créditer(...) ; must! [. . . ] ].
La raison principale de cette distinction est que le type comportemental permet une progression dans un dialogue qui doit être partagée entre les ports mis en relation (par exemple, l'émission de autorisé(...) doit coïncider avec la réception du même message) ; les ports pairs et les liaisons point-à-point nous permettent d'assurer faci- lement cette progression partagée. Nous ne désirons cependant pas nous restreindre à ces seuls types de communication ; un port serveur autorise les liaisons 1-à-n (ou client/serveur). Nous pensons que ces deux types de communication nous permet- tront de spéci er les autres modèles de communication (en utilisant un connecteur servant alors de médium de communication).