La Rochelle Université - Objets à contrôle...

RECHERCHE

Objets à contrôle réactif

Un modèle de conception pour applications concurrentes

Michel Augeraud — Frédéric Bertrand

Laboratoire d’informatique et d’imagerie industrielleUniversité de La RochelleAvenue MarillacF-17042 La Rochelle Cedex{michel.augeraud, frederic.bertrand}@univ-lr.frhttp://www-l3i.univ-lr.fr/L3I/equipe/{maugerau, fbertran}

RÉSUMÉ. Nous présentons le concept d’objet à contrôle réactif qui permet la conception d’appli-cations concurrentes à objets en dégageant le concepteur de la réalisation de la gestion des pro-cessus. Le concept que nous avons développé utilise la programmation réactive comme moyende contrôle du comportement des objets. Une des caractéristiques essentielles du modèle résidedans la séparation de l’expression et de l’exécution du contrôle des exécutions concurrentes del’expression et de l’exécution des transformations réalisées par les méthodes. Le contrôle estexprimé par un programme spécifiant les réactions attendues au cours du temps en fonctiondes appels de méthodes. Nous étudions également les relations du comportement vis-à-vis del’héritage et de l’agrégation. La base formelle sur laquelle repose la programmation réactivenous permet de réaliser la vérification de propriétés sur le comportement d’objets.

ABSTRACT. This paper presents the reactive controlled object model. It allows the design ofconcurrent applications giving the designer tools to concentrate on semantics and decharginghim to manipulate processes. Our reactive controlled object paradigm uses a reactive languageto program controllers which have in charge to control objects behavior. This model splitsprogramming in two parts, transformations done by objects methods and their control. Thecontrol is expressed using a term which specify expected reactions over time relatively tomethod calls. More, properties concerning coherency between behavior of objects boundedby an inheritance or an aggregation relationship are defined and verifications are shownusing simple examples. They are also used to picture the ablity we have to verifiy structuralproperties concerning method coordination.

MOTS-CLÉS : langages à objets concurrents, systèmes concurrents, contrôle réactif, verification.

KEY WORDS : concurrent object-oriented languages, concurrent systems, reactive control, model-checking.

Technique et science informatiques.

2 Technique et science informatiques.

1. Introduction

Les raisons qui justifient les recherches visant à introduire la concurrence dans lessystèmes à objets sont nombreuses. Parmi les plus importantes on peut noter :

1. une meilleure modélisation des objets du monde réel qui souvent se comportentde manière concurrente ;

2. l’amélioration des performances ;

3. allier les avantages (puissance notamment) de la programmation concurrenteavec ceux (en particulier, modularité) de la programmation à objets.

Mais surtout il y a une forte similitude entre processus et objet [MEY 93]. Malgrécette convergence et les nombreux travaux (voir [PAP 92, GUE 95, FUR 95, BRI 96,WEL 96] pour un panorama complet) intrégrant programmation concurrente et pro-grammation objet, il subsiste de nombreux problèmes. En particulier, la gestion de laconcurrence reste difficile surtout en raison du manque de distance entre l’expressiondes traitements réalisés par un objet et l’expression du contrôle de son fonctionnementcomme entité qui fournit des services.

Notre approche [AUG 92, BER 95] consiste à séparer ces deux aspects en considé-rant les objets comme des machines abstraites chargées de fournir des services. L’ac-cessibilité de ces services est soumise à des contraintes qui traduisent les possibilitésd’exécution en fonction de l’histoire des opérations exécutées par l’objet. Pour fairerespecter ces contraintes, l’accès à un objet est contrôlé par un programme réactif quigère, en fonction des demandes d’exécution et de l’historique des appels, l’activationou non des méthodes.

La décision d’exécution prise par un objet ou un groupe d’objets suite à un ap-pel d’une de ses méthodes dépend de la satisfaction de nombreuses contraintes. Lescontraintes que nous étudions concernent l’ordonnancement des exécutions de mé-thodes. Ces contraintes comportementales participent à la sémantique de l’objet oudu groupe d’objets. Elles permettent d’exprimer différentes propriétés sur l’exécutioncomme la séquentialité ou l’exclusion mutuelle. Elles concernent :

— l’ordre d’exécution des méthodes : par exemple, le bon fonctionnement d’unascenseur impose que les portes soient fermées avant que l’ascenseur démarre ;

— les possibilités ou impossibilités d’exécutions concurrentes : des méthodes met-tant à jour un même attribut ne peuvent pas et ne doivent pas s’exécuter de manièreconcurrente ;

— la possibilité que possède une méthode d’en interrompre une autre : l’exempled’une méthode d’arrêt d’urgence qui doit interrompre les exécutions en cours.

Le comportement contrôlé représente, comme dans les techniques de vérification,une abstraction du comportement de l’objet. De ce choix découle un ensemble cohé-rent de conséquences étudiées dans cet article :

— le comportement peut être isolé et étudié à part, ceci réduisant la complexitédu problème ;

— le comportement s’exprime sous forme d’un programme réactif ;

Objets à contrôle réactif 3

— les outils de vérification associés aux langages réactifs permettent au concep-teur d’opérer sur la représentation du comportement, en particulier pour prouver quele programme de contrôle du comportement satisfait certaines propriétés.

Cette approche consistant à effectuer des vérifications permet d’assurer que lesobjets en relation (héritage, composition) restent cohérents du point de vue de leurcomportement.

Dans la section 2 nous présentons les principaux travaux concernant l’introductionde la concurrence dans la programmation objet. Puis, section 3, nous introduisonsnotre modèle d’objet à contrôle réactif et, dans la section 4, montrons l’utilisationde ce modèle pour un convoyeur utilisé dans un atelier flexible. Les possibilités devérification que permet notre modèle sont présentées dans la section 5. Nous terminonspar la présentation d’une mise en œuvre en Java, section 6, en précisant la relationentre le module de contrôle du comportement et l’objet. En section 7, nous concluonsen présentant les perspectives de nos travaux.

2. Intégration de la concurrence dans la programmation objet

2.1. Introduction

L’introduction de la concurrence dans les langages à objets pose trois types de pro-blèmes, (1) l’articulation entre objets et processus, (2) la communication entre objetset (3) la synchronisation. Dans ce travail, nous nous intéressons seulement à l’aspectsynchronisation. Le lecteur peut se référer à plusieurs articles de synthèse qui pré-sentent les différentes façons dont les concepts énumérés précédemment ont été misen œuvre [PAP 92, GUE 95, FUR 95, BRI 96, WEL 96].

L’expression de la synchronisation peut, selon le niveau auquel s’effectue le con-trôle, concerner l’objet, ses méthodes ou les instructions de ses méthodes. Ainsi lesproblèmes posés par des accès concurrents de méthodes qui modifient un attributpeuvent être résolus en restreignant les possibilités d’exécutions concurrentes :

— soit en interdisant l’exécution concurrente de méthodes au sein d’un mêmeobjet (autoriser uniquement la concurrence inter-objet) ;

— soit, plus sélectivement, en interdisant la concurrence entre certaines méthodes(permettre une concurrence intra-objet).

Dans l’approche suivie, notre modèle se fonde sur un modèle à objets actifs pourlequel les méthodes sont exécutées dans des processus. Les mécanismes de synchro-nisation auxquels on s’intéresse, considèrent les méthodes comme unités de synchro-nisation.


2.2. Travaux existants

Pour rendre transparente, aux clients de l’objet, la synchronisation de leurs re-quêtes, les conditions de synchronisation sont associées à l’invocation des méthodesdans la plupart des langages existants. Ce choix évite aussi la dissémination du codede contrôle sur les clients. On constate aussi que, d’une manière générale, les travauxles plus récents [MAT 93, CAR 93, MAC 94] choisissent d’exprimer le contrôle dessynchronisations de manière la plus indépendante possible du corps des méthodes.

De manière générale, les conditions d’activation d’une méthode peuvent être fon-dées :

— soit sur une représentation spécifique, les conditions étant directement expri-mées en fonction de l’état de l’objet. Ce type de représentation est illustré principale-ment par deux types de mécanismes :

– les compteurs de synchronisation : ce mécanisme, développé par ROBERT etVERJUS [ROB 77] utilise des compteurs pour mémoriser le nombre d’appels à chaqueméthode suivant le stade de leur traitement. On distingue les appels parvenus à l’ob-jet, les appels en cours de traitement (exécution) et ceux dont l’exécution est terminée.Ces compteurs de synchronisation sont à la base de nombreux mécanismes de contrôle[MAC 94]. Ils sont principalement utilisés dans des gardes : conditions associées auxméthodes d’un objet. Quand une méthode est appelée, l’exécution est bloquée jus-qu’à ce que la garde devienne vraie. À partir de ce modèle, des travaux ont été menés(DRAGOON [CRE 91]) afin de réaliser un langage permettant l’héritage de compor-tements. La technique utilisée consiste à définir le comportement dans une classe àpart entière et non dans la classe de l’objet. Chaque classe représente des modulesgénériques au sens où les définit MAC HALE [MAC 94]. Une classe de comportementdécrit une politique de comportement standard comme lecteurs-écrivains, exclusionmutuelle...

– l’expression algorithmique du processus de contrôle, utilisée dans les mo-dèles à objets actifs, repose sur l’exécution d’une méthode particulière — exécutéeen tâche de fond — dont le rôle est de « calculer » les réponses à apporter aux de-mandes reçues par l’objet comme dans POOL [AME 87] ou dans EIFFEL// [CAR 93].L’exécution de cette méthode intervient dès la création de l’objet et se poursuit enpermanence jusqu’à la destruction de l’objet. Le programmeur doit explicitement endécrire le code.

— soit sur une représentation abstraite, les conditions sont exprimées en terme depropriétés abstraites portant sur l’exécution des méthodes et ne se réfèrent pas à unemise en œuvre particulière. Cette approche a conduit principalement à deux types demécanismes :

– les expressions de chemins (path expressions) [CAM 73] : ce type d’expres-sion utilise une notation dérivée des expressions régulières pour spécifier des con-traintes d’ordonnancement sur l’exécution des méthodes.

– les ensembles autorisés (ENABLED-SETS) : ce mécanisme, introduit dans[KAF 89], a été développé avec le langage ROSETTE [TOM 89]. Il est fondé sur le


concept d’abstraction comportementale qui consiste à définir des états abstraits decontrôle pour chacun desquels est défini un ensemble spécifique de méthodes autori-sées à s’exécuter. Un des principaux avantages de ce mécanisme est de permettre l’hé-ritage (et donc le raffinement) d’une politique de contrôle par une sous-classe. Si cettesous-classe introduit une nouvelle méthode, alors celle-ci peut être ajoutée à un (ouplusieurs) ensemble autorisé hérité de la classe mère. L’enrichissement d’ensemblesautorisés dont on hérite, constitue un mécanisme simple de réutilisation. On peut ainsiraffiner un comportement en définissant, pour certains états de contrôle, de nouvellestransitions possibles (correspondant à de nouvelles autorisations d’exécution). Cettetechnique a servi de base à différents langages dont ARCHE [BEN 92].

Il est important de noter que les concepts de concurrence et d’héritage ne sontpas indépendants. En effet, plusieurs travaux ont montré l’existence de conflits entreconcurrence et héritage [AME 87, KAF 89, TOM 89, PAP 92]. Ces conflits sont dé-nommés « anomalies d’héritage ». Le modèle des ENABLED-SETS est une réponseà ce problème. Dans ce modèle, les conditions de synchronisation des méthodes sontreprésentées à partir d’états abstraits. À chaque état est associé un ensemble de mé-thodes pouvant être exécutées. Cependant les transitions entre états sont préciséesdans le code des méthodes. Dans cette approche, la séparation entre l’expression de lasynchronisation et le code des méthodes demeure partielle.

En utilisant le même principe d’une approche déclarative, MATSUOKA, TAURA

et YONEZAWA [MAT 93] ont proposé une solution minimisant ces anomalies, lesensembles de méthodes. Ses principales caractéristiques sont sa forme déclarativecomme dans les ENABLED-SETS et une séparation complète du code de synchro-nisation de celui des méthodes car les transitions entre états sont exprimées en dehorsdu code des méthodes. Cette solution résout notamment le problème du changementd’état abstrait suite à une terminaison de méthode.

2.3. Synthèse

Quelle que soit la technique utilisée, le principe mis en œuvre peut être modélisépar une suite d’événements marquant les différentes étapes de l’appel et de l’exécutiond’une méthode. Ce modèle a été utilisé par MAC HALE [MAC 94] dans la définitiondu modèle Service-Object Synchronization (SOS). Chaque exécution d’une méthodem est représentée par deux événements ordonnés : début_m et terminaison_m. L’appeld’une méthode m d’un objet par un objet client se modélise par l’enchaînement desévénements présentés sur la figure 1.

Dans les différents mécanismes de synchronisation présentés ci-dessus, le contrôleintervient dès la réception d’une demande d’exécution, événement arrivée_m, et pro-duit, si l’activation est possible, l’événement début_m. L’objet réagit donc dès l’arrivéed’une demande.

Dans les différents travaux sur la synchronisation, seule l’activation (événementdébut_m) et la terminaison (événement terminaison_m) créent un changement d’étatdans l’objet (les demandes ne conduisant pas à une exécution sont oubliées). Ainsi,


appel

retour

début

arrivée

terminaison

Objet client Objet serveur

Figure 1. Les événements survenant lors de l’exécution d’une méthode

de manière plus précise, une exécution se traduit par un système à deux états et deuxtransitions :

Étatdébut_m��! État0 ( où m est active) (1)

État0terminaison_m��! État (où les attributs de l’objet sont modifiés) (2)

La séparation entre l’expression du contrôle et celle des transformations expriméedans les méthodes, impose que les caractéristiques de l’état soient définies séparémentdans l’expression du contrôle et dans le reste de la définition de l’objet.

3. Le modèle d’objets concurrents à contrôle réactif

3.1. Réactivité

Pour que les appels destinés à un objet ne soient pas perdus, le programme decontrôle de la synchronisation doit réagir à la vitesse du flux d’entrée. Ce type decomportement (réaction rapide vis-à-vis d’événements) est étudié depuis une dizained’années à travers une famille de langages dit réactifs. Ces langages sont liés auconcept de système réactif définit par PNUELI et HAREL dans [PNU 85]. Un sys-tème réactif est défini comme un système réagissant instantanément à des événementsreçus de manière continue de l’environnement. Cette réaction s’effectue en émettantdes événements vers cet environnement. Le système ne calcule ou n’exécute pas defonction mais maintient un équilibre avec son environnement. La plupart des systèmestemps-réel (ex. systèmes de contrôle ou de traitement du signal) et des protocoles decommunications sont des exemples de systèmes réactifs. La mise en ouvre logiciellede ces systèmes a conduit à plusieurs langages parmi lesquels ESTEREL [BER 92],STATECHARTS [HAR 87] et ELECTRE [CAS 95] sont représentatifs des différentesapproches possibles pour cette mise en œuvre.

En raison du caractère critique des systèmes mis en ouvre, ces langages possèdentune sémantique mathématique permettant la vérification formelle de propriétés com-portementales.


Dans notre cas, le fonctionnement du contrôleur est cadencé par l’arrivée des évé-nements (demandes et terminaisons d’exécution de méthodes). À chaque instant, unseul événement est pris en compte à l’entrée du contrôleur. Celui-ci produit (dans lemême instant) un événement de sortie qui est soit une activation de méthode, soit unedemande de mémorisation de l’événement entré.

Ce choix est celui que nous avons effectué dans le modèle des objets à contrôleréactif présenté dans la section suivante.

Il repose, comme tout système réactif, sur l’hypothèse que le système réagit « in-finiment rapidement ». Concrètement la réaction doit avoir lieu entre un événementd’entrée et le suivant. Il est important de souligner que dans notre modèle c’est lecontrôle qui est réactif, c’est-à-dire que le contrôleur doit réagir plus rapidement quele système de communication. Cette hypothèse, identique à celle du langage réactifELECTRE, est réaliste, d’une part en raison de la nature de l’activité du contrôleur quin’effectue que des tests, d’autre part parce que les systèmes de communication sontdotés de capacités de temporisation.

Le temps de traitement des méthodes étant infiniment supérieur au temps de ré-action du contrôleur, une saturation de l’objet peut résulter d’un nombre importantd’appels pour des méthodes ne pouvant s’exécuter. Cette saturation existe dans toutprogramme concurrent où l’objet receveur mémorise les appels ne pouvant pas s’exé-cuter et ne nécessitant pas une réponse immédiate. Mais dans notre modèle le contrô-leur peut le signaler. Néanmoins, l’hypothèse « le contrôleur peut réagir » devrait êtreformellement vérifiée à chaque mise en œuvre.

3.2. Le modèle d’objets concurrents

Pour définir notre modèle, nos différents choix ont été guidés par les objectifssuivants :

1. permettre à l’objet d’être constamment réceptif à l’évolution de son environne-ment. L’exécution d’une requête ne doit pas empêcher l’objet de pouvoir répondre àd’autres sollicitations notamment en indiquant si la demande peut être satisfaite im-médiatement ou si elle doit être différée. L’objet doit pouvoir également, si nécessaire,exercer un contrôle sur ses exécutions en cours. Par exemple, préempter l’exécutiond’une méthode si celle-ci n’était plus utile ou si, pour des raisons de sécurité, son arrêtdevenait critique ;

2. augmenter la capacité de traitement de l’objet pour permettre à une méthoded’être exécutée dès que l’état de l’objet le permet ;

3. offrir la possibilité d’effectuer des vérifications de propriétés sur le fonctionne-ment individuel ou collectif d’objets ;

4. permettre aux objets d’être répartis sur plusieurs machines d’exécution.

En prenant en compte ces différents objectifs, notre choix s’est porté sur un modèled’objet actif qui seul permet à un objet de pouvoir contrôler les exécutions de sesméthodes (point 1). Dans un modèle d’objet passif, les fils d’exécution ne sont pascrées par l’objet et de ce fait, il ne peut agir directement sur eux.


Concernant la concurrence intra-objet, le point 2 nous a naturellement conduit àadopter un modèle décrivant une concurrence intra-objet où chaque méthode est exé-cutée dans un fil d’exécution. Le contrôle des conditions d’exécution s’effectue enréagissant aux demandes d’exécution par l’activation de la méthode ou la mémorisa-tion de la demande. C’est un comportement réactif et le caractère « temps réel » desprogrammes réactifs apparaît comme une réponse à l’objectif 2.

En ce qui concerne l’interaction entre objets, nous avons suivi la proposition deMEYER [MEY 93] de laisser l’objet appelant maître des caractéristiques de l’appel.Ainsi un appel de méthode devra préciser le mode d’appel (synchrone ou asynchrone),la politique de réponse (immédiate ou normale 1), et une référence au fil d’exécutionréalisant l’appel pour permettre une synchronisation dans le cas d’un appel asynchronede méthode nécessitant en particulier le retour d’un résultat.

Le modèle à objets concurrents défini, nous allons maintenant préciser l’approchedéveloppée pour gérer la concurrence intra-objet.

3.3. Le contrôle réactif des exécutions

3.3.1. Problématique

Dans un modèle à objets concurrents (avec ou sans concurrence intra-objet) l’ac-tivation d’une méthode dépend de conditions liées :

— à la valeur des attributs de l’objet comme, par exemple, dans le cas d’un tamponborné où la méthode mettre n’est exécutable que si le nombre d’éléments présentsn’est pas égal à la taille maximale du tampon ;

— à l’activité des méthodes dans lesquelles on peut distinguer les conditions liéesaux exécutions en cours — comme dans le cas de l’exclusion mutuelle — de cellesliées à l’historique des exécutions et des appels. Par exemple, le cas où une méthodedoit être exécutée avant une autre afin de respecter la sémantique de l’objet.

Notre approche concerne l’expression des conditions liées à l’état d’exécution desméthodes. Ce contrôle concerne la coordination des exécutions des méthodes affec-tant un même objet. Son objectif est de réaliser l’ordonnancement des méthodes définipar le cahier des charges, éventuellement pour maintenir la cohérence structurelle del’objet en assurant des propriétés comme l’exclusion mutuelle. Les conditions d’exé-cution des méthodes constituent la « logique de fonctionnement » associée à l’objet.Pour assurer le respect de ces conditions, nous avons choisi d’associer à l’objet unestructure dédiée à cette fonction que nous avons nommée contrôleur d’exécution. Lafigure 2 illustre l’architecture générale d’un objet concurrent d’après le modèle défini.

D’autre part, pour permettre la programmation de ce contrôleur, c’est-à-dire spé-cifier les conditions relatives à l’état d’exécution des méthodes, nous avons développéun langage nommé BDL [BER 99] (pour Behavorial Description Language) permet-tant l’expression des contraintes entre les méthodes d’un objet.

1. On qualifie de normale la politique pour laquelle la requête de l’objet client est exécutée au plus tôt.


demandesd’exécutionde méthodes

filsd’exécutioncontrôleur

d’exécution

méthode en coursd’exécution

préemption

méthode

activation(création d’un fil

d’exécution)

terminaison

Figure 2. Architecture logique d’un objet concurrent avec contrôleur d’exécution

3.3.2. Le concept de contrôleur d’exécution

Le contrôleur d’exécution assure trois fonctions au sein d’un objet concurrent.La première est relative à la gestion des exécutions : le contrôleur crée, pour chaque

méthode dont l’exécution est demandée, un fil d’exécution destiné à exécuter le codede la méthode.

La seconde, plus complexe, consiste à synchroniser les exécutions à partir du pro-gramme BDL associé au contrôleur. Pour réaliser cela, le contrôleur doit connaître enpermanence l’état d’exécution des méthodes qu’il contrôle. Actuellement, le modèled’exécution du contrôleur possède une restriction : le contrôleur ne se réfère pas auxattributs de l’objet pour décider si la méthode est exécutable ou non. Ces conditionssont vérifiées dans le code de la méthode. Cette restriction provient des outils de vé-rification utilisés (section 5) qui opèrent sur des systèmes de transitions finis ; la priseen compte de conditions sur les attributs nécessiterait l’introduction de données numé-riques avec des domaines de définition non finis rendant impossible l’utilisation de cesoutils de vérification. Cette contrainte peut être illustrée par l’exemple bien connu deslecteurs-écrivains : dans un objet adoptant ce mode de synchronisation, une méthodelecture peut avoir simultanément des exécutions multiples. Le problème principalest alors de s’assurer que toutes ces exécutions soient bien terminées pour autoriserl’exécution d’une méthode ecriture. Le seul moyen est alors de compter les débutset les fins d’exécution 2 mais ce type de fonctionnalité ne peut pas être réalisé par unsystème de transitions fini si le nombre d’exécutions simultanées n’est pas borné.

La troisième fonction concerne la mémorisation de demandes normales qui nepeuvent être satisfaites immédiatement. Dans un tel cas, la demande est mémoriséepuis réitérée lorsqu’une méthode se termine car c’est à cet instant que les demandesen attente ont la possibilité d’être satisfaites.

2. En utilisant par exemple des compteurs de synchronisation (voir [ROB 77]).


3.4. La programmation du contrôleur avec BDL

3.4.1. Les opérateurs de BDL

Dans BDL, il existe trois types d’entités : les identificateurs de méthodes, les quali-ficateurs d’exécution de méthodes et les opérateurs d’ordonnancement. Ces opérateursont été adaptés du langage réactif asynchrone ELECTRE [CAS 95]. La grammaire dulangage BDL est présenté ci-dessous (sous forme BNF) :

T ::= T * répétitionj T ; T sequentialitéj T ||| T parallélisme faiblej T || T parallélisme fortj T | T exclusion mutuellej T ˆ T préemption faiblej T / T préemption fortej ( T ) parenthèsesj qualificateur nom_méthode méthode

qualificateur ::= exec_atomique exec_auto qualificateur de méthode

exec_atomique ::= nil j # exécution atomique

exec_auto ::= nil j ! exécution automatique

La sémantique intuitive de ces opérateurs est la suivante :

— un opérateur unaire de répétition, noté « * », indique que le terme BDL serépète à l’infini ;

— un opérateur binaire de séquentialité, noté « ; », indique que le terme gauchedoit être exécuté avant le terme droit ;

— deux opérateurs binaires de parallélisme indiquant que les termes gauche etdroit peuvent être exécutés en même temps :

– un parallélisme faible, noté « ||| », exprimant une possibilité : la structureparallèle peut se terminer si un terme a fini son exécution et que l’autre n’a pas encoredébuté la sienne ;

– un parallélisme fort, noté « || », exprimant une nécessité : la structure pa-rallèle se termine uniquement lorsque les deux termes ont achevé leur exécution.

— un opérateur binaire d’exclusion mutuelle, noté « | », indique que l’exécutiondes deux termes doit être mutuellement exclusive ;

— deux opérateurs binaires de préemption indiquant que l’exécution du termegauche est stoppée par le début d’exécution du terme droit. Il existe deux types depréemption :

– une préemption faible, notée « ˆ », indiquant que l’exécution du terme droitpeut survenir uniquement durant l’exécution du terme gauche ;


– une préemption forte, notée « / », indiquant que l’exécution du terme droitest obligatoire même si le terme gauche a terminé son exécution ;

Dans BDL, des propriétés sur l’exécution des méthodes peuvent être spécifiéesavec deux qualificateurs :

— un qualificateur d’atomicité, noté « # », indiquant que l’exécution de la mé-thode ne peut pas être interrompue ;

— un qualificateur, réservé aux méthodes privées de l’objet, noté « ! », indiquantque l’exécution de la méthode démarre automatiquement dès que le terme la précédantest terminé.

3.5. Mise en œuvre du langage BDL

3.5.1. La notion d’événement

La modélisation par événements des différentes étapes de l’exécution d’une mé-thode représente le fondement de la sémantique de BDL. Dans ce modèle, les de-mandes d’exécution de méthodes sont reçues par le contrôleur comme des événementsde type arrivée. Ces événements représentent des requêtes provenant d’autres objetsou de l’objet lui-même, et sont reçus à des instants distincts (c’est-à-dire un par un)par le contrôleur.

L’exécution déclenchée par le contrôleur représente la réaction à la réceptiond’un événement arrivée. En réponse, si l’exécution est possible, un événement detype début est émis à destination de l’environnement d’exécution. Dans le cas où laméthode n’est pas exécutable lors de l’arrivée de la demande, alors un événementexec_impossible est émis.

Durant l’exécution d’une méthode, si celle-ci doit être interrompue (préemption),alors un événement stop est émis par le contrôleur.

La fin normale d’une exécution de méthode est signalée au contrôleur par un évé-nement de type terminaison.

Lorsqu’une méthode est appelée, il est également nécessaire de représenter ce quisurvient du côté client. L’envoi d’une demande d’exécution est représenté par un évé-nement de type appel et, une fois la méthode exécutée, un événement de type retourest renvoyé à l’objet appelant.

La séquence d’événements survenant lorsqu’un objet (client) demande l’exécutiond’une méthode à un autre objet (serveur) a été présentée sur la figure 1.

Concernant l’objet appelé, la distinction entre les événements arrivée et débutest importante car elle représente le contrôle exercé par le contrôleur sur la demanded’exécution. Une autre caractéristique doit également être soulignée, elle est repré-sentée par l’existence des événements début et terminaison qui introduit la notion dedurée pour une exécution. Ces caractéristiques se retrouvent également dans le modèleSOS [MAC 94].


3.5.2. Utilisation d’un automate et traduction en Esterel

D’un point de vue théorique, un programe BDL décrit les contraintes d’ordre par-tiel entre les événements d’arrivée et précise les émissions produites par le contrôleuren réaction à ces arrivées. Un automate d’états fini est bien adapté à la représention dufonctionnement du contrôleur. Par exemple, le programme BDL suivant :

(ouvrir ; (#lire* / fermer))*

peut être représenté par l’automate 3 présenté sur la figure 3. Sur cet automate, lesymbole « ? » représente une réception d’événement et le symbole « ! » une émission.Le symbole « + » indique un choix exclusif entre plusieurs transitions.

?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer

?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire


?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer?TERM_fermer.!RETOUR_fermer ?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer

?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire


?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir?TERM_ouvrir.!RETOUR_ouvrir

?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir?ARRIVEE_ouvrir.!DEBUT_ouvrir

?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer+?ARRIVEE_fermer.!EXEC_IMPOSSIBLE_fermer

?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE?ARRIVEE_fermer.!EXEC_IMPOSSIBLE

?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire+?ARRIVEE_lire.!EXEC_IMPOSSIBLE_lire

?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire?TERM_lire.!RETOUR_lire

?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer?ARRIVEE_fermer.!DEBUT_fermer

?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire?ARRIVEE_lire.!DEBUT_lire

?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.?ARRIVEE_ouvrir.!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir!EXEC_IMPOSSIBLE_ouvrir

Figure 3. Automate du programme BDL « (ouvrir ; (#lire* / fermer))* »

L’utilisation d’un automate comme structure de contrôle présente les intérêts sui-vants :

— efficacité : la description d’un automate dans un langage de programmationproduit, après compilation, un code exécutable efficace. Cette efficacité est importantecar ce code est destiné à être exécuté fréquemment et il est souhaitable que l’objet(c’est-à-dire son contrôleur) réponde rapidement à une demande d’exécution ;

— vérification : les automates sont des modèles mathématiques pour lesquels denombreux outils de vérification ont été développés.

Produire directement un automate à partir d’un programme BDL est possible maisune grande partie de ce travail a déjà été réalisée par les langages réactifs. De plus

3. L’état initial figure en haut à gauche (double cercle).


de nombreux outils de vérification, avec lesquels ces langages sont interfacés, ont étédéveloppés.

Les compilateurs des langages réactifs produisent un automate utilisé à la fois parles outils de vérifications et par des translateurs pour générer un code C, ADA ou toutautre langage permettant de décrire l’automate.

Dans la section 3.5.1, nous avons montré que l’exécution d’une méthode pouvaitêtre représentée par une séquence d’événements, le contrôleur qui gère cette séquencese comporte comme un système réactif.

Nous avons choisi d’utiliser le langage réactif synchrone ESTEREL [BER 92] com-me langage cible car il offre des structures de contrôle de haut niveau et égalementpour la richesse de son environnement de développement (notamment son interfaçageavec différents outils de vérification). Cependant nous avons conservé l’hypothèsed’asynchronisme du langage réactif ELECTRE en ne traitant qu’un seul événement enentrée à la fois. La traduction des opérateurs BDL en ESTEREL et la réalisation ducompilateur permettant l’obtention de ce module est décrite dans [BER 96].

3.6. Intégration du contrôle dans un langage à objets concurrents

Les langages à objet offrent deux techniques de construction de classes, l’héritageet l’agrégation.

3.6.1. Héritage et comportement

Le mécanisme d’héritage des langages à objets induit des conflits avec la syn-chronisation du fonctionnement (cf. section 2.2). Comme l’ont montré les auteursde [MAT 93], ces problèmes (anomalie d’héritage) peuvent être minimisés en sépa-rant l’expression de la synchronisation du code des méthodes. Cette technique permetde ne réécrire que le code nécessaire. Cependant elle implique l’existence d’états abs-traits utilisés uniquement par le code de synchronisation. En particulier, les change-ments d’état sont réalisés par le code de synchronisation en dehors des méthodes.

Notre modèle, qui suit ces recommandations, sépare complètement l’expressionde synchronisation du code des méthodes.

Néanmoins cette technique laisse de côté des anomalies qui peuvent entraîner leblocage du système comme le montre l’exemple suivant.

Soit une classe C1 dont l’expression de synchronisation est « m1 ; m2 » repré-sentant une exécution séquentielle. Soit une classe C2 héritant de C1 et définissant unenouvelle méthode m3. Si l’expression de synchronisation de C2 est représentée par« (m1 |||m3 ) ;m2 » alors il existe une anomalie. En effet, si nous regardons lesévénements de sortie en utilisant l’ensemble des événements définis à la section 3.5.1,un objet instance de C2 peut avoir comme comportement la trace

début_m3 ! retour_m3 ! début_m2 ! retour_m2

Ce comportement n’est pas compatible avec les comportements possibles de C 1 carl’exécution de m3 conduit l’instance dans un état qui permet d’exécuterm 2 sans avoir,


au préalable, exécuté m1 (cf. figure 4). Donc cet objet ne se comporte pas comme uneinstance de C1. Ces anomalies résultent de la « non compatibilité » entre l’abstractioncomportementale d’un objet d’une classe C1 et l’abstraction comportementale d’unobjet d’une classe C2 héritant de C1.

?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2#ARRIVEE_m1.!RETOUR_m2

?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1?ARRIVEE_m1.!DEBUT_m1

?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3 #TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3

?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1?TERM_m1.#ARRIVEE_m1.!RETOUR_m1

?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.?ARRIVEE_m2.#ARRIVEE_m3.#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2#ARRIVEE_m1.!DEBUT_m2


?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3

?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.?TERM_m3.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3



?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.?TERM_m3.#TERM_m1.#ARRIVEE_m3.#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3#ARRIVEE_m1.!RETOUR_m3

Figure 4. Automate 4 de C2 décrivant le programme BDL « (m1 ||| m3) ; m2 »

Nous allons préciser cette notion de compatibilité mais auparavant nous indiquonsque l’ensemble M des méthodes d’une classe C est noté C:M = fm1;m2; : : : ;mng.

Soit b une instance de la classe C2, comme C2 hérite de C1, à chaque instant, b estdans un état s1 ou s0

1selon le point de vue adopté (b est un C2 ou b est un C1). Un

changement d’état résulte du démarrage de l’exécution d’une méthode ou de sa termi-naison. À la suite de cette exécution, l’objet doit pouvoir être considéré comme étantdu type C1 et du type C2. À chaque point de vue correspond un automate (A) représen-tant une abstraction du comportement (A1 est associé à la classe C1 et A2 est associéà la classe C2). L’action d’une méthodem 2 C1:M conduit à une transition d’étiquettem dans A1 mais aussi dans A2. Et, réciproquement, l’action d’une méthode de C 2conduit à une transition dans A2 et aussi dans A1. Mais, dans ce dernier cas, une mé-thode qui n’est que dans C2 conduit à une transition non observable (�-transition) dansA1.

Le modèle formel de COSTA et SERNEDAS [COS 94] utilise une notion d’homo-morphisme de traces pour étudier les relations qui existent entre une classe et la classedont elle hérite. Cette propriété est trop faible si on permet aux instances d’être consi-

4. Pour des raisons de lisibilité, les étiquettes des transitions maintenant dans un même état ont étémasquées (figures 4 et 5)


dérées au cours du fonctionnement comme des objets de la classe héritée ou de laclasse dont on hérite. L’exemple suivant illustre ce propos. Soit une classe C 1 dontl’expression de synchronisation consiste en « m1 ;m2 », et une classe C2, héritant deC1, définissant une nouvelle méthode m3. Si l’expression de synchronisation de C2 est« (m1 ||m3 ) ;m2 », un objet instance de C2 peut avoir comme comportement

début_m1 ! retour_m1 ! début_m3 ! retour_m3 ! début_m2 ! retour_m2

or ce comportement est en relation par un homomorphisme de traces avec le compor-tement

début_m1 ! retour_m1 ! début_m2 ! retour_m2

des instances de C1. Cependant il n’est pas compatible avec les comportements pos-sibles de C1. L’exécution de m1 conduit l’instance dans un état qui ne permet pas,selon le point de vue C1, d’exécuter m2 or cette exécution est impossible selon lecomportement de C2 (cf. figure 5).

?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2?TERM_m2.#ARRIVEE_m2.#ARRIVEE_m1.!RETOUR_m2


#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#TERM_m1.?ARRIVEE_m3.#ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3#ARRIVEE_m1.!DEBUT_m3








?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2?ARRIVEE_m2.#ARRIVEE_m1.!DEBUT_m2



?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3?TERM_m3.#TERM_m1.#ARRIVEE_m1.!RETOUR_m3

Figure 5. Automate de C2 décrivant le programme BDL « (m1 || m3) ; m2 »

Dans le programme JAVA ci-dessous le transtypage de l’instance unC2 en instancede type C1, après appel à m1(), conduirait à un blocage du fonctionnement de unC2 :

unC2 = new C2();unC2.m1();((C1) unC2).m2();


En se fondant sur ces remarques nous proposons une technique de vérification dela compatibilité entre le comportement d’un objet vu comme une instance de C 2 et lecomportement du même objet vu comme une instance de C 1 dont hérite C2.

La solution adoptée consiste à vérifier qu’à chaque instant, si l’événement d’entréeappartient à farrivée_mi, terminaison_mi j mi 2 C1:Mg pour mi 2 C1:M alorsl’événement de sortie (appartenant à fdébut_m i, retour_mi j mi 2 C1:Mg) de A1 estle même que l’événement de sortie de A2 c’est-à-dire que :

« À chaque instant la présence d’un événement de C1:M en sortie de A1

est équivalente à la présence du même événement en sortie de A2. »

3.6.2. Agrégation et comportement

Dans un objet composé (agrégat), les conditions d’exécution des méthodes de l’ob-jet composé peuvent dépendre de celles des objets composants. Par exemple, le brasd’un pont roulant ne peut se déplacer que si la tête qui le compose est en positionhaute. En conséquence le comportement d’un objet composé ne peut pas être déduitindépendamment du comportement de ses composants. L’automate qui représente lecomportement peut avoir à se référer à l’état des composants. Nous avons choisi desubstituer au contrôleur de chaque objet composant, un contrôleur unique. L’objetcomposé et les objets composants se réfèrent au même contrôleur évitant ainsi touteincohérence. Les objets composants sont alors considérés comme des objets passifs etsont sous la dépendance directe du contrôleur de l’objet agrégat. Cette substitution nepose pas de problèmes pratiques de réalisation car l’indépendance entre le contrôle etles opérations de l’objet font du contrôleur un module interchangeable.

Cette approche peut être illustrée par l’exemple d’un four à micro-ondes. Une ins-tance de la classe FourMO est constituée par l’agrégation d’une instance d’une classeGenerateurMO possédant deux méthodes marche et arret, et d’une instance dela classe Porte offrant deux autres méthodes : ouvrir et fermer. L’expression ducontrôle pour la classe GenerateurMO est la suivante :

(marche / arret)*

où la méthode marche exerce une action continue (émission des micro-ondes) et doitêtre stoppée par préemption.

Pour la classe Porte nous avons l’expression suivante :

(ouvrir ; fermer)*

Lors de la construction de l’agrégat, il est substitué au contrôleur de chaque objetle contrôleur associé à la classe FourMO dont le code BDL est le suivant :

((marche / arret) | (ouvrir ; fermer))*

Le problème conceptuel que pose une telle substitution est le suivant :

« le comportement d’un objet composant est-il compatible avec celui dumême objet vu comme entité indépendante de la composition?... »


Cette question se résout en utilisant des outils de vérification.L’utilisation d’un langage réactif pour exprimer les comportements permet de vé-

rifier que le comportement d’un objet composé est compatible avec celui de l’objetcomposant défini indépendamment de la relation de composition. Nous montrons dansla section 5 comment cette vérification peut être réalisée et proposons pour l’exemplede la classe FourMO une autre expression de synchronisation permettant d’ouvrir lefour en stoppant l’émission des micro-ondes.

Étant donné le comportementA1 d’un agrégat C1 comprenant un composant ins-tance d’une classe C2, il faut vérifier queA1 est compatible avec le comportementA2

de ce composant. La solution adoptée consiste à vérifier qu’à chaque instant pour unévénement d’entrée appartenant à farrivée_m i; terminaison_mijmi 2 C1:Mg si l’évé-nement de sortie (appartenant à fdébut_m i; retour_mijmi 2 C1:Mg) deA1 appartientà C2:M alors l’événement de sortie de A2 est le même.

4. Un exemple de modélisation : l’objet convoyeur

4.1. Présentation de l’exemple

L’atelier flexible a été retenu comme sujet d’étude de cas du projet KORSO. Nousavons repris l’exemple présenté dans [LEW 94] mais la réalisation que nous en faisonsest différente pour obtenir un simulateur réparti. Dans notre modélisation, l’atelierflexible est représenté par un ensemble d’objets qui peuvent être répartis sur diffé-rentes machines.

L’atelier flexible servant de modèle (voir figure 6) se compose :

— de deux convoyeurs munis de capteurs permettant de détecter la présence d’unepièce ;

— de deux ponts roulants ;

— de quatre machines-outils ;

— d’un panneau de commande ;

— et d’un panneau de contrôle qui permet de visualiser les déplacements.

Pour illustrer la modularité du contrôle, nous présentons l’objet convoyeur d’en-trée.


convoyeurs

machines-outils

ponts roulants

Figure 6. Atelier flexible tel qu’il apparaît sur l’écran de contrôle

4.2. Modèle objet

Un convoyeur, représenté par une instance de la classe Convoyeur, est modélisécomme un processus qui exécute une méthode « privée » avancer correspondant àl’avance du tapis roulant. Les opérations offertes par l’objet convoyeur sont :

— marcheArret : mise sous tension ou coupure de l’alimentation appelée àpartir du panneau de contrôle ;

— avancer : met en marche le moteur faisant avancer le tapis roulant ; cette mé-thode est privée, et son exécution est déclenchée par la fin d’exécution de la méthodeajouterPiece ;

— ajouterPiece : cette méthode est appelée par le panneau de contrôle pourindiquer au convoyeur de transporter une pièce ;

— retirerPiece : cette méthode est appelée par un pont roulant pour indiquerqu’une pièce a été prise ;

— stop : cette méthode est appelée par le capteur qui détecte une pièce en fin detapis, elle déclenche l’arrêt du tapis ;

— appelPont : cette méthode appelle le groupe de portiques pour demanderque la pièce en bout de tapis roulant soit enlevée ; cette méthode est privée, et sonexécution est déclenchée par la fin d’exécution de stop.

Modèle du comportement

Le comportement est décrit par une expression BDL qui spécifie l’ordonnance-ment admissible des exécutions. Le code du contrôleur qui est exécuté est celui produitpar la compilation de cette expression.


Si on souhaite qu’un seul objet soit présent sur le tapis, l’expression BDL du com-portement du tapis roulant d’entrée est :

(marcheArret ;( ( # ajouterPiece ; ! avancer / stop ) ;

( ! appelPont ; # retirerPiece ) ) */ marcheArret ) *

Cette expression signifie qu’on désire, après la mise sous tension du convoyeuret dès qu’une pièce est déposée sur le tapis roulant, que celui-ci se mette en marche(l’automaticité de l’enchaînement du dépôt de la pièce et de l’avance du tapis estindiquée par le qualificateur « ! »). L’avance du tapis se déroule jusqu’à ce que lecapteur détecte la pièce au bout du tapis et demande son arrêt. Après l’arrêt du tapis,la pièce est en attente jusqu’à son enlèvement. La séquence de dépôt et de prise estrépétée tant que le convoyeur est sous tension. Les méthodes ajouterPiece etretirerPiece sont qualifiées de non interruptibles (qualificateur « # »), ainsi touteinterruption laisse le système dans un état correct.

Au cours du cycle de vie du simulateur, après avoir testé ce comportement, leconcepteur peut souhaiter modifier le comportement pour que plusieurs pièces puissentêtre transportées par le tapis roulant. Dans ce cas, le comportement de l’objet est décritpar l’expression BDL suivante :

( marcheArret ;( # ajouterPiece ;

( ( ! avancer ||| # ajouterPiece ) * / stop ;! appelPont ; # retirerPiece ) * )

/ marcheArret ) *

Cette modélisation suppose que les appels à ajouterPiece ne sont pas troprapides par rapport à l’avance de tapis roulant sinon les pièces risquent de se chevau-cher. Elle suppose aussi que le temps d’exécution de ajouterPiece n’est pas tropgrand pour éviter qu’une pièce détectée ne tombe du tapis du fait qu’au moment del’appel à stop la méthode ajouterPiece était en cours d’exécution.

5. Vérification de propriétés

La vérification de propriétés représente une étape importante dans le cycle de vied’un objet. Un des principaux avantages de la programmation par objets est la possi-bilité, pour un objet, d’être facilement réutilisé par plusieurs applications. Pour éviterqu’une erreur dans la conception d’un objet soit propagée aux applications qui l’uti-lisent, il est important de s’assurer que l’objet se comporte correctement vis-à-vis desspécifications qui ont guidé son développement.


La conception d’un programme de contrôle du comportement repose donc surl’utilisation d’outils de vérification. L’expression BDL du comportement, après com-pilation du code ESTEREL, produit un automate représenté par un ensemble d’équa-tions booléennes (au format BLIF 5). Les propriétés de cet automate (et donc du com-portement de l’objet) peuvent être vérifiées au moyen d’outils utilisant ce format telque XEVE [BOU 97].

5.1. Vérification de propriétés comportementales d’un système

Les propriétés comportementales auxquelles nous nous intéressons appartiennentà deux catégories :

— les propriétés de sûreté définissant ce que l’on veut éviter ; par exemple : « lebras d’un pont roulant ou son chariot ne doit pas se déplacer si ce dernier n’est pasen position haute » ;

— les propriétés de vivacité définissant ce qui doit être finalement possible. Cespropriétés sont délicates à énoncer car elles expriment des évidences mais leur véri-fication pose souvent des problèmes. Ce que l’on vérifie surtout c’est l’absence d’in-terblocages. Par exemple : « chaque pièce prise par un pont roulant, doit finalementpouvoir être déposée sur une machine ou sur le convoyeur de sortie. »

5.1.1. Exemple de vérification d’une propriété de sûreté

Pour illustrer cette étape de vérification nous allons prendre comme exemple lavérification d’une propriété de sûreté concernant le convoyeur d’entrée de l’atelier.Nous rappelons ici cette propriété :

« Lorsqu’une pièce est prise, le tapis est arrêté. »

La vérification consiste à montrer qu’il n’existe pas de cas où retirerPieces’exécute alors que la méthode avancer est active. Pour vérifier que ce cas ne peutse produire, l’approche consiste à rechercher une situation inverse de celle à vérifierc’est-à-dire, dans notre cas, détecter une trace d’exécution où retirerPiece dé-marre alors que avancer est toujours en cours d’exécution. Il est important de noterici qu’on se place dans la situation où les méthodes d’un même objet ne s’appellentpas entre elles. D’autre part, la méthode est vue comme une unité d’exécution ne com-portant pas de point de synchronisation avec d’autres méthodes.

5. Berkeley Logical Interchange Format.


Le programme BDL décrivant le contrôle du convoyeur (présenté p. 19) est toutd’abord compilé pour obtenir un code ESTEREL. Puis, à ce programme est adjoint, parcomposition parallèle, un module de type observateur dont le rôle consiste à détecterles violations de la propriété à vérifier. Le code ESTEREL de cet observateur est donnéci-dessous :

await immediate DEBUT_avancer;% à ce stade, la méthode avancer est activeabort

% attente du demarrage de retirerPieceawait DEBUT_retirerPiece do

% à ce point, les deux méthodes sont actives% donc la propriété est violée...emit PROPRIETE_VIOLEE

end% l’attente se fait jusqu’à ce que la% methode avancer ne soit plus activewhen [ STOP_avancer or TERM_avancer ]

Après compilation, l’automate obtenu est soumis à XEVE. La vérification des évé-nements de sortie fait apparaître que l’événement PROPRIETE_VIOLEE ne peut êtreémis dans aucun cas d’exécution et donc que la propriété est vérifiée.

L’écriture de tels observateurs peut être réalisée directement mais le code d’un ob-servateur peut aussi être généré automatiquement en utilisant un outil appelé TEMPEST

[JAG 95]. Cet outil permet d’exprimer les propriétés à vérifier en utilisant une logiquetemporelle, les formules étant directement traduites en ESTEREL. Avec TEMPEST, lapropriété précédente s’écrirait :

Inputs: DEBUT_retirerPiece, TERM_stop, DEBUT_avancer;

P0 := { Previous DEBUT_avancer }

P1 := { P0 & DEBUT_retirerPiece }

PROP := { P1 -> ( AllPast ( TERM_stop Since DEBUT_avancer )) }

Safety := Always { PROP }

5.1.2. Exemple de vérification d’une propriété de vivacité

Un autre intérêt de notre approche concerne la vérification de propriétés de vi-vacité. En reprenant l’exemple du four à micro-ondes (section 3.6.2, p. 16), il estintéressant de vérifier la propriété suivante : « Quand le four fonctionne, une demanded’ouverture de la porte sera finalement satisfaite ».


Cette propriété peut être vérifiée par un observateur dont le code ESTEREL estprésenté ci-dessous :

await immediate DEBUT_marche;abort

await ARRIVEE_ouvrir;present [not DEBUT_ouvrir or not STOP_marche] then

emit PROPRIETE_VIOLEEend

when [TERM_marche or STOP_marche]

Dans cet observateur nous avons pris l’hypothèse que la demande doit être immédia-tement satisfaite.

La vérification montre que cette propriété peut être violée lorsqu’une demanded’exécution pour ouvrir survient durant l’exécution de marche car, dans ce cas, laméthode arret doit au préalable être exécutée. L’expression BDL ci-dessous résoutce problème.

((marche / (arret | (ouvrir ; fermer))))*

La détection d’interblocages rentre également dans le cadre de la vérification depropriétés de vivacité. Dans ce cas, on considère, contrairement à l’hypothèse précé-dente, que les méthodes d’un même objet peuvent s’appeler entre elles, ce qui peutconduire à un interblocage. Considérons un objet possèdant deux méthodes m 1 et m2

dont le comportement est exprimé en BDL par « m1 ; m2 ». Si la méthode m1 aucours de son exécution appelle m2 il en résulte un interblocage car le contrôleur n’au-torise l’exécution de m2 que si m1 est terminée et, d’autre part, m1 attend la fin dem2 pour se terminer.

Dans cette situation, nous avons développé une technique proche de celle des ob-servateurs. Le graphe des appels est modélisé par un programme ESTEREL qui simuleles appels. Ce programme est alors mis en parallèle avec le programme exprimant lecomportement du contrôleur. Le concepteur peut alors, en utilisant les outils de vé-rifications associés à ESTEREL, vérifier que l’événement de terminaison de m 2 n’estjamais émis.

5.2. Vérification de compatibilité de comportement

Dans cette partie, nous nous intéressons à la vérification de compatibilité entredeux classes liées soit par héritage, soit par agrégation. La technique mise en ouvrerepose également sur le principe de l’observateur. La figure 7 montre l’approche suivieoù un observateur vérifie les propriétés sur les événements de sortie de deux contrô-leurs.


Contrôleur C1

Contrôleur C2

Observateur (Propriété à vérifier

entre S et S’)

Relation d’héritageou d’agrégation

S

S’

S’’

E

Émission d’unsignal s’il existe uncas où la propriété

peut être violée

Figure 7. Vérification de propriétés de compatibilité grâce à un observateur

5.2.1. Exemple de vérification de compatibilité de l’héritage

Pour illustrer cette vérification nous considérons une classe Chariot dont lecontrôle du comportement est défini par le programme BDL suivant :

(init ; ((avancer | reculer) / stop ))*

Pour fonctionner correctement, une instance de cette classe doit d’abord recevoirune demande d’exécution pour sa méthode d’initialisation (init) puis le chariot peutsoit avancer, soit reculer. Durant l’exécution d’une de ces deux méthodes, ilpeut être nécessaire de stopper tout mouvement du chariot pour des raisons de sécurité.C’est la fonction de stop qui préempte avancer ou reculer.

De cette classe Chariot, nous dérivons une classe ChariotElevateur quiest contrôlée par l’expression BDL suivante :

(init ; (((avancer | reculer) ||| (monter | descendre)) / stop ))*

La vérification consiste à s’assurer qu’à chaque fois qu’un événement de typedébutm ou retourm est présent en sortie du contrôleur de la classe Chariot (c’est-à-dire que m 2 Chariot:M = finit; avancer; reculer; stopg) alors cet événement estégalement présent en sortie du contrôleur de ChariotElevateur. La réciproquedoit également être vérifiée pour m 2 Chariot:M .

La structure de l’observateur est constituée d’une mise en parallèle de branchesayant la structure suivante :

present [ ( CHARIOT_evt_sortie_m and not CHARIOT_ELEV_evt_sortie_m )or ( not CHARIOT_evt_sortie_m and CHARIOT_ELEV_evt_sortie_m ) ]

thenemit PROBLEME_evt_sortie_m

end present


La structure des clauses logiques provient de l’équivalence :

:(p, q), (p ^ :q) _ (:p ^ q)

La vérification montre qu’aucun événement PROBLEME_evt_sortie_m ne peutêtre émis. Ceci montre que le contrôle du comportement de la classe ChariotE-levateur est bien compatible avec celui de sa super-classe Chariot.

5.2.2. Exemple de vérification de compatibilité de l’agrégation

Cet exemple concerne le four à micro-ondes dont le comportement est donné parl’expression BDL suivante :

((marche / (arret | (ouvrir ; fermer))))*

Ici la question est : le comportement de l’objet fourMO (agrégat) est-il compatibleavec le fait que l’un des composants est un objet de type Porte possèdant le compor-tement « (ouvrir ; fermer)* »?

La vérification s’effectue en utilisant la technique donnée à la section 3.6.2. Lesoutils de vérification de la famille FC2TOOLS [BOU 94] permettent :

1. de construire un automate, produit synchrone de l’automate du comportementde l’agrégatA1 (objet fourMO) et de celui du composantA2 (objet porte).

2. de vérifier, en utilisant un observateur, que pour chaque événement de sortie lapropriété suivante est satisfaite :

agrégat.evt_sortie ) composant.evt_sortie

L’observateur compare à chaque instant les événements de sortie appartenant àfourMO:Evt

Tporte:Evt et produit un événement de violation de la propriété

si, l’événement s 2 fourMO:EvtTporte:Evt étant présent, le même événement

n’est pas présent en sortie de contrôleur de l’objet porte.Sachant que (p) q), (:p _ q), le code de cet observateur est le suivant :

[present [FOUR_DEBUT_ouvrir and not PORTE_DEBUT_ouvrir] then

emit VIOLATION_DEBUT_ouvrirend present

||present [FOUR_DEBUT_fermer and not PORTE_DEBUT_fermer] then

emit VIOLATION_DEBUT_fermerend present

||present [FOUR_RETOUR_ouvrir and not PORTE_RETOUR_ouvrir] then

emit VIOLATION_RETOUR_ouvrirend present

||present [FOUR_RETOUR_fermer and not PORTE_RETOUR_fermer] then

emit VIOLATION_RETOUR_fermerend present

]


On peut constater ici que cette agrégation est compatible avec le comportement dufour à micro-ondes et de la porte.

6. Mise en œuvre du modèle avec JAVA

Nous avons mis en œuvre notre modèle avec JAVA. La mise en œuvre du modèlen’est pas liée à un langage à objets particulier. Notre décision vient du fait que lecode initial correspondant à la visualisation de l’atelier était déjà disponible et écrit enJAVA 6. Si JAVA présente certains avantages, comme sa portabilité, sa gestion intégréedes fils d’exécution (threads), il comporte néanmoins quelques inconvénients pournotre mise en œuvre :

— l’absence d’héritage multiple est gênante car une classe d’objets doit pouvoirhériter de la classe de base ReactiveObject — regroupant les fonctionnalités debase d’un objet réactif — et d’une autre classe. Il existe néanmoins certaines possibi-lités pour contourner ce problème (voir [LAF 97, p. 20]) ;

— l’absence de références sur les méthodes conduit à utiliser un mécanisme d’in-trospection, un peu lourd, qui permet, en interrogeant une classe, de récupérer un objetMethod puis de demander son exécution — le passage des paramètres n’étant pas trèssimple.

L’appel d’une méthode par un objet client commence par la création d’un objetPolicyHandler qui permet de gérer la politique d’appel du client. Cette classepermet, entre autre, de gérer l’asynchronisme d’un appel.

Lorsque l’appel parvient à l’objet destinataire, il déclenche la création d’une ins-tance de type ExecRequest, objet mémorisant l’ensemble des paramètres néces-saires à l’exécution de la requête (comme, par exemple, l’instance de Method corres-pondant à la méthode appelée). Ce type est ensuite utilisé comme type des événementsarrivée présents en entrée de l’automate. L’instance ExecRequest est alors trans-mise au contrôleur de l’objet — contrôleur dont la classe hérite de Controller— qui produit un événement de type arrivée en entrée de l’automate. Cette classeController est une classe abstraite contenant deux références : l’une à l’automateassocié, l’autre à une file où sont mémorisées les demandes d’exécution en attente.

L’interface entre l’automate décrit avec ESTEREL et le contrôleur, écrit en JAVA

s’effectue en traduisant la description explicite de l’automate (format oc produit parle compilateur ESTEREL) en JAVA grâce un traducteur ocjava. Ce traducteur produitdeux classes JAVA :

— une classe Automaton représentant l’automate et comportant des méthodespermettant d’indiquer la présence d’événements en entrée ; le nom de ces méthodes estde la forme input{ARRIVAL_ | TERM_}méthode_appelée. La présence de l’événe-ment est alors validée par une méthode run qui fait réagir l’automate sur ses entrées ;

— une classe AutomatonInterface comportant des méthodes permettant à

6. Ce code est disponible à l’URL suivante : http://www.fzi.de/divisions/prost/projects/korsys/java_simulation.html.


unClient unServeur uneDemande unControleur unAutomate uneInterfAutomate uneExecMethode(PolicyHandler) (ExecRequest) (MyController) (Automaton) (AutomatonInterface) (MethodProcess)

Création du threaddestiné à exécuter

la méthode

Point de synchronisationpour attendre la fin

d’exécution de la méthode

Tentatived’exécution d’unedemande en attente

Pas de méthode,donc fin du thread

Figure 8. Diagramme de séquence dans le cas d’un appel normal en mode synchrone

l’automate d’indiquer la présence d’événements en sortie. Ces méthodes sont de laforme out{START_ | DONE_}méthode_appelée et l’utilisateur de l’automate doitdéfinir le code pour indiquer les actions à effectuer lors de l’émission de l’événement.Ici, l’action à réaliser consiste à exécuter la méthode passée en paramètre par l’in-termédiaire de l’instance de Method en créant un objet de type MethodProcess,classe héritant de Thread.

Si l’exécution de la méthode n’est pas possible (émission de EXEC_FAILED parl’automate), le contrôleur mémorise la demande d’exécution dans une file d’attente.Cette demande sera soumise de nouveau au contrôleur dès qu’une méthode terminerason exécution.

La figure 8 décrit le diagramme de séquence intervenant lors d’un appel normal enmode synchrone.


7. Conclusion

Le modèle des objets à contrôle réactif permet la conception de programmes àobjets concurrents. Ce modèle sépare le contrôle de la concurrence de l’expressiondes transformations. Pour cette raison, le contrôle est exprimé dans un composantde l’objet — le contrôleur réactif — qui a en charge de contrôler l’exécution desméthodes, entités dont le rôle est d’exprimer les transformations de l’état des objets.

Le modèle des objets à contrôle réactif permet une conception plus claire en sépa-rant les problèmes de synchronisation de ceux de la programmation des transforma-tions. Il permet aussi une expression plus aisée de la synchronisation en permettantl’utilisation d’un langage de synchronisation (BDL) de haut niveau. De plus, cetteséparation répond aux exigences d’indépendance entre synchronisation et transforma-tion nécessaires à la réduction des anomalies d’héritage.

L’expression de la concurrence est répartie sur chaque objet mais centralisée ausein de chaque objet. Ce choix permet une vision plus claire et plus facile à maîtriserdu comportement.

Les synchronisations étant exprimées par l’intermédiaire d’un langage réactif,l’automate représentant le comportement peut être éventuellement visualisé, le fonc-tionnement de l’objet peut être simulé et il est possible de vérifier que des propriétéscomportementales souhaitées sont satisfaites. Ces propriétés peuvent être des proprié-tés d’ordonnancement entre les méthodes de l’objet mais également des contraintes,entre méthodes, résultant de constructions comme l’héritage ou l’agrégation. Le choixd’un langage réactif apporte aussi une plus grande confiance dans le processus deconception dans la mesure où le code produit par les langages réactifs et sur lequelporte la vérification est le même que celui utilisé lors de l’exécution du programme.

L’utilisation des objets à contrôle réactif serait facilitée par un outil intégré deconception permettant l’édition, la vérification et la compilation d’une classe. Actuel-lement, si la compilation d’une expression BDL en ESTEREL puis en JAVA est automa-tique et si un paquetage JAVA (Reactive) existe pour définir les principales classes(Controller, PolicyHandler, MethodProcess, ExecRequest, ...) assu-rant ainsi une plus grande cohérence de conception, la réalisation des interfaces entreles méthodes de l’objet et l’automate est manuelle. De même, l’utilisation des outilsde vérification n’est pas intégrée à un environnement de développement.

Les travaux que nous menons actuellement portent sur la réalisation d’un outilintégrant l’ensemble des étapes de mise en œuvre et de vérification. Cet outil doitparticiper au développement d’un système d’aide à la navigation de véhicules auto-mobiles, projet mené au sein du laboratoire L3i.

Remerciements

Les auteurs tiennent à remercier le Conseil Régional Poitou-Charentes pour sonsoutien financier à ces travaux et les lecteurs anonymes pour l’aide qu’ils leur ontapportée.


8. Bibliographie

[AME 87] AMERICA P., POOL-T: A Parallel Object-Oriented Language. SHRIVER B. etWEGNER P., Eds., Research Directions in Object-Oriented Programming, p. 199–220. MITPress, Cambridge, Massachusetts, 1987.

[AUG 92] AUGERAUD M., « A Reactive Part to Specify Dynamic Object Behavior ». Indo-French workshop on object-oriented systems, novembre 1992.

[BEN 92] BENVENISTE M. et ISSARNY V., « Arche : Un langage parallèle à objets fortementtypé ». Rapport technique 1646, INRIA, mars 1992.

[BER 92] BERRY G. et GONTHIER G., « The ESTEREL Synchronous Programming Lan-guage: Design, Semantics, Implementation ». Science Of Computer Programming, vol. 19,no 2, p. 87–152, 1992. ftp://ftp-sop.inria.fr/meije/esterel/papers/BerryGonthierSCP.ps.gz.

[BER 95] BERTRAND F. et AUGERAUD M., « Un modèle de contrôle réactif pour les lan-gages à objets concurrents ». Actes du Congrès Biennal de l’AFCET, p. 75–84, Toulouse,FRANCE, octobre 1995. AFCET. http://www-l3i.univ-lr.fr/L3I/equipe/fbertran/pub/afcet95.ps.gz.

[BER 96] BERTRAND F., « Un modèle de contrôle réactif pour les langages à objets concur-rents ». Thèse de doctorat, Université de La Rochelle, L3I, Avenue Marillac, 17042 LaRochelle Cedex, janvier 1996.

[BER 99] BERTRAND F. et AUGERAUD M., « BDL: A Specialized Language for per-ObjectReactive Control ». IEEE Transactions on Software Engineering, a paraître, 1999.

[BOU 94] BOUALI A., RESSOUCHE A., DE SIMONE R. et ROY V., « The FCTOOLS Re-ference Manual ». INRIA / ENSMP-CMA, Sophia-Antipolis, FRANCE, 1994. ftp://ftp-sop.inria.fr/meije/verif/primer.ps.gz.

[BOU 97] BOUALI A., « Xeve: an Esterel Verification Environment ». Rapport tech-nique 0214, INRIA, décembre 1997. ftp://ftp-sop.inria.fr/meije/verif/RT-214.ps.gz.

[BRI 96] BRIOT J. et GUERRAOUI R., « Objets, parallélisme et répartition ». Technique etscience informatiques, vol. 15, no 6, p. 765–800, 1996.

[CAM 73] CAMPBELL R. H. et HABERMAN N., « The Specification of Process Synchroniza-tion by Path Expressions », p. 89–102. Springer Verlag, décembre 1973.

[CAR 93] CAROMEL D., « Toward a method of object-oriented concurrent programming ».Communications of the ACM, vol. 36, no 9, p. 90–102, 1993.

[CAS 95] CASSEZ F. et ROUX O., « Compilation of the ELECTRE reactive language into finitetransition systems ». Theoretical Computer Science, vol. 146, juillet 1995.

[COS 94] COSTA J., SERNEDAS A. et SERNEDAS C., « Object Inheritance Beyond Subty-ping ». Acta Informatica, vol. 31, p. 5–26, 1994.

[CRE 91] CRESPI REGHIZZI S., GALLI DE PARATESI G. et GENOLINI S., « Definition of reu-sable concurrent software components ». Proceedings of ECOOP’91, p. 148–166, Geneva,SWITZERLAND, juillet 1991. Springer Verlag.

[FUR 95] FURMENTO N., ROUDIER Y. et SIEGEL G., « Parallélisme et distribution en C++ :une revue des langages existants ». Rapport technique RR 95-02, I3S, Sophia-Antipolis,FRANCE, 1995.


[GUE 95] GUERRAOUI R., « Les langages concurrents à objets ». Technique et science infor-matiques, vol. 14, no 8, p. 945–971, 1995.

[HAL 93] HALBWACHS N., Synchronous programming of reactive systems. Kluwer AcademicPub., 1993.

[HAR 87] HAREL D., « STATECHARTS: a Visual Formalism for Complex Systems ». ScienceOf Computer Programming, vol. 8, p. 231–274, juin 1987.

[JAG 95] JAGADEESAN L. J., PUCHOL C. et VON OLNHAUSEN J. E., « Safety Property Veri-fication of Esterel Programs and Applications to Telecommunications Software ». Procee-dings of Conference on Computer-Aided Verification 1995, Liège, BELGIQUE, juillet 1995.http://www.cs.utexas.edu/users/cpg/TempEst/doc/95-CAV.ps.Z.

[KAF 89] KAFURA D. G. et LEE K. H., « Inheritance in Actor based Concurrent Object-Oriented Languages ». COOK S., Ed., Prooceedings of ECOOP’89. Cambridge UniversityPress, juillet 1989.

[LAF 97] LAFFRA C., Advanced Java : idioms, pitfalls, styles and programming tips. Prentice-Hall, 1997.

[LEW 94] LEWERENTZ C. et LINDNER T., « Case Study "Production Cell": A ComparativeStudy in Formal Software Development ». Rapport technique, Forschungszentrum Infor-matik Karlsruhe, 1994.

[MAC 94] MAC HALE C., « Synchronisation in Concurrent, Object-oriented Languages: Ex-pressive Power, Genericity and Inheritance ». PhD thesis, University of Dublin, De-partment of Computer Science, Trinity College, Dublin 2, Ireland, octobre 1994. ftp://ftp.dsg.cs.tcd.ie/pub/doc/dsg-86.ps.gz.

[MAT 93] MATSUOKA S., TAURA K. et YONEZAWA A., « Highly Efficient and EncapsulatedRe-use of Synchronization Code in Concurrent Object-Oriented Languages ». Proceedingsof OOPSLA’93, p. 109–126, 1993.

[MEY 93] MEYER B., « Systematic concurrent object-oriented programming ». Communica-tions of the ACM, vol. 36, no 9, p. 56–80, 1993.

[PAP 92] PAPATHOMAS M., « Language design rationale and semantic framework for concur-rent object-oriented programming ». PhD thesis, Université de Genève, janvier 1992.ftp://cui.unige.ch/OO-articles/papathomasThesis.ps.Z.

[PNU 85] PNUELI A. et HAREL D., « On the Development of Reactive Systems », vol. F 13 deNATO ASI, p. 477–498. Springer-Verlag Berlin Heidelberg, K.R. Apt édition, 1985.

[ROB 77] ROBERT P. et VERJUS J.-P., Toward Autonomous Descriptions of SynchronizationModules. GILCHRIST B., Ed., Information Processing 77, p. 981–986. North HollandPublishing Company, 1977.

[TOM 89] TOMLINSON C. et SINGH V., « Inheritance and Synchronization with Enabled-Sets ». Proceedings of OOPSLA’89, p. 103–112, New Orleans, Louisiana, octobre 1989.

[WEL 96] WELCH L., HAMMER D. K. et VAN ROOSMALEN O., « A Taxonomy for Distri-buted Object-Oriented Real-Time Systems ». OOPS Messenger, vol. 7, no 1, p. 78–85,janvier 1996.


Article reçu le 12 septembre 1997.Version révisée le 20 janvier 1999.

Rédacteur responsable : J.P. ELLOY

Michel Augeraud est Maître de Conférences à l’Université de La Rochelle et effectue sa re-cherche au Laboratoire d’Informatique et d’Imagerie Industrielle (L3i) dans l’équipe « Lan-gages et architectures à objets ». Il s’intéresse aux aspects dynamiques des systèmes à objets, àleur contrôle et à leur vérification.

Frédéric Bertrand est chercheur au Laboratoire d’Informatique et d’Imagerie Industrielle etMaître de Conférences à l’Université de La Rochelle depuis 1997. Il a réalisé son doctorat surla définition d’un modèle de contrôle réactif pour les langages à objets concurrents. Ses sujetsd’intérêts portent sur la programmation par objets et la vérification.

La Rochelle Université - Objets à contrôle...

Documents

Transcript of La Rochelle Université - Objets à contrôle...