Home

Introduction

1. 257 Table des figures Chapitre Ill D finition des classes d Objets Cooperatifs Figure III 1 Equation fondamentale du mod le 93 Figure II 2 Le formalisme des Objets Coop ratifs et ses formalismes de r f rence 93 Figure III 3 Syntaxe de l interface d une classe 101 Figure II 4 Syntaxe graphique de la pragmatique d une classe 104 Figure ITI 5 BNF de la d finition du marquage initial d une place 0 0 0 ce eecceseesteerseeeeeeeees 106 Figure IIL 6 Sp cification de la classe Fichier 108 Figure II 7 Sp cification de la classe Fichier prot g eeeeeeeeeseceeeeeceseeeceeceeeeeceaeenteaes 110 Figure IIL8 Services d initialisation et de mise jour eee eeecesecseesecneeeeceeeececeaeeeeeaeeateaes 113 Figure III 9 Exemple de transition d invocation ceeeeseeceseeecssecseeeeceeeeecaseeceecaeeeeeaeeateaes 120 Figure III 10 Transition d invocation et d acc s 120 Figure III 11 Impl mentation de la classe Fichier 123 Figure III 12 Impl mentation de la classe Fichier prot g e eeceeecceeeseceseeeceseeeeeseeeeerenee 124 Figure III 13 OPCS de l op ration Ouvrir_en_ criture 125 Figure III 14 OPCS de l op ration Lire 126 Figure III 15 Les deux c t s d une invocation 128 Figure IL 16 S mantique intuitive d une InVOCatiON 129 Chapitre
2. Enfiler lt Marc gt Enfiler 2 lt Jean gt lt ANY 1 gt lt ANY 2 gt lt ANY 3 gt Enfiler lt ANY 4 gt lt Mathieu ANY 1 ANY 2 gt lt Luc gt lt Marc ANY 2 ANY 3 gt lt Luc ANY 3 ANY 4 gt lt ANY 5 gt at ANY 1 AN NY lt lt hieu 7 Y 2 gt lt Marc A 2 NY 3 lt Luc ANY 3 NY 4 lt Jean ANY 4 NY 5 D filer lt ANY 5 gt lt ANY 2 gt lt Marc ANY 2 NY 3 gt lt Mathieu gt lt Luc ANY 3 ANY 4 gt lt Jean ANY 4 NY 5 D filer lt ANY 5 gt lt ANY 3 gt lt Luc ANY 3 ANY 4 gt lt Marc gt lt Jean ANY 4 ANY 5 Figure IL 17 Evolution des marquages pour le motif File PPS YS PY Se VVIVV VIVV Vs On v rifie que les jetons sont bien captur s par la transition D filer dans l ordre o ils ont t trait s par la transition Enfiler D autre part pour que ce motif soit substituable une place il faudrait l encadrer par une place d entr e et une place de sortie toutes deux de capacit 1 qui ne sont pas incluses dans la figure pour plus de simplicit 65 II 2 Extension des RPO b Place Pile De la m me mani re une place g r e comme une pile Premier Arriv Dernier Sorti ou LIFO peut tre mul e par le motif
3. 2 5 Ph 3 SETgauch 3 85 Ph droit Figure IV 9 D finition textuelle de l impl mentation de la classe Table La Figure IV 9 montre la d finition textuelle de l impl mentation de la classe Table les seuls attributs d un objet composite sont des r f rences vers les objets composants la d finition des services offerts est simplement un renommage de services offerts par des instances composantes la d finition graphique quivalente est donn e en Figure IV 10 139 IV 3 Hi rarchie de composition Class Implementation Table Nom 1 Nom 2 Nom 3 STRING Ph 2 Philosophe Chef_de_Table ite i NS Nom Nom 2 Philosophe De pNom Nom 1 garnit le plat garnit le plat pNom Nom 3 garnit le plat donne baguette gauche donne baguette droite Figure IV 10 D finition graphique de l impl mentation de la classe Table 140 IV 3 Hi rarchie de composition 141 Chapitre V S mantique formelle d un syst me d objets coop ratifs Un syst me d Objets Coop ratifs a un comportement non s quentiel et on peut y observer des flots de contr le concurrents qui voluent en parall le ou se synchronisent Intuitivement le comportement du syst me doit r sulter de la combinaison des comportements d crits par les ObCS des objets qui le composent les ObCS communiquant alors par des places partag es Le mod le d ex cution d un syst me d Objets Coop ratifs est alors identiqu
4. Figure V 11 Marquage initial du syst me exemple Etape 5 Gestion du polymorphisme Jusqu ce stade on a consid r que chaque TI concernait toujours des objets de m me classe et on n a pas pris en compte la possibilit de polymorphisme L tape 5 va impl menter le polymorphisme en rassemblant en un seul r seau les ObCS d extension des classes qui sp cialisent une des classes racines de la hi rarchie d h ritage Ceci est r alis en une seule op ration e Toutes les places param tre resp r sultat de chaque transition d accord d un service sont identifi es dans un ensemble de fusion fusion set Huber 89 en descendant la hi rarchie d h ritage Le type de ces places ne d pend que de la signature du service qui est constante pour toute la hi rarchie d h ritage et les places que l on fusionne ont donc bien le m me type e Toutes les places attribut repr sentant un attribut public sont elles aussi fusionn es en descendant la hi rarchie d h ritage cr ant un ensemble de fusion pour chaque attribut public ces nouveaux ensembles de fusion seront utilis s dans l tape suivante pour impl menter les TA Transitions d Acc s un attribut cf IIL 4 3 Cette fusion cr e un nouveau type de conflit entre transitions ce conflit a lieu entre les ObCS des diff rentes classes regroup es par l tape 5 Toutes les transitions d accord d un m me service se trouvent en conflit le long de la hi ra
5. Frappe_le_cours lt e Enseignant b Brouillon gt lt f Fichier word4 gt L ordre n est pas sp cifi la secr taire frappe les cours avec une priorit connue d elle seul Figure VI 5 Exemples de la syntaxe de services ordonnanc s Il nous faut maintenant d crire la mani re dont l ordonnancement des invocations d un service s int gre dans le proc d de reconstruction du WSCS d crit en V 3 Comme on l a d fini en I1 2 7 les places faiblement tri es mention Soft sont une extension au formalisme des RPO ce m canisme tend explicitement le pouvoir d expression du formalisme et il n est pas possible de trouver un motif quivalent qui se restreigne la d finition de base des RPO La d finition d un service ordonnanc de mani re faible n a donc pas d influence sur le proc d de construction du WSCS mis part le fait que la place param tre de ce service doit tre faiblement tri e Les places fortement tri es mention Hard au contraire sont impl ment es comme une abr viation des RPO et une telle place g n re donc un motif particulier qui en tient lieu La d finition d un service ordonnanc de mani re forte doit donc tre prise en compte lors de la construction du WSCS Le motif correspondant au crit re de tri de la place doit tre ins r lors des tapes 1 et 2 du proc d au moment o sont introduites les places param tres L ordre porte toujours sur la prise en compte de
6. La figure VII 23 pr sente la repr sentation externe de l interface La fen tre dialogue pr sente trois sous fen tres distinctes e Une zone d dition dans laquelle les attributs du n uplet s lectionn peuvent tre dit s par l interm diaire d l ments de dialogue standard boutons radio cases cocher zones de textes IBM 89 e Une zone de d filement qui montre la liste des n uplets pr sents dans la table en affichant uniquement la valeurs de leur attribut cl Les l ments de cette liste sont s lectionnables en les pointant avec la souris e Une zone de commande qui permet de d clencher les primitives du SGBD cr ation suppression remplacement en cliquant sur des boutons poussoir Nous avons ajout le bouton R tablir qui permet d annuler les modifications effectu es sur un n uplet et de restaurer son tat initial b Abstraction Plusieurs choix sont possibles pour identifier l Abstraction c est dire l objet essentiel ind pendant de toute interface de manipulation qui est sous jacent notre application on pourrait songer par exemple d crire un objet table relationnelle Pour notre part nous avons choisi de d crire la partie Abstraction par la classe n uplet qui d crit les n uplets stock s dans les tables Le fait de nous situer dans le mod le Objet nous permet d utiliser le concept d h ritage pour obtenir une description g n rique de l Abstraction de notre applicatio
7. Les r seaux ex cuter dans cette strat gie sont ceux obtenus apr s l tape 3 de la construction du WSCS Pour ex cuter un mod le suivant cette strat gie les r gles suivantes doivent tre appliqu es 1 2 3 4 5 6 Pour chaque objet primitif cr er un processus interpr tant l ObCS de l objet avec le marquage initial d fini par le syst me Ce processus est identifi par le nom de l objet Chaque occurrence de la transition d appel g n r e par l expansion d une transition d invocation cf III 1 f ex cute la premi re primitive de communication pour d poser un jeton dans la place param tre correspondante du r seau r f renc par le nom de l objet serveur De m me chaque occurence d une transition de retour d pose le jeton r sultat dans la place r sultat correspondante du r seau r f renc par le nom de l objet client il faut se souvenir que l identificateur d appel envoy par le client avec les param tres du service est de la forme Nom_de_classe Num ro_d instance Num ro_d ordre et que l identit du client est donc Nom_de_classe Num ro_d instance cf V 1 Chaque occurence d une Transition d Acc s TA doit acc der aux valeurs des attributs stock s dans les places attributs du r seau r f renc par l objet serveur en utilisant le deuxi me type de primitive de communication Chaque occurence d une transition qui invoque l op ration Create g n re
8. 32 1 3 La m thode HOOD Les objets actifs pour lesquels l ObCS contr le l ex cution des op rations fournies L ex cution d une op ration peut donc d pendre de l tat de l objet qui a t modifi par des invocations pr c dentes Si c est le cas on dit que l op ration a des contraintes fonctionnelles d activation Lorsqu il demande une op ration un serveur actif le client peut contr ler l effet de cet appel sur son propre flot de contr le en sp cifiant un type de requ te d ex cution qui peuvent tre P P yp q qui p Requ te HSER Highly Synchronous Execution Request le flot de contr le appelant est suspendu jusqu ce que l op ration invoqu e ait t compl tement ex cut e ce mode d ex cution correspond exactement la s mantique du rendez vous en Ada Requ te LSER Loosely Synchronous Execution Request le flot de contr le appelant est suspendu jusqu ce que la requ te ait t accept e par l objet serveur Le contr le est rendu l objet client d s que le serveur pris en compte la requ te envoi d un acquittement Requ te ASER Asynchronous Execution Request Le flot de contr le appelant n est pas interrompu mais un signal d ex cution ou message est envoy l appel L op ration invoqu e s ex cute alors en parall le avec le flot de contr le du client Requ te TOER Timed Out Execution Request l appelant demande que la requ te soit ex cut e av
9. On peut galement utiliser les arcs inhibiteurs g n ralis s II 2 2 6 pour trier les jetons d une place Ceci est r alis par le motif de la Figure I 22 T1 a si Pl a et Gortie P1 b et Trip a lt Trip b Figure IL 22 Motif se comportant comme une place tri e version 2 Le motif de la Figure 11 22 mule une place tri e Hard Descending On ne peut franchir la transition T1 avec un jeton lt a gt que s il n existe aucun jeton lt b gt dans la place tel que Tri a lt Tri b Un des int r ts de cette construction est que le tri est en quelque sorte relatif la transition Plusieurs transitions peuvent donc voir la place tri e suivant diff rents crit res 2 8 Prise en compte du temps Les r seaux de Petri en g n ral et les RPO tels que nous les avons d fini jusqu pr sent permettent d exprimer la s quentialit la pr c dence la concurrence ou la synchronisation et autorisent donc la d finition de liens de causalit entre v nements ils ne permettent de mod liser une dimension importante de l volution des syst mes la dimension temporelle que d une mani re qualitative et non pas quantitative Pour rem dier cette carence et autoriser la prise en compte quantitative du temps dans les mod les plusieurs mod les de RdP temporis s ont t propos s e Les RdP temporels Merlin 74 Merlin 76 associent chaque transition un couple tmin gt tnax O tmin donne l
10. de courtoisie L N M Tac peut tre consid r comme le contrat qu un serveur garantit de remplir pour l ensemble de ses clients Consid rons le cas d un serveur dont le marquage est tel qu il est en mesure d accepter une requ te mais qui volue par occurrence de transitions priv es TP de telle sorte qu il ne puisse plus accepter la requ te initiale Il ne remplit pas son contrat car un client ne peut pas tre inform de cette volution interne qui conduit cependant au rejet de sa requ te Pour viter de tels comportement les ObCS d impl mentation et de sp cification doivent tre transparents D finition IX 4 Crit re de transparence Soit o L N M et sac Tac tels que G Sac Tac LAN M Tac Le serveur sera dit transparent ssi Jae T Tac tel que 6 0 sa L N M Un serveur qui n est pas transparent sera dit sournois La transparence est quivalente la condition de comportement de Andre 90 et elle garantit que le fait d accepter une requ te d pende uniquement des requ tes pr c demment accept es Ly Tl Figure IX 1 Serveur sournois et serveur transparent La Figure IX 1 montre gauche un serveur sournois apr s le franchissement de T1 suite une requ te de S1 le franchissement de T2 resp T3 emp che d accepter le service S2 resp S1 Le r seau de droite sur la m me figure mod lise un serveur transparent qui accepte les m me s quences d
11. la variable v est donc li e un nouveau nom d objet D finition 11 21 Marquage atteint par un franchissement Soit Mt S une transition t T franchissable depuis le marquage M m Val avec la substitution S M m Val le marquage atteint par le franchissement de la transition t avec la substitution S partir du marquage M est d fini ainsi i V p P m p m p S Post p t S Pr p t ii Val est la valeur des jetons r sultant de l application de l action de t aux l ments de SV oy On notera MS M Informellement on peut d crire le franchissement d une transition t de la mani re suivante Enlever des places de t les jetons qui sont li s aux tuples de variables d entr e e Ex cuter l action de t pour calculer les valeurs des jetons de sortie e D poser dans les places de t les jetons li s aux tuples de variables de sortie D finition IL 22 Transitions concurremment franchissables Soit un multiensemble d instances de transitions Y Erreur ou t S est une instance de t Y sera dit concurremment franchissable depuis un marquage M not M si et seulement si V pe P Erreur lt M p Les transitions du multiensemble sont concurremment franchissables si et seulement si toutes les places en entr e des transitions contiennent suffisamment de jetons pour chacune des instances de transition de Y 1 3 Analyse statique des propri t s Le fait de permettre une a
12. 214 Sp cification de la classe Transport 215 Impl mentation de la classe Transport 216 259 178 179 Figure VIL 11 Figure VII 12 Figure VII 13 Figure VII 14 Figure VII 15 Figure VII 16 Figure VII 17 Figure VII 19 Figure VII 20 Figure VII 21 Figure VII 22 Figure VII 23 Figure VII 24 Figure VII 25 Figure VII 26 Table des figures Sp cification de la classe D rivation cccccceesseesceseceseceseceseceeecsecnseeseeeeeeneeees 217 Impl mentation de la classe D rivation cecceeseeecceseceteceseceeecaeenseeseeeeeeneeses 218 Sp cification de la classe composite Ilot 219 Impl mentation de la classe composite Ilot 219 Sp cification de la classe Transport double 220 Impl mentation de la classe Transport double 221 Sp cification de la classe Entr e_ilot 222 Sp cification de la classe Cellule 224 Le model e Seeheim 5 55 he ehh ne td me 227 Structure de contr le d une application interactive conventionnelle e Structure de contr le d une application dirig e par v nements ceeeeeeeeeeees Repr sentation externe de l diteur de n uplets 0 cceeceseeseceeeseeeseeeeeeneeeneeees 233 Sp cification de la classe n uplet ec eccecceeseeceeeceeeceeeeeseceseceecaeensecneeeeee
13. 4 La r gle de tir concurrent est celle du WSCS V 4 on ne peut franchir concurremment que des instances de transitions pour lesquelles la variable self est li e des noms d objets diff rents Suivant cette strat gie les communications initi es par les transitions d appel et de retour sont toujours dynamiques Ce n est plus le cas si on utilise un interpr te pour l ObCS de chaque hi rarchie de classe Etape 6 de la construction du WSCS La technique d crite par Bako 90 pour l ex cution par compilation partielle des RPO est applicable aux ObCS des Objets Coop ratifs condition toutefois de ne pas utiliser l acc s aux attriuts publics d une classe cette technique de compilation exclut en effet le recours la deuxi me primitive d IPC Dans une impl mentation r partie d un mod le d Objets Coop ratifs qui utilise les primitives de temporisation d crites en VI 1 2 des probl mes de d rive d horloge peuvent se produire Dans le cas d un appel gard si l horloge de l appel est en retard par rapport celle de l appelant le d lai de garde sera d autant moins long et r ciproquement si l horloge de l appelant est en retard Si l volution du registre temporel n est pas d crite dans le r seau par les techniques de Richter 85 mais au contraire g r e par l environnement on peut utiliser les techniques de synchronisation d horloges r parties d crites pour les applications temps r el Kopetz 87 2
14. Abstraction Mechanisms in CLU Communications of the ACM Vol 20 n 8 August 1977 Lecture Notes in Computer Science N 254 Petri Nets Central Models and Their Properties N 255 Petri Nets Applications and Relationships to Other Models of Concurrency Advances in Petri Nets 1986 Part I amp II Proceedings of an Advanced Course Bad Honnef September 1986 Brauer Reisig Rozenberg Eds Springer 1987 248 Mayer 91 Merlin 74 Merlin 76 Meyer 90a Meyer 90b Milner 80 Milner 83 Minkowitz 87 Minsky 75 Minsky 88 Moss 87 Oberweis 86 Olsen 83 Bibliographie MAYERR J Wholistic design Engineering and Manufacture IFIP conference CAPE 91 on computer applications in production and engineering September 1991 Bordeaux France MERLIN P A study of the recoverability of computer systems Ph D thesis University of California Irvine 1974 MERLIN P FARBER D J Recoverability of communication protocols Implications of a theoretical study IEEE transactions on Communications vol 24 No 9 Septembre 1976 MEYER B Sequential and Concurrent Object Oriented Programming in TOOLS 90 pp 17 28 MEYER B Conception et Programmation par Objets InterEditions Paris 1990 MILNER R A Calculus of Communicating Systems Theoretical Computer Science n 23 pp 267 310 1983 Springer 1980 MILNER R Calculi for Synchrony and Asynchrony LNCS Vol 92
15. D finition 11 26 Conflit structurel et conflit effectif Deux transitions tj et ty sont en conflit structurel Brams 83 si et seulement si elles ont au moins une place commune en entr e Ap Pr p t 0 et Pr p ty 0 Elles sont en conflit effectif pour un marquage M si de plus M1i M2 et 3 p M p lt Pr p ty Pr p tp Figure II 2 conflit de transitions En cas de conflit effectif entre deux transitions et en l absence de toute interpr tation le choix entre ces transitions est non d terministe A titre d exemple dans la Figure II 2 les transitions T et T2 sont en conflit structurel avec le marquage donn sur la figure les deux transitions ne sont pas en conflit effectif car seule TZ est franchissable Le conflit sera effectif pour tout marquage M tel que M P1 gt 1 et M P2 1 Lorsque l on consid re des r seaux de haut niveau o les jetons sont diff rentiables r seaux individus ou portent des valeurs r seaux pr dicats ou objets un niveau suppl mentaire d ind terminisme vient s ajouter il peut exister plusieurs mani res de franchir une transition donn e avec des substitutions capturant des individus diff rents dans les places d entr e La d finition des RPO contient un m canisme permettant de r duire cet ind terminisme il s agit des pr conditions associ es au transitions du r seau II 1 2 Toutefois les pr conditions peuvent s av rer insuffisantes dan
16. L objet Fichier apr s ex cution de ce service est dans l tat Ecrivain relativement au Fichier_prot g qui le manipule Cette information n est nulle part visible dans l ObCS de Fichier et n a d ailleurs pas de sens pour lui 4 5 Interpr tation de l ObCS d impl mentation On a explicit au paragraphe III 3 5 la mani re dont l ObCS de sp cification doit tre lu c est dire la mani re dont s interpr te le comportement d un serveur Pour que la vision de l interaction entre objets soit compl te nous allons maintenant d finir galement de mani re intuitive comment doit s interpr ter un ObCS d impl mentation Il nous faut ici non seulement pr ciser la d finition de la franchissabilit et la r gle de tir des transitions mais aussi donner la signification d une transition d invocation TT dont l action contient une requ te de service Comme pour l ObCS de sp cification ces d finitions sont donn es ici de mani re intuitive et seront formalis es au chapitre V 3 112 II 4 Impl mentation d une classe a Franchissabilit des transitions On peut classifier les transitions d un ObCS d impl mentation en quatre cat gories non exclusives entre elles e Les transitions d accord associ es un service par la fonction de disponibilit e Les Transitions d Invocation TI dont l action est une requ te de service e Les Transitions d Acc s TA dont l action est l acc s en lecture un attribut pub
17. Proving Monitors Communications of the A C M Vol 19 N 5 pp 273 279 1976 HUBER P JENSEN K SHAPIRO R M Hierarchies in Coloured Petri nets 10th European Workshop on applications and theory of Petri Nets Bonn June 89 HUR J CHON K Overview of a Parallel Object Oriented Language CLIX in ECOOP 87 pp 315 324 IBM Corp Common User Acces Advanced Interface Design Guide June 1989 Proceedings of 12th International Conference on Software Enginnering Nice France March 1990 IEEE Computer Society Press ISSN 0270 5257 JANTZEN M VALK R Formal properties of place transitions nets In Net Theory and Applications Proceedings of the Advanced Course on General Net Theory of Processes and Systems Hambourg RFA 1979 J RVINEN H M KURKI SUONIO R SAKKINEN M SYSTA K Object Oriented Specification of Reactive Systems in ICSE 12 pp 63 71 247 Jensen 81 Jensen 87 Kahn 86 Kaplan 89 Kessels 77 Kopetz 87 Krakowiak 85 Lamport 83 Lapalme 89 Lautenbach 74 Lieberman 81 Lieberman 86 Liskov 77 LNCS 87 Bibliographie JENSEN K Coloured Petri nets and the invariant method Theoretical Computer Science n 14 pp 317 336 1981 North Holland Publishing Company Coloured Petri Nets in LNCS 87 Part I Vol 254 pp 248 299 KAHN K DEAN TRIBBLE E MILLER M S BOBROW D G Objects in Concurrent Logic Programming Languages OOPSLA
18. Springer 1980 MINKOWITZ C HENDERSON P An Application of Object Oriented Programming to Petri Net Models of Discrete Event Driven Simulation in ECOOP 87 pp 187 192 MINSKY M A Framework for Representing knowledge in Psychology of Computer vision Winston P Ed Mc Graw amp Hill New York 1975 MINSKY M La Soci t de L esprit InterEditions 1988 MOSS J E B KOHLER W H Concurrency Features for the Trellis Owl language in ECOOP 87 pp 223 232 RICHTER G Temporal Aspects in Office Automation Systems Proc of IFIP TC8 Working Conference Office Systems Methods and Tools Pisa Italy October 1986 Brachhi G Tsichritzis D Eds Elsevier Science Publishers B V North Holland IFIP 1986 OLSEN D R DEMPSEY E P Syngraph A Graphical User Interface Generator Computer Graphics July 1983 pp 43 50 249 Oswald 90 Paludetto 91 Paludetto 90 Parnas 69 Parnas 73 Pasquier 89 Peterson 81 Petri 62 Pitette 86 Pnueli 86 Pomello 86 Ramchandani 74 Reizig 86 Bibliographie OSWALD H ESSER R MATTMAN R An Environment for Specifying and Executing Hierarchical Petri Nets in ICSE 12 pp 164 172 PALUDETTO M Sur la commande de proc d s industriels Une m thodologie bas e Objets et R seaux de Petri Th se de Doctorat de l Universit Paul Sabatier Toulouse D cembre 1991 PALUDETTO M VALETTE R COURVOISIER M
19. c est le cas chaque fois que deux transitions en conflit structurel sont en conflit effectif pour un marquage donn Les extensions qui visent permettre une ma trise de l ind terminisme ne sont pas de simples abr viations elles ne sont pas toujours r ductibles en dehors de cas simples un RPO normal et augmentent effectivement le pouvoir d expression du formalisme au d triment des possibilit s d analyse statique des mod les Toutefois leur introduction nous para t justifi e dans l optique d une utilisation du formalisme pour la mod lisation de syst mes en grandeur r elle Elles ont cependant t utilis es avec parcimonie dans ce m moire Enfin l objectif de la derni re extension la temporisation est explicitement d accro tre le pouvoir d expression du formalisme afin de le rendre applicable une classe plus large de probl mes Ces extensions ne sont pas toutes orthogonales entre elles les priorit s par exemple sont exprimables par des arcs inhibiteurs et r ciproquement Toutefois les cas d utilisation pratique de telles extensions sont suffisamment diff rents pour justifier de cette redondance 50 II 2 Extension des RPO 2 1 Ind terminisme dans les R seaux de Petri Objets Plusieurs de ces extensions ont pour objectif de r duire l ind terminisme de l volution d un r seau aussi nous commen ons par caract riser les diff rents niveaux d ind terminisme pr sents dans un RPO
20. Create Data Flows Peut_traiter lt pal Palette gt lt r BOOLEAN gt is do r pal op ration_suivante in Ops end Traite ObcCS Toutes les places sont de type lt Palette gt Figure VII 20 Implementation de la classe Cellule Une palette arrivant par la voie de gauche qui n est pas concern e par le poste reste sur la voie de gauche sinon elle va en T2 puis T4 pour subir sur le poste l op ration suivante de sa gamme Une palette arrivant par la voie de droite passe toujours par le poste A la sortie du poste en T5 elle va vers la voie interne celle de gauche si l on se trouve dans la derni re cellule de production PS de l lot et qu il reste des op rations faire sur l lot ou si le poste suivant ne peut pas effectuer l op ration suivante de la gamme On voit donc que la d cision de faire transiter la palette vers la voie de gauche d pend d une condition non locale la cellule doit consulter l l ment de transport suivant suivant Passe _ droite pour prendre cette d cision On pourra v rifier que les r gles de gestion d une cellule de production sont bien v rifi es 209 2 INTERFACES PERSONNE LOGICIEL Nous allons montrer dans cette tude de cas comment le formalisme des Objets Coop ratifs s int gre dans le processus de conception d une application interactive Pour les applications interactives comme pour toute autre application le processus de conception peut se d comp
21. Extension des RPO Prio PxT gt 0 1 telle que la valeur de Prio p t n est significative que si Pr p t 0 graphiquement un arc Pr p t tel que Prio p t 1 sera repr sent par un trait en gras La priorit d une transition t est alors d finie par Prio t Erreur On se ram ne alors la d finition 11 29 de Hack par vt t e T t lt t amp Prio t lt Prio t La Figure II 7 partie gauche illustre la d finition explicite des priorit s sur les transitions et la d finition implicite par l utilisation des arcs prioritaires partie droite La repr sentation de droite est plus lisible les arcs en gras tant intuitivement interpr t s comme le chemin privil gi que les jetons cherchent parcourir Dans les deux cas si T1 et T2 sont simultan ment franchissables c est TZ qui sera choisie T1 T2 Figure II 7 Priorit s par transitions et priorit s par arcs Notre d finition est par ailleurs quivalente celle de Hack en effet quelle que soit la relation d ordre sur les transitions pour un r seau donn il est toujours possible d muler cette relation d ordre par notre notation en rajoutant des places cet effet Le m canisme de priorit sur les arcs se combine l gamment avec les places capacit au prix de l introduction d une nouvelle notation graphique l arc en gras figure alors en sortie d une transition mais la s mantique d une telle notation illustr e en Figure II
22. IFIP TC 8 WG 8 1 working conference Namur Belgium 18 20 October 1989 North Holland SIBERTIN BLANC C High level Petri nets with Data Structure 6th European Workshop on Petri Net and applications Espoo Finland June 85 SIBERTIN BLANC C Petri Nets with individuals and objects instead of tokens Internal report extended version of Sibertin 85 SIBERTIN BLANC C Petri Nets with Objects as a recursive programming language Bigre Globule 59 dec 87 in french SIBERTIN BLANC C Analysis of Petri Nets communicating trough a Client Server protocol Internal report SIBERTIN BLANC C Cooperative Objects for the Conceptual Modelling of Organizational Information Systems Proc of IFIP TC8 Working Conference on the Object Oriented Approach in Information Systems Quebec City Canada October 1991 F van Assche et al Eds Elsevier Science Publishers 1991 SIFAKIS J Use of Petri nets for performance evaluation ae International symposium on modelling and performance evaluation of computer systems H Beilner et E Gelenbe Eds North Holland 1977 251 Souissi 89 Stefik 86 Stroustrup 87 Tardieu 83 Taubner 87 TECHLOG 89 TOOLS 90 Tripathi 89 TSI 85 Valette 79 Valette 86 Valette 85 Valette 88a Valette 88b Bibliographie SOUISSI Y MEMMI G Composition of nets via a communication medium 10th European Workshop on applications and theory of
23. Priorit s sur les arcs et place capacit eee eeceeseeceeseeeeeeeeceeceseseeeeeeneenseenaes Figure II 9 gt Are inhi biteut vi eee teeri in i ieee va tee Head oven Pie ed ei ees Figure IL 10 combinaison d arc inhibiteur et d arc standard 0 0 ee eeeecseescsceeeeeeceseeeceaeeeeeneens Figure IL 11 Arc inhibiteur g n ralis sans precondition ce eeeseeecneeeececeeeeeeeeeeecaeeaeeneens Figure IL 12 Arc inhibiteur g n ralis avec pr condition Figure IL 13 Arc inhibiteur testant tous les jetons d une place Figure II 14 Influence du tri sur la franchissabilit 0 tee eeecceseeeeeeeceeeeeeseceeesecneeeeeaeeeceaeees Figure IL 15 Pri erunification Etre Rene AR RE es RAR RER EN An Anke Figure IL 16 Un motif se comportant comme une file ee eeeeeeeeeceseeeceseceeeeeeneeeceeenererenee Figure IL 17 Evolution des marquages pour le motif File Figure IL 18 Un motif se comportant comme une Pile Figure IL 19 Evolution des marquages pour le motif Pile Figure IL 20 Motif se comportant comme une place tri e version 1 Figure IL 21 Evolution des marquages pour le motif Place trie 0 0 0 eeceeceeseeseeeeeeeeeeteeneeenees Figure IL 22 Motif se comportant comme une place tri e version 2 Figure 11 23 mulation d une transition temporis e Figure 1 24 mulation des r seaux arcs temporels
24. Structuration des mod les de R seaux de Petri de Haut Niveau 79 PARTIE Il LES OBJETS COOPERATIFS 81 Chapitre Ill D finition des objets coop ratifs Le formalisme des Objets Coop ratifs est un langage de conception Orient Objet qui permet la mod lisation d un syst me des niveaux d abstraction diff rents en le d crivant comme une collection d objets concurrents qui coop rent d une mani re pr cis ment d finie afin de remplir les services attendus du syst me En paraphrasant une quation c l bre notre approche peut tre caract ris e par Syst me Objets Coop ration Objet Structure de Donn es Op rations Comportement Figure II 1 Equation fondamentale du mod le L approche objet nous fournit les concepts suffisants pour d finir la structure des objets et leurs inter relations afin de structurer le syst me suivant les principes de forte coh sion et de faible couplage la th orie des r seaux de Petri quant elle nous permet de mod liser le comportement des objets et les communications qu ils entretiennent de telle sorte que l on puisse exprimer la concurrence aussi bien entre les diff rents objets qu au sein m me d un objet Structure de donn es Approche Objet Services Objets Coop ratifs Comportement R seaux de Petri Coop ration Figure II 2 Le formalisme des Objets Coop ratifs et ses formalismes de r f rence Pour ce qui est des composants structure
25. dans la majorit des langages objets plut t que la d signation de la syntaxe Eiffel qui est Current 144 2 PRESENTATION DE L EXEMPLE Nous allons illustrer le proc d de construction du WSCS partir d un syst me tr s simple Les classes qui composent ce syst me n ont pas de fonctionnalit bien d finie mais sont construites afin de mettre en exergue tous les points qui interviennent au cours du processus de construction Class Implementation Pclient ObCS Pl P4 lt x INTEGER gt P2 lt o ServeurS gt P3 P5 lt o ServeurG gt oO GServer create lt x o SServer create lt x Figure V 2 La classe Pclient La classe Pclient Figure V 2 d crit le comportement d objets qui agissent uniquement en tant que clients aucun service n est d fini pour la classe et les instances ne peuvent donc pas tre utilis es en tant que serveurs La classe Pclient est cliente des classes ServeurG pour serveur g n rique et Serveurs pour serveur sp cialis qui h rite de ServeurG Conform ment la r gle d h ritage Serveurs offre les m mes services que ServeurG ici uniquement OP augment s de ses propres services ici OP2 145 V 2 Pr sentation de l exemple Class Implementation ServeurG Services OP1 lt p INTEGER gt lt r Create lt c INTEG do Ready lt c gt end Create ObcCS PG1 lt p INTEGER c Ready lt c
26. es ou d exceptions 35 1 3 La m thode HOOD 3 5 Les objets Classe La notion de classe propos e par HOOD ne doit pas tre confondue avec celle pr sente dans la majorit des autres mod les objets HRM 89 d finit une classe comme un objet r utilisable dans lequel certains types et ou donn es utilis s par les op rations de la classe ne sont pas d crits On peut d finir une instance d une classe dans laquelle ces types et ou donn es sont d finis explicitement cr ant ainsi un objet particulier pour une conception donn e Cette d finition correspond tout fait ce qu il est convenu d appeler un type g n rique dans la plupart des autres m thodes de programmation Les limitations l utilisation des objets Classe sont s rieuses un objet classe est forc ment l objet racine d une autre conception HOOD il ne peut donc utiliser aucun objet du syst me concevoir HOOD entretient la confusion avec les classes d objet dans leur acception traditionnelle en proposant de plus une forme d g n r e de l instanciation des langages objet quand plusieurs instances identiques sont n cessaires le nom de ces instances est g n r par un nom g n rique concat n avec des entiers successifs pris entre deux bornes On voit que cette construction ne permet d exprimer ni l instanciation dynamique o des objets viennent l existence au cours de la vie du syst me ni la relation d utilisation dynamique entre
27. lt Valeur gt liste de valeurs gt lt Valeur gt lt liste de valeurs gt Figure IILS BNF de la d finition du marquage initial d une place Les Figures III 6 et III 7 illustrent l utilisation de cette syntaxe d affectation dans le code d une op ration Create Les valeurs dans la d finition d un n uplet peuvent tre des param tres de l op ration Create ou des constantes on peut s abstenir de mentionner une multiplicit gale 1 Pour favoriser la lisibilit de l ObCS on fera figurer sur sa repr sentation graphique la distribution de jetons du marquage r sultant de l ex cution de Create 3 4 Exemples Pour illustrer la sp cification d une classe dans le formalisme des Objets Coop ratifs nous allons d crire deux classes d objets Les entit s d crites par ces classes n appartiennent pas vraiment au 94 II 3 Sp cification d une classe domaine d application auquel nous destinons notre formalisme savoir les syst mes concurrents Au contraire nous avons choisi ces entit s parmi les l ments de base de la culture informatique afin que le lecteur puisse se concentrer sur les aspects syntaxiques du formalisme sans avoir au pr alable int grer la s mantique du syst me mod lis e La classe Fichier d crit un fichier tel que le manipule un syst me d exploitation de type UNIX Ce fichier est une simple suite de caract res chaque caract re tant individuellement adr
28. par l une des op rations du poste Il est orient vers T7 dans le cas contraire ou bien si 74 est plein Une priorit est donn e la palette allant de T2 vers T4 par rapport celle venant de 73 On notera que D2 est prioritaire sur DZ Cela signifie qu en cas d accumulation des palettes en T3 D1 ne fera rien venir en T4 et attendra la lib ration de T3 en stoppant les palettes en fin de T1 Pour D3 Un produit sortant de TS restera sur l anneau ext rieur si le poste suivant logique cf gamme est le suivant physique mais galement si la palette doit rejoindre le distributeur fin de travail sur l lot Elle bifurquera vers l anneau int rieur dans le cas contraire Pour D4 Les palettes issues de T6 sont prioritaires vis vis de celle venant de T7 1 3 Configuration de l atetier Chaque l ment de l atelier tapis roulant poste de travail est contraint par des param tres concernant sa capacit le nombre de palettes qu il peut contenir un instant donn et sa dur e de transfert La valeur de ces param tres est donn e en Figure VII 4 193 VII 1 Mod lisation d un atelier flexible cellule de transport 1 voie du 4 2 unit s de temps par distributeur emplacement Tunit par emplacement cellule de transport 2 voies 4 sur chaque voie 1 unit par emplacement cell de production O oo Figure VII 4 Param tres des composants de l atelier Chaque poste de travail est programm pour acco
29. sent es avec les m mes buts L objet de notre travail est de d finir un mod le qui concilie les concepts de la conception Orient e Objet avec ceux des R seaux de Petri de Haut Niveau RdPHN en conservant les avantages propres chacune de ces approches et notamment e G rer la complexit des mod les par des techniques et des crit res sains de structuration e Faciliter la r utilisation et l extension de mod les d j produits e Offrir les m canismes d abstraction permettant de mod liser un syst me diff rents niveaux et d utiliser le m me formalisme diff rentes tapes du cycle de vie e Produire des mod les faciles lire et valider en autorisant la description d interfaces de haut niveau entre composants et en profitant de la repr sentation graphique claire et concise des R seaux de Petri e Permettre des validations statiques et dynamiques du mod le en cours d laboration afin de d tecter au plus t t les erreurs et les dysfonctionnements gr ce une s mantique formellement d finie Pour atteindre ces objectifs nous proposons un formalisme appel Objets Coop ratifs Ce formalisme est d fini formellement avec toute la pr cision n cessaire pour qu il puisse tre effectivement utilis comme un Langage de Sp cification Ex cutable Le but est de mettre la disposition du mod lisateur les concepts structurant les plus puissants de l approche objet classification encapsulati
30. viter en premi re lecture la d finition formelle des RPO et s y reporter lorsque nous y faisons r f rence au cours du texte 1 1 Pr liminaire math matique a D finition sur les ensembles On introduit tout d abord les notations principales qui seront utilis es tout au long des d finitions On notera Z ensemble des entiers relatifs N l ensemble des entiers naturels N l ensemble des entiers naturels non nuls et X les op ration d addition et de multiplication sur les entiers lt la relation d ordre inf rieur ou gal sur les l ments de Z P l ensemble des parties d un ensemble E quelconque l ensemble vide D finition II 1 Multiensemble Soit E un ensemble dont les l ments sont not s ej avec ie N On d finit un multiensemble sur E par une fonction x x E Z de support fini i e i tels que x e 0 est fini On notera x Erreur avec x e Z 38 IL 1 Les R seaux de Petri Objet Un multiensemble sur un ensemble E peut tre consid r comme un ensemble dans lequel on a affect un coefficient entier chaque l ment de E d terminant la multiplicit de son appartenance On appelle Z E l ensemble des multiensembles de E Z E est le Z module libre sur Z engendr par E Soient eg E etx Erreur le Z E par extension de la notation ensembliste on notera ep x si et seulement si x e0 0 x Erreur le cardinal du multiensemble x Un multiensem
31. 2 Ordonnancement des invocations lt x self gt lt x id gt CREATE lt a id gt lt a sqlf gt lt selfiself gt lt avant 3 lt avant self gt lt a self gt lt b se f gt LS lt a b id self gt lt param x id self V lt a b id sel f gt Sparam xy idr geli V lt c id gt lt retour id gt END S1 KA resu 3 retour f param x lt a c self gt Figure VI 7 WSCS d un service LIFO 179 3 FLOTS DE DONNEES En g n ral une invocation a pour cons quence l initiation la terminaison l interruption ou la r activation de flots de contr le internes l objet serveur Dans de nombreux cas cette action sur la structure de contr le du serveur est triviale voire inexistante nous avons d j rencontr un tel cas il s agit des services de mise jour des attributs d un serveur cf IIL 3 qui offrent une mani re standardis e de modifier la valeur des attributs publics d un objet Dans les ObCS de sp cification ou d impl mentation un service de mise jour apparait comme une transition non connexe au reste du r seau la connexit sera restaur e au moment de la construction de l ObCS d extension de la classe par l introduction des places attributs cf V 3 3 La sp cification et la s mantique d un tel service sont rappel es en figure VI 8 lt ancien self gt lt nouveau lt nouveau id self CHANGEattribut CHANG Eattribut lt ancien
32. 7 gt 4 a 4 lt x gt 2 lt y gt 4 lt x gt 8 lt y gt a et b ne sont pas comparables car on n a nia lt Q b ni b lt a Par contre si a lt x gt alors a sO a b Definitions sur les applications D finition II 9 Prolongement canonique Soit E et F deux ensembles et une fonction f E gt F Soit E l ensemble des n uplets d l ments de E 40 IL 1 Les R seaux de Petri Objet le prolongement canonique f de f est d fini par f E gt F lt el lt En gt P lt ez gt lt f e fle gt f ainsi d finie est l unique homomorphisme de E vers F qui respecte la concat nation et prolonge f D finition II 10 Prolongement lin aire Le prolongement lin aire f de f sur Z E est d fini par f Z E gt Z F x Erreur gt f x Erreur avec x e Z f ainsi d finie est l unique prolongement lin aire de f qui respecte et f peut tre d finie par r currence 1 six e E gt f x f x 2 six y Z E gt f x y f x f y du fait que f est lin aire 3 sixe Z E ne Z gt f n x n f x D finition II 11 Support d un multiensemble de n uplets La fonction Support associe tout multiensemble de n uplets de E l ensemble des l ments de E pr sents dans ces n uplets Elle peut tre d finie par r currence comme suit 1 Soit Ops l ment neutre de E support 0 2 Soitx E suppo
33. 86 Special issue of SIGPLAN Notices Vol 21 N 11 pp 214 223 Portland OR USA November 1986 KAPLAN S M LOYALL J P GARP Scheme Implementing a Concurrent Object Based Language Special issue of BIGRE N 65 Putting SCHEME to work pp 66 84 ISSN 0221 5225 Juillet 1989 KESSELS J L W An alternative to event queues for synchronization in monitors Communications of the A C M Vol 20 N 7 pp 500 503 1978 KOPETZ H OCHSENREITER W Clock synchronisation in distributed real time systems IEEE Transactions on Computers Vol C 36 n 8 August 1987 KRAKOWIAK S Des syst mes d exploitation des ordinateurs ISBN 2 04 016416 2 Dunod Informatique 1985 LAMPORT L Solved Problems Unsolved Problems and Non Problems in Concurrency Proceedings of 3 Annual ACM Symposium on Principles of Distributed Computing 1984 LAPALME G SALLE P Plasma II an Actor Approach to Concurrent Programming Proceedings of the ACM SIGPLAN Workshop on Object Based Concurrent Programming SIGPLAN Notices Vol 24 N 4 April 1989 pp 81 83 LAUTENBACH K SCHMID H Use of Petri Nets for proving correctness of concurrent Process system Information Processing 74 North Holland 1974 LIEBERMAN H A preview of Act 1 Al memo 625 MIT AI Lab 1981 LIEBERMAN H Delegation and Inheritance Two Mechanisms for Sharing Knowledge in Object Oriented Systems in BI GL 48 pp 79 89 LISKOV B SNYDER A ATKINSON R SCHAFFERT C
34. 88 A Comparative Study of Object Oriented Analysis Methods HP Labs technical report April 1991 DE CINDIO F DE MICHELIS G POMELLO L SIMONE Superposed Automata nets Applications and Theory of Petri nets LNCS 52 1981 DENERT E Specification and design of dialogue systems with state diagrams in Proc of International Computing Symposium Li ge pp 417 424 North Holland 1977 DIJKSTRA E W Cooperating sequential processes Technical Report EWD 123 1965 reproduit dans Programming Langages F Genuys ed Academic Press 1968 pp 43 112 DIJKSTRA E W Hierarchical ordering of sequential processes Acta Informatica Vol 1 N 2 pp 115 138 1971 DUCOURNEAU R HABIB M On some Algorithms for Multiple Inheritance in Object Oriented Programming in ECOOP 87 pp 291 302 DUMOND Y D marches applicatives par les objets dans la conception de logiciel de commande de proc d s industriels in GL17 89 pp 68 83 EUROPEAN CONFERENCE ON OBJECT ORIENTED PROGRAMMING Special issue of BIGRE N 54 Juin 1987 FALK H CASE Tools emerge to handle real time systems Computer Design Vol 27 N 1 January 1988 pp 53 74 245 Feldbrugge 87 Ferber 84 Fritschy 89 Galton 87 Genrich 87 GL17 89 Goldberg 83 Guttag 77 Hack 72 Hack 75 Halbert 86 Harel 88 Hee 89 Hewitt 77 Hewitt 73 Bibliographie FELDBRUGGE F JENSEN K Petri Net Tool Overvi
35. Dans le formalisme des Objets Cop ratifs la pragmatique est d finie par un ObCS il nous faut d finir un crit re formel de compatibilit des ObCS entre classes d riv es Le crit re de compatibilit que nous avons retenu est identique celui qui caract rise la compatibilit entre un ObCS de sp cification et d impl mentation Il repose sur la comparaison des langages accept s par l ObCS de l anc tre et celui du descendant et sera d taill au chapitre IX avec les autres possibilit s d analyse du mod le Le fait que le crit re de compatibilit entre anc tre et descendant soit identique celui entre sp cification et impl mentation induit une propri t importante 127 IV 2 Hi rarchie d h ritage la comparaison entre anc tre et descendant peut se limiter la sp cification de classe si les sp cifications sont compatibles et que chaque niveau d h ritage les impl mentations sont compatibles avec les impl mentations alors les impl mentations seront galement compatibles entre anc tre et descendant ceci permet une bonne factorisation du processus de v rification 2 2 H ritage multiple On parle d h ritage multiple lorsque une classe peut avoir plusieurs anc tres imm diats Le formalisme des Objets Coop ratifs autorise l h ritage multiple et la relation d h ritage est donc un graphe sans cycle et non plus un arbre Comme dans tout formalisme autorisant l h ritage multiple le probl me
36. Distributeur SetPr c dent as SetDistributeur Transport _ double Services Tous les services sont h rit s ObCS Circule lt Palette gt Cd GAUCHE Circule TRANSMETTRE DROITE Figure VII 17 Sp cification de la classe Entr e_ilot 206 VIL 1 Mod lisation d un atelier flexible Class Implementation Entr e _Ilot Attributes Ops set of Operations Services Create lt Oper set of Operations gt is do Ops Oper end Create Operations Peut_traiter lt pal Palette gt lt r BOOLEAN gt is do r pal op ration_suivante in Ops end Peut_traiter Passe_a_droite lt pal Palette gt lt r BOOLEAN gt is do r NOT traite pal end Passe_a_droite Entree GCircule GSortie lt Palette gt Entree DCircule DSortie lt Palette gt Entree SCircule SSortie lt Palette gt GAUCHE Figure VII 18 Impl mentation de la classe Entr e_ilot 207 VIL 1 Mod lisation d un atelier flexible Un objet de cette classe effectue le raccordement entre le distributeur et l lot auquel il appartient Les palettes entrent en provenance du distributeur sur la voie de droite Apr s avoir fait le tour de I ilot elles retournent dans le distributeur si elles sont sur la voie de droite par appel de Transmettre ou amorcent un autre tour dans l ot si elles sont sur la voie de gauche On remarque que le service de consultation Passe_ _ droite est red fini par rap
37. Etape 1 Gestion des demandes de service Le but de cette tape est d tendre les ObCS des classes clientes afin de leur permettre d effectuer des requ tes de service et d obtenir les r sultats de ces requ tes C est dans cette tape que la possibilit d occurrences simultan es des TI doit tre prise en compte Chaque occurrence d une requ te de service sera estampill e par le client lui permettant ainsi de diff rencier les valeurs renvoy es par ses appels On trouve ici la premi re utilisation du m canisme de g n ration d identifieurs du V 1 Plus pr cis ment la gestion des demandes de service n cessite d tendre les ObCS de chaque classe cliente du syst me de la mani re suivante 1 Chaque Transition d Invocation TI est clat e en une transition d appel qui a les m mes places d entr es que la transition originale et une transition de compl tion qui a les m mes places de sortie que l originale 2 Pour chaque TI une place d attente est introduite afin de connecter la transition d appel et la transition de compl tion Le type de cette place est l agr gation des types des variables d entr e de la TI ou un jeton simple s il n y a pas de variable d entr e 3 Une Place param tre est ajout e en sortie de chaque transition d appel Le type de cette place est identique la signature d entr e du service appel L arc qui connecte la transition d appel 148 V 3 Construction du r seau glob
38. II 2 8 Les arcs connectant la place param tre et les transitions d accord sont temporis s par l expression 0 delay ou delay d note la valeur de l l ment correspondant dans la place param tre L arc qui connecte la place param tre la transition d annulation est temporis par l expression delay Le type de la place r sultat est tendu par l adjonction d un l ment bool en d notant l occurrence d un timeout lors de l invocation du service Les tiquettes des arcs reliant les transitions de retour du service la place r sultat sont tendues pour initialiser cet l ment FAUX alors que l arc en provenance de la transition l initialise VRAI e Lors de l tape 6 les tiquettes des arcs connectant les transitions d invocation avec la place param tre sont tendues afin de transmettre la valeur du d lai de garde avec les autres param tres de l invocation Pour les invocations par rendez vous non gard la valeur infinie co est transmise lt a b id self gt lt a b id self gt lt x id TRUE Figure VI 4 S mantique d une invocation gard e La syntaxe graphique d une invocation gard e est illustr e en figure VI 3 et sa s mantique en figure VI 4 avec une partie du WSCS g n r par une telle invocation L invocation gard e est l quivalent d une TOER Timed Out Execution Request de la m thode HOOD 174 VII Modes d invocation des services 1 3 Communicati
39. OBJET Apr s un bref rappel des principes fondamentaux de l approche objets la section 1 1 rappelle la th orie des Types Abstraits de donn es qui en est un des fondements th oriques La section suivante est consacr e une tude sur les rapports entre sp cification et impl mentation des composants logiciels Nous pr sentons ensuite en d tail deux concepts importants de l approche objet que nous avons mis en avant dans le formalisme des Objets Coop ratifs la programmation par contrat et la hi rarchie d h ritage La programmation par objet est n e du constat des faiblesses de la programmation structur e et de la conception par hi rarchie fonctionnelle descendante Le probl me majeur de ces approches est la dichotomie tr s nette entre structure des donn es et structure des traitements qu elles induisent le processus de conception s attachant uniquement aux fonctions et leur raffinage progressif les donn es sont en quelque sorte diffuses dans toute la conception Or au cours d un processus de conception on se rend compte que la structure que l on envisage pour les traitements est bien plus souvent remise en cause que la structure des donn es Il est donc plus judicieux de centrer le processus de conception sur les donn es ou les objets manipul s D autre part en centrant le processus de conception sur les donn es la probabilit d obtenir une certaine forme de r utilisabilit augmente car dans de nombreux
40. Objet Syst me d Objets et Environnement d un Syst me d Objet ces trois entit s relevant de la m me description Ceci permet par exemple le test unitaire d un d objet consid r comme un syst me en lui fournissant un environnement ad quat lt gt SYSTEME t ENVIRONNEMENT L environnement est a 7 tS de l environnement Combinaison des Figure IV 2 Univers Syst me d Objets et Environnement La Figure IV 2 illustre la vision de l univers comme un ensemble d objets li s par la relation d utilisation Suivant l endroit o l on place dans cet univers les fronti res entre syst me et environnement on consid rera l environnement comme un serveur comme un client ou comme une combinaison des deux Dans la troisi me partie du pr sent m moire nous pr sentons deux tudes de cas utilisant notre formalisme Une de ces tudes qui d crit un atelier de fabrication robotis est mod lis e comme un syst me clos L autre une interface personne logiciel est mod lis e comme un syst me ouvert o l environnement est client du syst me 125 2 HIERARCHIE D HERITAGE Nous avons d j rencontr deux types de relations qui permettent de structurer un ensemble de classes d Objets Coop ratifs e La premi re est la relation entre sp cification et impl mentation qui en donnant deux descriptions coh rentes mais distinctes d une m me classe permet de s abstraire des d tails du fonctionnement intern
41. P Une introduction la programmation par objet Giens 86 2 journ es Bases de Donn es avanc es COLOM J M SILVA M VILLAROEL J L On software implementation of Petri Nets and Colored Petri Nets using high level concurrent languages Seventh European Workshop on applications and theory of Petri nets Oxford July 86 COUTAZ J The Construction of User Interfaces and the Object Paradigm in ECOOP 87 pp 135 144 COWAN B W WEIN M State versus history in user interfaces Proceedings of IFIP conference Interact 90 Cambridge August 1990 North Holland 244 Cox 86 Dahl 66 Dang 86 De Bondeli 87 De Champeaux 91a Bibliographie COX B J Object oriented programming an evolutionary approach Addison Wesley Mass 1986 DAHL O J NYGAARD K SIMULA An Algol Base Simulation Language Communications of the ACM Vol 9 N 9 pp 671 678 Sept 1966 DANG W Programmation Concurrente en Langage Orient Objet in BI GL 48 pp 149 155 DE BONDELI P Impl mentation en Ada de types de synchronisation et communication inter t ches sp cifi s par des r seaux pr dicats transition in BI GL 57 DE CHAMPEAUX D Object Oriented Analysis and Top Down Software Development ECOOP 91 LNCS N 512 pp 360 376 Springer Verlag July 1991 De Champeaux 91b DE CHAMPEAUX D DeCindio 81 Denert 77 Dijkstra 65 Dijkstra 71 Ducourneau 87 Dumond 89 ECOOP 87 Falk
42. RdP priorit s te T est franchissable depuis M par la substitution S si 1 Ype P S Pr p t lt m p 2 iln existe pas t e T tel que Mt ett lt t Toutefois il est en g n ral peu significatif d affecter une priorit globalement toutes les transitions du r seau et il n existe pas de repr sentation graphique lisible des priorit s sur les transitions En pratique les priorit s sont surtout utilis es pour lever l ind terminisme entre deux transitions en conflit structurel et cette utilisation nous appara t galement comme tant la mieux fond e m thodologiquement il semble en effet que le fait de g rer des priorit s sur l ensemble des transitions du r seau contrevienne l aspect strictement local de la r gle de franchissement o seules les places adjacentes la transition en cours d examen sont consid rer Pour favoriser cette utilisation des priorit s nous proposons donc de r duire la port e de la d finition de Hack en affectant des priorit s non plus aux transitions mais aux arcs du r seau et en se limitant deux niveaux de priorit on parlera alors d arcs prioritaires par opposition aux arcs sans priorit La relation d ordre est alors calcul e en fonction de la priorit des arcs D finition IL 30 RPO priorit s Un RPO priorit s R lt C T V P Pr Post Prio gt est d fini par l adjonction un RPO lt C T V P Pr Post gt d une fonction Prio 55 II 2
43. Type2 type export Sv2 lt vl Typel gt service sans param tre d entr e et avec un param tre de sortie de type Typel type export Sv3 service sans param tre d entr e ni de sortie Attributes attl Typel att2 Set of INTEGER Figure IIL 3 Syntaxe de l interface d une classe La syntaxe de d claration des types des constantes des services et attributs qui constituent l interface d une classe est illustr e en Figure III 3 On remarque notamment que les listes de param tres d entr e et de sortie sont d limit es par des signes inf rieur et sup rieur lt gt au lieu des parenth ses classiquement utilis es dans les langages de programmation Cette syntaxe particuli re sera justifi e 90 U1 3 Sp cification d une classe au III 3 2 La figure illustre galement quelques simplifications syntaxiques utilis es pour d signer des fonctions dont la liste de param tres d entr e ou de sortie est vide 3 2 Pragmatique d une classe Pour compl ter la sp cification d une classe d objets il convient d expliciter la pragmatique des objets de cette classe Il faut fournir une description de l objet qui explicite son mode d emploi en d taillant notamment sa structure de contr le c est dire Les conditions d activation de ces services et plus particuli rement les s quencements possibles d activation des services offerts les contraintes d ex
44. WSCS deux autre strat gies d ex cution des mod les peuvent tre propos es avec un interpr te par objet ou un interpr te par classe d objets Quelle que soit la solution choisie il est n cessaire de disposer de primitives de communication inter processus IPC afin que les interpr tes puissent communiquer Les interpr tes communiquent par changes de jetons et on doit donc d finir des primitives permettant cet change Nous allons voir que deux primitives suffisent e La premiere permet un interpr te de d poser un jeton dans une place d un r seau pris en charge par un autre interpr te e La seconde permet un interpr te d acc der aux valeurs d un jeton dans une place d un r seau pris en charge par un autre interpr te en lecture seulement 15 Une liste d outils supportant l utilisation des RdP est d crite dans Feldbrugge 87 et maintenue jour en permanence 223 VIL I Un interpr te par classe d objet 1 UN INTERPRETE PAR OBJET Avec cette strat gie d ex cution chaque objet du syst me est pris en charge par son propre interpr te qui ex cutera son ObCS Avec cette solution la dynamique et la topologie du mod le en cours d ex cution pr sente la m me structure que le syst me mod lis mais cette approche pr sente en revanche les inconv nients li s la prolif ration des interpr tes quand des objets sont cr s dynamiquement dans le syst me et d un trafic plus intense d IPC
45. a Vue externe La vue externe d un composant est celle des utilisateurs potentiels de ce composant Elle d crit ce que le composant fait et comment il peut tre utilis Un composant est alors per u comme une bo te noire dont on ne conna t que la fonction et le mode d emploi Cette approche b n ficie des fondements th oriques apport s par la th orie des Types de Donn e Abstraits Fr quemment une analogie est faite entre cette vision de l utilisation de composants logiciels et les techniques d ing nierie que l on rencontre dans le domaine de l lectronique et que certains auteurs Cox 86 on propos d int grer dans l ing nierie logicielle avec le concept de circuits int gr s logiciels software IC La sp cification d un composant logiciel dont la connaissance est n cessaire pour son utilisation 3 correcte est constitu e de deux composants distincts l interface et la pragmatique e L interface d crit l aspect syntaxique de l utilisation du composant si on poursuit l analogie entre composant logiciel et circuit int gr il s agit l du brochage du circuit de son nombre de pattes des tensions accept es en entr e et d livr es en sortie e La pragmatique au contraire d crit l aspect s mantique et dynamique du composant La s mantique d crit les fonctionnalit s caract rise les r sultats fournis en fonction des entr es et donne les effets de bord ventuels li s aux activit s du composant La dyn
46. alors modifi e de la mani re suivante te T est franchissable depuis M par la substitution S si 1 Ype P S Pr p t lt m p 2 m p lt Capacit p Post p t Pr p t sp cifiant ainsi qu aucun franchissement ne peut rendre le cardinal du marquage d une place sup rieur sa capacit Le proc d permettant de transformer un r seau capacit en un r seau simple est d crit dans Andr 81 Jantzen 79 Il consiste simplement rajouter pour chaque place p capacit une place p de type jeton dite place compl mentaire de p dont les transitions d entr e et de sortie sont respectivement les transitions de sortie et d entr e de la place p Le marquage initial de la place compl mentaire est d fini par mo p Capacit p mo p lt gt 54 II 2 Extension des RPO Figure IL6 Place capacit et notation abr g e Graphiquement on repr sentera la capacit d une place entre parenth ses l int rieur de l ellipse qui la repr sente La Figure II 6 illustre la syntaxe graphique d une place capacit et le RPO quivalent 2 5 Arcs priorit Les r seaux priorit Hack 75 ont pour objectif de r duire l ind terminisme dans l volution d un r seau en munissant l ensemble T des transitions d une relation d ordre partiel lt La franchissabilit des transitions est alors d finie de la mani re suivante D finition IL 29 Franchissabilit d un
47. arriv e d pend de la fa on dont le type d objet est d fini La valeur d un l ment de type classe est constitu e de la valeur de son nom et de la valeur de ses attributs ainsi deux objets ayant des attributs de m me valeur mais ayant des noms diff rents ont une valeur diff rente D finition 11 14 Compatibilit des types On d finit une relation d ordre large partielle sur un ensemble C de types appel e compat de la mani re suivante i Pour les types simples INTEGER compat REAL CHAR compat STRING ii Pour les types classe Cs compat Cg si et seulement si Cs est une sp cialisation de Cg suivant la hi rarchie d h ritage ror x ko o compat se g n ralise C ainsi lt t h gt compat lt t t n gt si et seulement si n m et Vie 1 n tj compat t i 1 2 D finition des RPO La d finition formelle des r seaux de Petri 4 Objets se fonde sur le pr liminaire math matique nonc ci dessus 42 IL 1 Les R seaux de Petri Objet D finition IL 15 R seau de Petri Objets Un R seau de Petri Objets R lt C T V P Pr Post gt est d fini par les l ments suivants 1 Un ensemble C de types U a C Dom t sera appel l univers de R 2 Un ensemble T de transitions 3 Une famille Vte r d ensembles de variables non n cessairement disjoints indic e par T Onnote V t T v Pour ces familles Vite 7 on d finit une famille
48. attribut de type simple est appel une propri t e Un attribut de type classe est appel une r f rence Il nous faut faire une remarque d ordre m thodologique quant la possibilit pour une classe de rendre publics des attributs dans sa sp cification cette possibilit n est pas essentielle et certains langages objet tel Smalltalk s en dispensent compl tement L acc s aux attributs pose plusieurs probl mes e D une part dans un contexte de programmation concurrente l acc s un attribut constitue un couplage bien plus intime que l invocation qui peut tre implant e par passage de messages entre processus Nous verrons au V 3 que la s mantique de l acc s un attribut d crite en 6 Cette restriction n est pas li e aux fondements th oriques du formalisme et on pourrait envisager de fournir la possibilit de surcharge comme facilit syntaxique 89 U1 3 Sp cification d une classe termes de RdP est tr s diff rente de celle de l invocation Il y a donc lieu de s interroger sur l opportunit de publier des attributs si l objet doit tre faiblement coupl avec son environnement par exemple implant sur un ordinateur distant e D autre part la publication d un attribut a des r percussions importantes sur l organisation de l h ritage qui est discut e au IV 2 les attributs publi s par une classe anc tre doivent tre galement publi s par toute classe d riv e en publiant un attrib
49. cas un logiciel est une collection de structures de donn es plus ou moins universelles agenc es pour obtenir une fonctionnalit sp cifique L approche objet vise donc permettre un processus de conception guid par les donn es mais s attache cacher la repr sentation interne de ces donn es en n autorisant leur acc s qu travers un ensemble d op rateurs qui masquent aux utilisateurs de l objet les d tails de son implantation physique Ainsi la dichotomie entre donn es et traitement dispara t et l objet est une entit qui rassemble ses donn es propres et les op rateurs susceptibles de les manipuler Rumbaugh 91 caract rise une approche orient e objet par quatre crit res e Le premier est l identit tout objet une identit sa r f rence et les r f rences d objets sont uniformes et ind pendantes du contenu ce qui permet de constituer des collections d objets h t rog nes e Le second est la classification tout objet est une instance d une classe qui d finit sa structure et son comportement e Le troisi me est le polymorphisme c est dire la propri t qu un m me traitement ait des interpr tations diff rentes selon la classe de l objet auquel on l applique e Le quatri me est l h ritage qui permet de relier les diff rentes classes en une hi rarchie taxonomique et qui est essentiel pour promouvoir l extensibilit et la r utilisabilit des classes L architecture d
50. cas du VII 1 est un bon exemple d une telle technique de conception Un objet composite est simplement constitu d instances composantes et n a pas d existence ind pendamment d elles Les services qu il offre ses clients doivent donc n cessairement tre des services offerts par ses instances En g n ral un objet composite ne publiera qu un sous ensemble restreint des services offerts par ses composants ces services repr sentant des op rations d un niveau d abstraction sup rieur 3 1 D finition d une classe composite Comme pour toute classe d objets on va fournir pour une classe composite deux descriptions une sp cification l usage des clients de la classe et une impl mentation d crivant la structure interne des instances Nous illustrerons les diff rents points de la d finition par un exemple sans signification uniquement destin mettre en lumi re les conventions syntaxiques utilis es Nous traiterons ensuite un exemple significatif la Table des philosophes o les objets composants sont les philosophes de Dijkstra 130 IV 3 Hi rarchie de composition a specification d une classe composite La sp cification d un objet composite a la m me structure que celle d un objet atomique Le fait d tre composite ou atomique est une caract ristique de l impl mentation d une classe e La sp cification d une classe ne mentionne pas le fait que les instances sont atomiques ou composites Au niveau de
51. cette m me op ration L impl mentation indique galement les contraintes temporelles d utilisation des objets de la classe correspondant ici au temps de transit des palettes Les places de capacit 1 en entr e et en sortie permettent d viter que des palettes n entrent ou ne sortent de la section une vitesse sup rieure la vitesse de transit nominale pour un l ment On peut galement remarquer que l inverse de la plupart des exemples que nous avons d j rencontr s l impl mentation n a pas compliqu l op ration Transmettre qui reste mod lis e comme une simple transition Ici et ce sera le cas dans le reste de cet exemple l impl mentation a essentiellement pour but de raffiner le comportement interne de l objet en rendant plus fine la description de son espace d tats 199 VIL 1 Mod lisation d un atelier flexible Class Implementation Transport Attributes capa INTEGER Capacit en nombre de palettes t INTEGER Temps l mentaire de transit pr c dent Transport Operations Peut_traiter lt pal Palette gt lt r BOOLEAN gt is do r FALSE end Create lt cap temps INTEGER gt is capa cap t temps end ObCS Entree Sortie lt Palette gt Circule lt Palette gt Hard FIFO TRANSMETTRE Circule capa 2 Figure VII 10 Impl mentation de la classe Transport d La classe Derivation Une d rivation est
52. classe composite Table Class Specification Table Services garnir lt riz Nourriture gt create nom l nom 2 nom 3 STRING is Pr t lt gt Garnir Figure IV 8 Sp cification de la classe Table La classe composite Table mod lise une table de trois philosophes Le seul service qu offre la table de philosophes son environnement est la r ception de riz pour le r approvisionnement du plat sa sp cification est d crite en Figure IV 8 Son ObCS de sp cification montre seulement que le service Garnir n est pas toujours disponible Compound Class Implementation Table Attributes R f rences vers les objets composants Chef_de_table Ph 2 Ph 3 Philosophe Services fonction de traduction garnir lt riz Nourriture gt Chef_de_table garnir_le_plat create nom l nom 2 nom 3 STRING is 1 Cr ation des instances des objets composants et initialisation de leurs propri t s Chef_de_ table Philosophe Create nom 1 Ph 2 Philosophe create nom 2 Ph 3 Philosophe create nom 3 2 Initialisation des r f rences des objets composants d finit les relations d utilisation entre instances Chef_de_table SETgauche Ph Chef_de_table SETdroite Ph Ph 2 SETgauche Ph droit _Tabl Ph Chef_ Chef_de_Tabl Ph
53. classe le couple constitu par le RPO et la fonction Disp L ex cution d un service par l objet quivaut au franchissement d une des TS associ es ce service lorsqu un objet re oit une invocation il ne peut l ex cuter que si l une des TS associ es ce service est franchissable dans le RPO Lorsque cette invocation est effectivement ex cut e la TS correspondante est franchie et le marquage du r seau est modifi en cons quence La liste des param tres d entr e d un service ventuellement vide est indiqu e sur l arc d activation de chaque transition associ e De m me la liste des param tres de sortie est report e sur son arc de compl tion Ce report explique pourquoi on a choisi d utiliser les d limiteurs lt gt dans la syntaxe de d finition des listes de param tres et de valeurs de retour des services ces d limiteurs sont classiquement utilis s dans la repr sentation graphique des n uplets de variables dans les r seaux Pr dicats Transition et ici on identifie la 91 II 3 Sp cification d une classe liste de param tres d entr e resp de sortie d un service avec un n uplet de variables d entr e resp de sortie de chaque transition associ e L ObCS peut contenir des transitions qui ne sont pas associ es un service ces transitions appel es Transitions Priv es TP servent mod liser des changements d tat internes l objet qui ne sont pas directement d clench s par
54. confirm e et repr sent e graphiquement par un rectangle surmontant un trait Figure VI 1 Dans une invocation non confirm e les valeurs de retour du service invoqu sont bien entendu inaccessibles et ne peuvent tre affect es des variables de sortie de la transition END Service retour f param x lt retour Figure VI 1 Syntaxe graphique d une invocation non confirm e L impl mentation d un tel mode de communication est tr s simple lors de la premi re tape de construction du WSCS V 3 1 les places de sortie de la TI sont reli es la transition d appel et non plus la transition de compl tion le reste du proc d de construction demeure identique La transition de compl tion notamment a alors pour but de consommer le jeton typ r sultat de l ex cution du service lt b self gt lt b id a gt gt Cparam lt a b id self gt lt param id self gt lt param x id self lt param x id self END Service retour f param x lt retour id Figure VI 2 S mantique d une invocation non confirm e La figure VI 2 illustre la syntaxe graphique d une invocation non confirm e et la figure 11 40 en donne la s mantique avec une partie du WSCS g n r par une telle invocation Une invocation non confirm e est l quivalent d une type de message PAST du langage ABCL Yonezawa 86 1 2 3 ou d une requ te ASER de la m thode HOOD 1 3 172
55. de n_uplet peut d clencher un message d erreur modal c est dire une fen tre o l utilisateur est contraint de signaler imm diatement sa prise en compte de l erreur avant de poursuivre son dialogue pilot par v nements Figure VII 25 Editeur de n uplets Identifiant Attribut x Attribut y R tablir Item 02 Item 03 ltem 04 Le n uplet Item 03 est d j pr sent dans la table Ajout impossible Figure VII 25 L diteur de n uplets avec un message d erreur modal Le n uplet est en outre capable de s ajouter ou de se d truire dans sa table relationnelle et d afficher ses valeurs dans une fen tre 217 VIL2 Interfaces Personne logiciel c Dialogue C est pour la sp cification du Dialogue ou du Contr le suivant la terminologie de J Coutaz que l utilisation du formalisme des Objets Coop ratifs se trouve pleinement justifi e Nous allons mod liser la partie Dialogue du mod le Seeheim par une classe d Objets Coop ratifs munie de son ObCS qui va d crire la structure du dialogue et la r partition du contr le entre utilisateur et application 218 VIL2 Interfaces Personne logiciel Class impl mentation Editeur Attributes f Fen tre Fen tre d dition des attributs du n uplet Services Editer Effectuer une op ration d dition quelconque sur Le n uplet s lectionn Remplacer Remplacer le n uplet courant par celui en cours d dition Ajouter Ajouter le n uplet
56. de donn es et services l approche objet est aujourd hui suffisamment riche pour que l on y trouve facilement les concepts les mieux adapt s nos objectifs Un objet sera donc d fini comme une instance de sa classe et pourvu d un ensemble d attributs et d un ensemble de services ou m thodes qui permettent la manipulation de ses attributs Cette d finition est faite d une mani re tr s classique proche du langage Eiffel La structure d un objet est enrichie par l ajout d un ObCS Object Control Structure 1 3 6 qui d finit sa structure de contr le interne ou son comportement Les ObCS sont d crits par des R seaux de Petri Objets II 1 2 et permettent de d crire la disponibilit des services en fonction de l tat interne de l objet et les changements de cet tat produits par l ex cution des services Le r le d un objet dans un syst me est d aider les autres objets en mettant leur disposition ses services et en accomplissant les demandes d ex cution de services les invocations qu il re oit Un 83 Introduction objet peut ainsi tre consid r du point de vue de ses clients les objets pour le compte desquels il ex cute des op rations ou du point de vue de ses serveurs les objets qu il invoque La d finition d un objet du point de vue de ses clients est sa sp cification Elle inclut ceux parmi ses attributs qui sont accessibles en lecture par d autres objets les op rations qui peuvent tre i
57. de l tape pr c dente 2 De m me on fusionne la place r sultat en entr e de chaque transition de compl tion avec la place r sultat en sortie de la transition de retour du service correspondant Les tapes 1 3 assurent que les places que l on fusionne cette tape sont de m me type Cette derni re tape de fusion cr e galement des conflits entre transitions ici ce sont les transitions de compl tion du m me service qui sont en conflit toutes n cessitant une marque dans la place r sultat du service Ce conflit ne cr e pas d ind terminisme dans l volution du r seau car il est lui aussi r solu dynamiquement et de mani re d terministe par unification sur la variable id l estampille d appel Une Transition d Acc s TA est par d finition une transition qui comprend dans sa partie action ou pr condition une expression de la forme var atty atty atty ou var est de la classe CI et att est de la classe Clj pour i 1 n Une telle expression est syntaxiquement correcte uniquement si Cl a un attribut public att de classe Cl Cl a un attribut public att 1 de classe Cl 7 pour i 1 n 1 Il nous faut maintenant implanter l acc s aux attributs publics dans le WSCS 3 Pour chaque TA dans les ObCS que l on fusionne il faut La relier en entr e et en sortie la place attribut att de l ObCS de Cl Les arcs incidents sont tiquet s par lt att var gt La relier en entr e
58. de tri fort ascendant resp descendant V j m p Trip Val S Pr p t lt Trip resp Trip Val S Pr p t 2 Trip 4 Vpe P telle que Pr p t 0 et Trip est un crit re de tri faible ascendant resp descendant V S tel que S Pr p t lt m p Trip Val S Pr p t lt Trip Val S Pr p t resp Trip Val S Pr p t gt Trip Val S Pr p t Pour une transition t donn e il n y a pas de diff rence entre le tri faible et fort de ses places d entr e si t ne comporte pas de pr condition et s il n y a pas de contrainte d unification sur ses variables d entr e 63 II 2 Extension des RPO i e si chaque variable d entr e ne figure que sur un seul arc Dans ce cas en effet les jetons qui optimisent un crit re de tri se trouvent forc ment dans une des substitutions possibles Nous allons montrer que les places fortement tri es mention Hard sont une simple abr viation des RPO et nous allons d crire des motifs permettant de les muler Les places faiblement tri es mention Soft par contre sont une extension du mod le puisque le choix se fait alors parmi l ensemble des substitutions possibles Leur introduction tend donc le pouvoir d expression du formalisme Nous commen ons par la pr sentation de deux abr viations des RPO permettant d exprimer qu une place est g r e en pile ou en file Sibertin 87 a Place file Figure 11 16 Un motif se co
59. der au m me ensemble d attributs le long de la hi rarchie d h ritage afin que les places attributs puissent tre fusionn es 182 VI 3 Flots de donn es i MMMM ObCS d extension de Cserveur ObCS d extension de Cclient 7 g 4 lt id self gt lt attx sel Z lt atty a gt lt x self lt atty self gt lt x self gt Figure VI 11 WSCS g n r par l invocation d un data flow Une invocation concernant un data flow n a aucune influence sur le contr le du client ni sur celui du serveur Une telle invocation peut donc intervenir dans une pr condition ou dans le corps d une op ration interne algorithmique du client Ceci permet de rem dier aux limitations des op rations internes d crites en III 4 2 la raison pour laquelle on avait interdit l utilisation des invocations dans le code des op rations internes tait d imposer que tous les flots de contr le entre objets soient d finis dans les ObCS d impl mentation Un data flow ne repr sentant pas un flot de contr le cette restriction peut tre lev e sans remettre en cause la s mantique formelle de la coop ration entre objets d crite par le WSCS Dans ce mode de communication c est le client qui ex cute le code algorithmique associ un service C est la s mantique que la m thode HOOD donne aux op rations sans contrainte fonctionnelle d activation cf 1 3 L expression a OP1 lt x gt qui appara t dans la
60. des invocations La d finition d un ObCS de sp cification doit se restreindre un sous ensemble de la syntaxe d finie au chapitre II 1 2 Les restrictions sont les suivantes Les attributs publi s par la classe sont utilis s comme registres de l ObCS cf II 2 2 La d finition du RPO ne doit pas comporter d autres registres on verra au III 4 que cette restriction est lev e lors de la d finition de l impl mentation de la classe Les actions associ es aux transitions de l ObCS ne doivent pas contenir d invocation utiliser une invocation reviendrait en effet pr ciser un des services requis par les instances de la classe d s sa sp cification pratique que nous avons rejet e Une action sera donc constitu e uniquement d affectations et d expressions simples des variables d entr e de la transition Syntaxe graphique de l ObCS Bien que la structure d un r seau de Petri soit donn e par ses fonctions d incidences Pr et Post on pr f re en g n ral consid rer sa repr sentation graphique plus lisible Les conventions graphiques suivantes illustr es en Figure IIL 4 sont appliqu es pour la description d un ObCS que ce soit un ObCS de sp cification ou un ObCS d impl mentation que nous d crivons ci apr s Le nom d une place appara t en italique l int rieur de l ellipse qui la repr sente Pour all ger la repr sentation graphique du r seau et pour minimiser les croisements d arcs qui diminu
61. dialogue fournit en aram tre du service l identifiant du n uplet d sign p p gn e La case de fermeture en haut et gauche du cadre de la fen tre est associ e au service Quitter e Enfin tous les l ments de dialogue de la zone d dition sont associ s au service Edit Ainsi une action quelconque sur un de ces l ments qui a pour effet de modifier la valeur d un des rar pate Une fois ces associations tablies ont peut donner un aper u de la dynamique du dialogue en d crivant comment les actions de l utilisateur font voluer le marquage de l ObCS et r ciproquement comment ce marquage active ou inhibe les d clencheurs de l interface e Avec le marquage initial d crit par l op ration Create on dispose d un n uplet avec des valeurs par d faut dans la place D faut Seuls sont actifs les l ments de la zone d dition la transition T1 associ e au service Editer est franchissable et le bouton Ajouter transition T2 e Apres avoir fix les valeurs d sir es pour le n uplet l utilisateur invoque le service Ajouter transition T2 qui fait passer le n uplet dans l tat S lectionn e A partir de cet tat l utilisateur peut invoquer le service D truire transition T3 qui le ram ne au marquage initial Plus probablement il choisira d Editer transition T4 le nouveau n uplet stockant ainsi dans la place Edit le couple lt o dup gt qui d signe respectivement le n uplet initial et celu
62. du conflit de nom des caract ristiques h rit es se pose cf I 1 4 La solution que nous avons retenue est celle du langage Eiffel qui consiste en un renommage des caract ristiques en conflit D finition IV 3 H ritage multiple et renommage des services Soient Cg1 et Cg2 deux classes qui ne sont pas en relation d h ritage s un service publi la fois par Cg1 et Cg2 Cs une classe descendante directement ou indirectement de Cg1 et Cg2 alors La clause d h ritage de Cs devra d finir une renomination d un des services en conflit de la forme inherit Cgl rename s as lt nouveau nom gt Cg2 Un classe d finie par h ritage multiple doit tre compatible avec chacun de ses anc tres en utilisant le m me crit re de compatibilit que pour l h ritage simple cf SIX 4 128 3 HIERARCHIE DE COMPOSITION Nous avons jusqu pr sent rencontr deux types de relation possibles entre classes d objets e La relation d h ritage est un qui d crit le fait qu une classe est une sp cialisation d une autre e La relation d utilisation qui d crit le fait qu une classe a besoin des services offerts par une autre pour r aliser ses fonctions Dans le formalisme des Objets Coop ratifs le fait qu il existe une relation d utilisation entre deux classes C et C2 C utilise C2 se traduit par le fait que C7 poss de des r f rences vers des instances de C2 Ces deux relations entre classes permett
63. la description statique de la structure et du comportement des objets instances de cette classe qui seront cr s dynamiquement Dans le formalisme des Objets Coop ratifs l unit de conception est la classe d objets L objet instance d une classe est le composant de base du syst me Il favorise l abstraction en donnant la possibilit de d crire s par ment la sp cification d une classe d objets et son impl mentation tout en autorisant une v rification formelle de la coh rence de ces deux descriptions e Il permet le masquage d information et l encapsulation en d finissant pour une classe des op rateurs d acc s qui cachent la structure de donn e physique des instances e C est un langage fortement typ le type de chaque entit variable constante param tre du langage fait partie de sa d finition et ce type d termine son domaine de valeur Le type d une expression quelconque du langage peut tre d termin de mani re statique au simple examen du texte de la classe dans laquelle cette expression est d finie e C est un langage s mantique de r f rence la manipulation des objets se fait par l interm diaire de leur r f rence on parle aussi de nom des objets et des op rations telles que l affectation ou la comparaison portent sur les r f rences et non sur la valeur des objets r f renc s e Crest un langage cr ation dynamique les objets peuvent tre cr s dynamiquement d
64. la mesure o la description de l atelier ne pr voit pas de montrer l arriv e des composants et la sortie des produits finis un Atelier est un syst me clos sans interface Sa d finition est donn e en figure VII 8 Compound Class Implementation Atelier T1 Transport pr c dent pr c dent X T2 Transport D2 Derivation I2 Hot POR OP1 C1 B4 distributeur 2 istributeur OP2 C2 B3 OP3 C2 pr c dent OP4 C3 B3 OP5 C4 B4 pr c dent T3 Transport I1 Hot distributeur OP1 A1 OP2 B1 OP3 A2 B2 sues pr c dent OP4 A3 B2 pr c dent OPS A4 T4 Transport Figure VII 8 Classe composite Atelier c La classe Transport La classe Transport mod lise le comportement d une bande transporteuse une voie telles que celles qui composent l anneau de distribution Sa sp cification pr sente seulement son comportement abstrait et n indique donc pas les contraintes temporelles de son utilisation ici le temps de transit des palettes qui parcourent la section de transport Cette classe illustre galement l utilisation des places a capacit cf IL 2 4 et des places tri es cf II 2 7 la mention Hard FIFO indique que les palettes sont fournies par l op ration Transmettre dans l ordre o elles ont t re ues par l interm diaire de la transition Recevoir Une instance de transport connait son l ment pr c dent lui aussi instance de transport ou d
65. le franchissement de cette transition correspondant au temps mis par le serveur pour accomplir le service Ce d lai d pend uniquement de l tat du serveur et peut ventuellement devenir infini si le marquage de l ObCS du serveur est tel que le service ne puisse plus devenir accessible Dans ce cas l invocation ne se termine jamais et le franchissement correspondant reste pour toujours suspendu chez le client Afin de donner au client plus de contr le sur ses invocations nous allons d finir deux nouveaux modes d invocation en les munissant d une repr sentation graphique en d crivant comme pour le rendez vous leur s mantique formelle par le RPO quivalent la s quence d appel et en explicitant la mani re de les int grer dans le proc d de construction du WSCS d crit en V 3 Il faut souligner que ce sera toujours au client de d cider du mode d invocation d un service le serveur n est pas inform du mode avec lequel il est invoqu 1 1 Invocation non confirm e Dans certains cas il peut tre significatif pour un client d envoyer un serveur un signal ou un message sans attendre en retour ni r sultat ni accus de r ception Ce mode de communication est utile par exemple pour d crire des situations de diffusion d information multi casting ou pour impl menter le m canisme de la continuation des langages d acteur Hewitt 77 171 VII Modes d invocation des services Un telle invocation sera dite non
66. lisation d un atelier flexible a La classe Transport_double Tous les objets qui figurent dans un Ilot ont un objet Pr c dent et ils ont deux voies de circulation Nous allons donc d finir une classe g n rique Transport_double qui jouera vis vis d eux le m me r le que Transport pour les l ments du distributeur L op ration Peut_traiter la m me s mantique que pour la classe Transport et sera implant e de fa on diff rente dans chacune des sp cialisations de cette classe L op ration Passe_ _droite indique si la section pr f re recevoir la palette sur sa voie de droite ou de gauche Class Specification Transport double Services Gauche lt pal Palette gt Droite lt pal Palette gt Consultation Services Peut_traite lt pal Palette gt SETpr c dent lt p Transport_double gt BOOLEAN Passe _ _ droite lt pal Palette gt BOOLEAN Obcs GCircule DCircule lt Palette gt GCircule capa GAUCHE DROITE Figure VII 15 Sp cification de la classe Transport_double L impl mentation de Transport_double est tr s simple reprenant les principes d impl mentation de la classe Transport Elle se contente de faire progresser une palette et la passe au suivant sur la m me voie que celle sur laquelle elle l a re ue 204 VIL 1 Mod lisation d un atelier flexible Class Implementation Transport _ double Attributes pr c dent2 Trans _2_ voie
67. logiciel temps r el Software Engineering and its Applications Toulouse dec 1988 VALETTE R PALUDETTO M LABREUILLE B P FARAIL P Approche orient e objet HOOD et r seaux de Petri pour la conception de logiciel temps r el Proc of 15t International Workshop on Software Engineering and its Applications EC2 Toulouse France December 1988 252 Vielcanet 90 Ward 85 Wasserman 85 Weinreb 80 Winston 81 Wirfs Brock 90 Wirth 71 Yokote 87 Yonezawa 86 Yonezawa 87 Bibliographie VIELCANET P HOOD Design Method and Control Command techniques for the Development of Real Time Software CISI Ing ni rie Aerospace Branch 1990 WARD P MELLOR S Structured analysis for Real Time systems Prentice Hall New Jersey 1985 WASSERMAN A Extending State Transition Diagrams for the Specification of Human Computer Interaction IEEE Transactions on Software Engineering Vol 11 N 18 August 1985 WEINREB D MOON D Flavors Message Passing in the Lisp Machine AI Memo 602 MIT Artificial Intelligence Laboratory November 1980 WINSTON P H HORN B K P LISP Addison Wesley 1981 WIRFS BROCK R WILKERSON B WIENER L Designing Object Oriented Software Prentice Hall 1990 WIRTH N Program development by step wise refinement Communications of the ACM vol 14 N 4 pp 221 227 April 1971 YOKOTE Y TOKORO M Concurrent Programming in Concurrent Smal
68. logiciel et de la circulation de documents 234 Conclusion L utilisation dans d autres domaines sugg rera sans doute de nouveaux enrichissements par exemple c est la mod lisation des ateliers flexibles qui a sugg r la d finition des places tri es et la hi rarchie de composition extensions qui ne sont pas forc ment significatives dans d autre domaines L utilisation de ce formalisme en tant que langage de programmation n cessiterait certainement d autres m canismes on peut penser par exemple un m canisme d exceptions permettant de prendre en compte les cas de mort des objets Objets Coop ratifs et m thodologie Les Objets Coop ratifs pr sentent le grand avantage de pouvoir tre utilis s en tant que formalisme ou en temps que langage tout au long du cycle d un d veloppement logiciel Toutefois si un formalisme peut tre d usage g n ral une m thode est n cessairement tr s li e son domaine d utilisation et il faudrait d velopper pour chaque domaine un corpus de r gles m thodologiques permettant l utilisation correcte du formalisme Le formalisme des Objets Coop ratifs est en lui m me l apport central de ce m moire Nous souhaitons galement mettre en avant deux autres contributions originales e Nous avons d fini au chapitre II 2 des extensions aux R seaux de Petri Objets notamment les places tri es les arcs inhibiteurs g n ralis s et le registre temporel qui sont san
69. m thode HOOD PNO met profit l utilisation des RdP pour guider le concepteur dans son processus de mod lisation pour la d couverte de nouveaux objets Apr s avoir d finie par un RdP le comportement d un objet de niveau n l analyse des invariants lin aires des places de son ObCS permet de d terminer des bons candidats comme ObCS des objets de niveau n 1 Cette utilisation d une technique d analyse formelle au sein m me d un processus de conception est particuli rement remarquable car les techniques couramment propos es pour la d couverte des objets Booch 87 Meyer 90b sont le plus souvent d ordre empirique et ce probl me pr occupe particuli rement les ing nieurs logiciels qui souhaitent suivre une d marche Orient e Objet Enfin la m thode se poursuit jusqu au niveau de la production de code en d finissant des r gles de traduction semi automatique en traduisant par des structures de contr le Ada les ObCS des objets de la conception Les principes fondamentaux de la m thode HOOD PNO sont comparables ceux de notre approche et nous avons personnellement eu de nombreuses r unions de travail avec M Paludetto et les autres membres du groupe IPANEMA conduit par Robert Valette o certaines de ces id es ont vu le jour Pour situer plus pr cis ment notre contribution par rapport la sienne citons les points suivants e HOOD PNO est une m thode compl te qui couvre tout le cycle de vie et est plus particuli re
70. objet moniteur et l approche objet processus Toutefois le mod le des acteurs qui a donn lieu un grand nombre de travaux a introduit des primitives idiosyncratiques qui m ritent un chapitre elles seules 26 27 Le clonage dans l approche par acteurs le concept de classe est absent le m canisme d instanciation d une classe qui produit un nouvel objet est remplac par la notion de prototype Senteni 90 un prototype est la fois un moule servant la g n ration de nouveaux acteurs et une instance dont les fonctionnalit s sont tendues la production de ses propres clones Les clones sont d finis de mani re diff rentielle en sp cifiant uniquement ce qui les distingue de leur prototype On peut de cette mani re changer dynamiquement le comportement de toute une famille d acteurs en changeant le comportement de leur prototype La communication La seule primitive de communication entre acteurs est l envoi de message qui est asynchrone et unidirectionnel Il n existe pas du moins dans le mod le de base de primitive de communication synchrone du type question r ponse A nsi par exemple l acc s par un acteur x une variable d tat d un autre acteur y n cessite t il deux transmissions de messages avec un protocole bien d fini x envoie une requ te y r clamant la valeur de l attribut x se place ensuite en position de refuser tout message sauf la r ponse attendue de y y t
71. objets o un objet client n utilise pas toujours les m mes objets serveurs 3 6 D finition des ObCS HOOD n impose aucune notation particuli re pour la d finition des ObCS L environnement cible d une conception HOOD tant le langage Ada la mani re la plus naturelle d exprimer les structures de contr le est d utiliser les constructions pr sentes dans ce langage savoir les primitives de gestion des t ches et le rendez vous Toutefois d autres formalismes sont propos s dans le manuel de r f rence HOOD on peut citer le langage ESTEREL les primitives de communication offertes par des ex cutifs temps r els ou les r seaux de Petri La mani re formelle d int grer ces formalismes externes n est toutefois pas d crite 3 7 Conclusion L objet est l entit primordiale d une conception HOOD et toute la d composition se fait en termes d objets et non pas en termes de classes comme dans d autres approches On a vu 1 3 5 que le concept de classe est pr sent en HOOD sous une forme assez loign e de son acception usuelle dans les mod les objets Il est donc difficile en HOOD de factoriser la structure et le comportement d objets identiques au sein d une seule entit la classe D autre part des notions li es au concept de classe telles que l instanciation l h ritage et le polymorphisme ne peuvent pas tre prises en compte Enfin la relation d utilisation senior junior est d finie statiquement par la concepti
72. par des soci t s priv es Techlog 89 et d autres tant du domaine public gt On pourrait envisager partir de la description des classes et de la d finition du syst me de g n rer directement le WSCS sous la forme des structures de donn es accept es par ces outils pour la description des r seaux qu ils traitent Cette solution aurait pour inconv nient que les r sultats obtenus par l ex cution d un mod le seraient donn s en termes du WSCS et qu il pourrait alors tre difficile de les interpr ter en termes d objets et de classes Les travaux de Taubner 87 Buetler 89 visent am liorer l efficacit des interpr tes de RdP par une impl mentation distribu e utilisant un algorithme parall le Une autre possibilit est de coordonner l activit de plusieurs interpr tes de telle sorte que chacun ex cute une partie du r seau global Cette solution est judicieuse quand les sous r seaux mod lisent chacun une partie bien distincte du syst me ces r seaux sont alors ex cut s par leur propre processeur tout comme le sous syst me qu ils mod lisent Si le syst me que l on mod lise est r parti les interpr tes peuvent l tre galement de fa on simuler galement les communications dans le syst me Cette d composition en sous r seaux significatifs est le r sultat naturel d une mod lisation conduite en s appuyant sur l approche Orient e Objet En plus de la solution qui consiste interpr ter le
73. plusieurs instances d objets et le nombre de ces instances n volue pas au cours du temps e Le graphe de la relation d utilisation entre ces instances est constant au cours du temps Un tel sous syst me sera mod lis comme une instance d une classe composite Nous pensons fermement que la d composition hi rarchique descendante n est pas essentielle la ma trise de la complexit dans un mod le objets Au contraire il semble que cette vision hi rarchique s oppose en quelque sorte la vision d une organisation coop rative du logiciel qui est la base m me des concepts mis en avant dans le formalisme des Objets Coop ratifs La d composition hi rarchique a en outre souvent pour effet de r duire les possibilit s de r utilisation des objets produits car ceux ci sont plus d pendants de leur contexte Aussi nous ne pensons pas que la hi rarchie de composition doive guider le processus de conception d un syst me donnant ainsi ce processus une dynamique essentiellement descendante Dans un mod le d objets coop ratifs la relation de composition sera essentiellement un outil d abstraction destin masquer la complexit locale d un groupe d objets qui coop rent en les repr sentant sous la forme d une unit fonctionnelle plus agr g e Ainsi la composition pourra tre int gr e dans un processus de conception ascendant permettant ainsi de fonctionner par agr gation plut t que par d composition L tude de
74. pr conditions des transitions en sortie de p est une tautologie Pour all ger la repr sentation des RPO on associe aux r gles d mission un motif graphique qui masque la place et regroupe sa transition d entr e et ses transitions de sortie en une macro transition Figure II 5 Pour assurer que la disjonction des pr conditions soit une tautologie on peut mentionner le mot clef ELSE qui correspond alors la n gation de la disjonction des autres pr dicats 53 II 2 Extension des RPO lt x Vpl vp2 gt lt x VOL YPZ NOT vp1 OR vp2 lt X gt Figure II 5 R gle d mission et notation abr g e Il faut remarquer que les pr conditions des transitions de sortie du motifs sont valu es l occurrence de la transition d entr e ce qui assure que la franchissabilit des transitions de sortie est ind pendante des franchissements qui ont pu avoir lieu dans le r seau depuis l occurrence de la transition d entr e 2 4 Places capacit Lorsqu on mod lise un syst me par RdP il est fr quent d interpr ter une ou plusieurs places du r seau comme des l ments de stockage physique La capacit d un tel l ment i e le nombre d objets qu il peut contenir est n cessairement limit e Il est donc commode d associer la place repr sentant cet l ment une capacit n N n gt 0 sp cifiant le nombre de jeton maximum qu elle peut contenir La d finition de la franchissabilit est
75. requ te en attente sur ce service La valeur des param tres d entr e de la requ te sont unifi s avec les variables d entr e de Sig s Il existe t Disp s tel que Mt On appelle ex cution du service s le franchissement de la transition t 3 7 Propri t s de l ObCS de sp cification L volution d un Objet Coop ratif tant d crite par un RPO nous pouvons profiter des techniques d analyse statique d di es aux r seaux de Petri afin d tudier les propri t s du comportement de chaque objet d une classe Avant tout il nous faut prendre en compte un probl me li la nature m me des ObCS un sous syst me ouvert n est pas destin voluer seul et son comportement ne peut tre tudi sans mettre quelques hypoth ses sur le comportement de son environnement L ObCS d une classe mod lise justement un tel syst me ouvert pour lequel les transitions de service d finissent l interface avec l environnement Avant de pouvoir appliquer les m thodes classiques d analyse des RdP aux ObCS il est n cessaire de fermer ces r seaux de la mani re suivante La cl ture d un ObCS est une op ration qui consiste supprimer les arcs d activation et de compl tion adjacents aux transitions de service du r seau L hypoth se sous jacente est que l environnement du r seau fournit tout instant les jetons n cessaires son volution et consomme les jetons produits l environnement n applique donc aucune contrain
76. s mantique on renonce pratiquement toute possibilit d analyse statique des RdP Un des avantages de cette approche est que les mod les produits sont plus simples et plus lisibles que ceux qu on obtiendrait par les techniques classiques de pliage qui permettent de passer d un mod le de RdP un mod le de RdP color s quivalent mais plus concis Ici le pliage est remplac par une substitution en ligne des sous r seaux Nous donnons ici certains points permettant de comparer cette approche la n tre e Dans les Objets Coop ratifs on pargne galement au concepteur la t che de replier lui m me ses r seaux pour pouvoir g rer plusieurs instances du m me processus dynamique Toutefois le pliage est obtenu automatiquement et sans duplication des sous r seaux e Il est possible dans les Objets Coop ratifs d obtenir des comportements dynamiques et m me r cursifs comparables ceux d crits par les transitions d invocation Toutefois nous obtenons ces comportements avec un r seau global dont la structure n volue pas La technique permettant cela d crite au V 3 serait d ailleurs parfaitement applicable aux transitions d invocation e Enfin les auteurs voquent la possibilit d avoir des couleurs de jetons qui r f rencent d autres r seaux color s mais soulignent que pour le moment cette technique n a pas t retenue D une certaine mani re c est cette possibilit d avoir des jetons qui
77. services de leur environnement e L encapsulation ou la dissimulation d information les services que requiert une classe n ont pas d int r t pour ses clients et aucune d cision concernant l impl mentation des clients ne devrait tre prise au vu de l interface requise par un de ses serveurs puisque cette interface est susceptible de changer e La r utilisabilit si l interface d une classe inclut les informations requises en plus des informations offertes il devient impossible de r utiliser une classe en dehors de son propre contexte L interface d une classe d Objets Coop ratifs est constitu e d un ensemble de types d un ensemble de constantes d un ensemble de services et d un ensemble d attributs chacun de ces ensembles pouvant tre vide On parlera des types constantes services et attributs export s ou publi s par la classe L interface d une classe contient tout d abord des d finitions de types ces types sont utiles pour pouvoir d finir des domaines particuliers pour les param tres en entr e et en sortie des services Pour chaque type export on donne Son nom dont la visibilit s tend toute classe cliente de celle o le type est d fini e Sa construction on peut d crire explicitement comment le type est constitu partir des constructeurs de base et une classe cliente aura acc s tous les op rateurs l gaux sur ce type On peut galement comme en Ada restreindre cet acc s aux s
78. substituer comporte un certain nombre de places d interface en entr e et en sortie qui constituent en quelque sorte les param tres formels de la substitution Le r seau de niveau sup rieur d signera parmi ses propres places celles qui doivent servir de param tres r els la substitution par une notation simple la fois textuelle et graphique e Les places de substitution sont la construction duale des transitions de substitution ou le r seau substituer se comporte comme une place et offre une interface compos e de transitions Si plusieurs transitions du r seau de niveau sup rieur font r f rence la m me transition d interface cette derni re doit tre dupliqu e autant de fois que n cessaire e Les places et transitions de fusion sont essentiellement une facilit graphique permettant de repr senter graphiquement la m me entit place ou transition plusieurs endroits du r seau Nous utiliserons cette facilit dans notre propre formalisme cf SIIL 3 e Enfin les transitions d invocation on pour but d muler l appel de proc dure des langages de programmation Chaque appel ventuellement r cursif implique une instanciation temporaire du sous r seau correspondant donc une modification dynamique de la structure du r seau et 74 II 3 Structuration des mod les de R seaux de Petri de Haut Niveau il est donc impossible de construire un RdP color quivalent Bien entendu avec une telle
79. te En donnant cette construction la s mantique des pr conditions Eiffel un tel cas d clencherait une erreur d ex cution d pendante de l impl mentation physique par exemple l envoi d un message d erreur un op rateur Cette possibilit d j t voqu e par De Bondelli 87 qui parle de pr conditions absolues ou de pr conditions d attente 118 UL 7 Comparaison avec l approche Axiomatique Il existe un autre cas de blocage infini d un client en attente de l ex cution d un service c est le cas ou un client invoque un serveur mort c est dire un serveur pour lequel l ObCS un marquage qui ne rend franchissable aucune transition Une invocation un tel client ne pourra jamais tre servie Ce cas correspond galement une erreur de mod lisation et devrait lever une erreur d ex cution La d finition d une pragmatique par R seaux de Petri pr sente d autres diff rences importantes par rapport une approche par TAD e Notre approche vise fournir une description explicite et d taill e de l espace d tats des objets en pr cisant au maximum l influence de l tat sur la disponibilit des services et r ciproquement l influence de l ex cution des services sur l tat de l objet Un TAD au contraire n a pas d tat plus pr cis ment son espace d tats est d fini de mani re indirecte par les quations qui le r gissent et la notion d effet de bord n existe pas e Dans le langa
80. travail pr sent ici s attache principalement aux trois premiers points cit s ci dessus sp cification conception et simulation Beaucoup reste faire en ce qui concerne l analyse et la validation d un mod le d Objets Coop ratifs mais le caract re formel de ce mod le permet d envisager l utilisation des r sultats g n raux de la th orie des RdP Enfin nous n avons pas tudi la g n ration de code partir de notre mod le mais des r sultats disponibles par ailleurs Paludetto 91 peuvent tre utilis s La premi re partie du m moire est consacr e l tude des deux formalismes qui servent de r f rence aux Objets Coop ratifs l approche objet et les R seaux de Petri e Le chapitre I est consacr l approche objet Il rappelle de mani re succincte les concepts fondamentaux de l approche objet qui sont maintenant bien connus I 1 Nous d crivons ensuite de mani re plus approfondie les diverses propositions qui ont t faites pour prendre en compte la concurrence dans l approche objet 1 2 Enfin le 1 3 pr sente une des m thodes les plus utilis es de conception par objets des syst mes concurrents la m thode HOOD Le chapitre II d crit les r seaux de Petri Objets RPO utilis s pour d crire le comportement et la coop ration des Objets Coop ratifs La section I 1 est une pr sentation formelle et d taill e des RPO n cessaire pour que nous puissions notre tour d finir formellem
81. type _ r de fonctions d finies par type Vv gt C qui s tend en faisant l union avec la fonction type de la D finition II 12 typer Vtv U gt C type Vy Y U Sc 4 Un ensemble P de places pourvu d une fonction type type P gt Cc On appelle arit la fonction arit Po N p arit p longueur type p De ceci on peut d duire V p P type p carit p On dira qu une place p P est de type jeton simple si arit p 0 i e type p 0x Si arit p gt 0 on dira que p est de type jeton typ 5 Une fonction d incidence avant Pr d finie par Pr PXT N VUU pt D Erreur vie VUU telle que i support Pr p t 1 V Vi ii V v e Pr p t longueur v arit p iii V v e Pr p t type v type p On notera p t tic T Pr p tj 0 t pi pi P Pr pj t 0 6 Une fonction d incidence arri re Post d finie par Post PXT gt N VUU pt Erreur gt vie VUU 43 IL 1 Les R seaux de Petri Objet telle que 1 support Post p t V G Vi ii V v e Post p t longueur v arit p iii V v e Post p t type v compat type p On notera p i ti ti T Post p ti 0 t pi pi P Post p t 0 Vin P P support Pr p t A V est l ensemble des variables d entr e d une transition t Vout TP P support Post p t A V est l ensemble des variables de s
82. un l ment de transport une voie mais qui offre en plus un service permettant de d river une palette en transit vers un autre l ment de transport On trouve donc ici une utilisation tr s naturelle de la relation d h ritage entre classes Dans l atelier que nous d crivons une D rivation re oit une palette venant de T4 dans le cas de D1 et venant de D dans le cas de D2 et la transmet soit l lot DZ peut transmettre 71 D2 12 soit l l ment de transport suivant c est dire D2 pour D1 et T1 pour D2 200 VIL 1 Mod lisation d un atelier flexible Class Specification D rivation Inherit Transport Attributes ilot Transport Section vers laquelle on d riv Services Les services Transmettre et SETpr c dent sont h rit s D rive lt pal Palette gt SETilot lt Transport gt ObCS Circule lt Palette gt Hard FIFO TRANSMETTRE Circule capa Figure VII 11 Sp cification de la classe D rivation L impl mentation donn e ici d une section de d rivation est assez sp cifique au contexte de l atelier mod lis on voit que la d rivation ne peut avoir lieu que si la section de transport vers laquelle on d rive Peut_traiter effectivement la palette en transit ceci correspond la clause a des r gles de gestion du distributeur De m me la clause d est assur e par l arc prioritaire cf IL 2 5 en entr e de la place Sortie 201 VIL 1 Mod lisation d un ateli
83. un nouveau processus interpr te qui ex cute l ObCS de l objet nouvellement cr Ce processus est identifi par le nom du nouvel objet La r gle de tir d un interpr te est de ne pas autoriser les franchissements concurrents dans son r seau 224 VIL I Un interpr te par classe d objet 2 UN INTERPRETE PAR CLASSE D OBJETS Cette strat gie n utilise qu un seul processus pour chaque se du syst me L avantage principal est ni le nombre de processus ni la structure des relations que rocessus entretiennent n voluent Les r seaux que l on ex cute dans cette strat gie sont les ObCS d extension V 3 en suivant les r gles suivantes 1 Cr r un processus pour chaque classe du syst me qui interpr te son ObCS d extension avec le marquage initial d fini en V 3 4 Un interpr te est r f renc par le nom de la classe dont il ex cute l ObCS d extension 2 Chaque occurrence d une transition d appel d pose un jeton dans la place param tre correspondante du processus r f renc par le nom de la classe de l objet serveur De m me chaque occurence d une transition de retour d pose le tuple r sultat dans la place r sultat du processus r f renc par le nom de la classe de l objet client 3 Une occurrence d une transition invoquant l op ration Create d pose le n uplet de param tres dans la place param tres de la transition Create dans l ObCS d extension de la classe que l on veut instancier
84. vectoriel L hypoth se de base est que Ja concurrence est exprim e par l interaction de multiples activit s sur des objets partag s Trellis Owl d finit un type sp cial pour d noter les activit s du syst me Il s agit du type Activity Une nouvelle activit peut tre initi e par appel de la primitive create act create Activity FOO a1 a2 L instruction ci dessus cr e une nouvelle activit qui ex cute l op ration FOO avec les arguments aj a2 Le flot de contr le li l activit persiste jusqu la fin de l op ration Le langage fournit les primitives de synchronisation n cessaires pour permettre l acc s aux donn es partag es e Les verrous d exclusion mutual exclusion locks objets manipul s par les trois primitives create acquire et release permettent la d finition de sections critiques e Les files d attentes wait queues sont similaires aux conditions des moniteurs Diff rentes primitives sont galement fournies afin de r pondre aux probl mes li s l utilisation des moniteurs notamment pour permettre un r veil it ratif des processus en attente dans une file Les approches suivantes restent dans la tradition des moniteurs mais se dispensent de la notion de processus en la confondant avec celle d Objet b CLIX SINA Dans le langage CLIX propos par Hur 87 l unique activit d un objet est de r pondre aux messages qui lui parviennent un objet n a donc
85. 0 Bibliographie BRAMS G W nom collectif R seaux de Petri Th orie et Pratique T 1 th orie et analyse T 2 mod lisation et applications ISBN 2 903 60713 3 Masson 1983 BRAUER W Petri nets Applications and relationships to other models of concurrency W Brauer W Reisig G Rosenberg editor LNCS 254 amp 255 Springer Verlag BRINCH HANSEN P Structured Multiprogramming Communications of the A C M Vol 15 N 7 pp 574 578 1972 BRINCH HANSEN P Operating Systems Principles Prentice Hall 1973 BRIOT J P YONEZAWA A Inheritance and Synchronization in Concurrent OOP in ECOOP 87 pp 35 44 BRUNO G ALESSANDRO B Petri net based Object Oriented modelling of distributed systems OOPSLA 86 1986 BUETLER B ESSER R MATTMAN R A distributed simulator for High Order Petri nets 10th European Workshop on applications and theory of Petri Nets Bonn June 89 BURR R J A System Design with Ada Prentice Hall 1984 CARDELLI L A Semantics of Multiple Inheritance in Semantics of Data Types LNCS N 173 pp 51 67 Springer Verlag New York 1984 CARDELLI L WEGNER L On Understanding Types Data Abstraction and Polymorphism Computing Surveys vol 17 n 4 pp 471 522 Dec 1985 CAROMEL D Concurrency An Object Oriented Approach in TOOLS 90 pp 183 197 GROUPE DE REFLEXION TEMPS REEL du CNRS Rapport Le temps r el D partement Sciences Physiques pour l Ing nieur du CNRS Juin 1988 COINTE
86. 1 G n ration d identificateurs 1 GENERATION D IDENTIFICATEURS Afin de pouvoir g rer la dynamicit de l volution du syst me il est n cessaire que chaque objet puisse g n rer des identificateurs qui soient uniques dans toute l tendue du syst me Cette possibilit est implant e par un processus r current chaque objet du syst me a une identit unique et peut donc g n rer un identificateur globalement unique en concat nant son propre nom la valeur d un identificateur localement unique A cette fin on d finit un type simple appel Identificateur chaque objet poss de un attribut priv de type INTEGER not i initialis 0 et une op ration interne appel e gensym en r f rence son quivalent dans le langage LISP Winston 81 dont le code est le suivant gensym Identificateur is G n re un identificateur unique pour tout le syst me do i 1 selfll d note l identit de l objet qui ex cute gensym result concatener self i end gensym Figure V 1 G n ration d identificateurs Plusieurs d finitions sont possibles pour le type Identificateur et la fonction Concat ner Nous avons choisi la solution suivante Type Identificateur STRING Concat ner Identificateur x INTEGER Identificateur renvoie des identificateurs de la forme lt nom d instance num ro d ordre gt llPour d noter l identit de l objet on a pr f r utiliser le mot cl self utilis
87. 11 Arc inhibiteur g n ralis sans pr condition La Figure II 12 montre la combinaison d un arc inhibiteur avec une pr condition Si on donne par exemple Prop a b a b lt 7 la transition T2 est franchissable avec les substitutions b 4 et b 5 Elle n est pas franchissable avec la substitution b 3 car il existe dans P1 une valeur de a a 3 telle que Prop a b est v rifi e T1 b si P2 b Figure IL 12 Arc inhibiteur g n ralis avec pr condition Dans ces figures on a fait figurer en l gende des notations logiques visant a faciliter une compr hension intuitive de la franchissabilit des transitions Une formule du type Tx a si Py a doit tre lue Quel que soit a la transition Tx est franchissable avec la valeur a si le marquage de la place Py contient le jeton lt a gt 60 II 2 Extension des RPO Il faut remarquer que l introduction d un arc inhibiteur inverse la signification habituelle des pr conditions ainsi une transition avec arc inhibiteur et sans pr condition est plus contrainte que la m me transition avec une pr condition T1 x si P1 x et P1 y et Prop y T1 x si P1 x et Prop y Figure IL 13 Arc inhibiteur testant tous les jetons d une place La Figure II 13 illustre la puissance d expression de cette extension la transition T n est franchissable que si tous les jetons dans P v rifient le pr dicat Prop Nous r utiliserons cette techni
88. 25 Chapitre IX Analyse d un mod le d objets coop ratifs Si on souhaite voir fonctionner les objets d un syst me comme l entend le concepteur il est n cessaire que leurs ObCS satisfassent certaines conditions L usage des RPO pour d finir les ObCS nous permet d utiliser les techniques d analyse d velopp es pour ce formalisme afin de prouver un certain nombre de propri t s Les propri t s d un ObCS concernent les aspects suivants e Quel type de comportement doit on attendre d un serveur fiable Il doit produire un r sultat pour toute invocation qu il a accept e ne jamais g n rer de r sultats non r clam s et respecter son mode d emploi c est dire sa sp cification e Les relations entre sp cification et impl mentation sont claires en ce qui concerne sa structure de donn es et les services qu il offre cf SIV 2 1 En ce qui concerne sa structure de contr le on doit assurer la coh rence des ses ObCS de sp cification et d impl mentation De m me la relation d h ritage entre classes est pr cis ment d finie en ce qui concerne les structures de donn es et les services En ce qui concerne la structure de contr le l ObCS d une classe sp cialis e doit tre coh rent avec celui de la classe dont il descend Pour tablir ces propri t s nous allons donner des contraintes portant sur le comportement des ObCS qui peuvent tre v rifi es post riori une fois l ObCS construit Les contra
89. 8 est d appliquer la priorit sur l arc entrant adjacent la place compl mentaire On rencontrera de telles constructions dans l tude de cas du VIL1 56 II 2 Extension des RPO Figure II 8 Priorit s sur les arcs et place capacit 2 6 Arcs inhibiteurs g n ralis s Les arcs inhibiteurs Hack 75 on t introduits afin de permettre le test z ro dans un RdP c est dire conditionner la franchissabilit d une transition au fait qu une place du r seau est vide Il a t d montr Brams 83 Peterson 81 que cette extension dote les RdP de la puissance d expression d une machine de Turing et rend donc leur finitude ind cidable Dans le cadre de RPO nous allons tendre la s mantique des arcs inhibiteurs classiques en introduisant les arcs inhibiteurs g n ralis s qui permettent d exprimer que le franchissement d une transition est conditionn non plus par le fait qu une place est vide mais par le fait qu une place ne contient pas de jeton portant une certaine valeur Si l on consid re que les arcs inhibiteurs classiques permettent d exprimer la n gation en logique des propositions les arcs inhibiteurs valu s vont permettre d exprimer la n gation en logique des pr dicats Nous donnons tout d abord une d finition des arcs inhibiteurs au niveau des RdP simples Cette d finition est une alternative celle de Hack mais est l g rement plus expressive Nous tendons ensuite cette d finition aux R
90. Avec des objectifs aussi diff rents les concepts mis en avant par chacune de ces approches sont souvent distincts et parfois m me contradictoires ainsi une approche de type intelligence artificielle privil giera des techniques souples favorisant une programmation de type exploratoire et incr mentale une approche de type g nie logiciel au contraire utilisera des techniques plus contraignantes afin d obtenir une fiabilit et une prouvabilit sup rieure Le travail pr sent dans ce m moire se situe clairement dans le domaine de l approche g nie logiciel aussi notre pr sentation de l approche objet se limitera t elle ce domaine Notre travail porte plus sp cialement sur l expression de la concurrence au sein de l approche objet aussi notre pr sentation des concepts de base de l approche objet sera t elle br ve d autant que les textes qui portent sur ce sujet abondent Meyer 90b Rumbaugh 91 Cointe 86 Booch 87 entre autres Le chapitre est organis comme suit Introduction La section I 1 est un rappel des fondements de l approche objet en insistant plus particuli rement sur ceux qui ont guid la conception de notre formalisme La section II 2 est une revue bibliographique assez d taill e des principales propositions faites pour int grer la description de la concurrence et du parall lisme dans l approche objet La section II 3 enfin est consacr e la m thode HOOD 1 LES FONDEMENTS DE L APPROCHE
91. B voir paragraphe 4 b Un produit est autoris quitter l lot d s que toutes les op rations qu il devait y subir sont r alis es c A chaque palette est affect e une gamme de fabrication qui correspond la suite logique des op rations subir Ainsi pour une gamme donn e plusieurs routages sont possibles pour le produit en fonction des al as de production et des r gles de gestion Au niveau des trajectoires si le poste suivant logique dans la gamme de fabrication correspond au poste suivant physique implantation lignel la palette transitera par l anneau ext rieur Dans le cas contraire elle rejoint le poste suivant par l anneau int rieur 13 Architecture d un atelier de fabrication selon laquelle la succession spatiale des postes de travail co ncide avec le s quencement des op rations ex cuter sur chaque pi ce 191 VII 1 Mod lisation d un atelier flexible Sens de Stoppeur s curit au ture du circulation tireur code palette Stoppeur S gt gt pousseur Stoppeur tireur MODULE i Stoppeur Stoppeur indexage s curit au pousseur Capteur Figure VII 2 Architecture d une cellule de production L atelier fonctionne en flux tir l Un stock amont satur sur un poste entraine la poursuite du cheminement de la palette sur l art re centrale La palette reste sur l anneau central et cherche le poste le plus proche pouvant ex cuter la m me op ration en fonction
92. D se trouvent la fois dans la m thode dite des machines abstraites Abstract Machines ou AM et dans la m thode OOD Object Oriented Design Booch 83 Cette m thode d velopp e l initiative de L Agence Spatiale Europ enne ESA par un consortium constitu de Cisi Ing ni rie CRI A S et Matra Espace est utilis e dans les projets Colombus et Herm s 3 1 Les concepts HOOD propose une d composition hi rarchique de la conception dans l espace de la solution fond e sur l identification d abstractions dans l espace du probl me HRM 89 HOOD met l accent sur la hi rarchisation de la solution et impose deux types de hi rarchies e La hi rarchie senior junior o des objets seniors au sommet de la hi rarchie contr lent et utilisent des objets juniors C est au sein de cette hi rarchie que sont prises en compte les contraintes de forte coh sion et de faible couplage e La hi rarchie parent enfant qui permet la d composition d un objet en autres objets plus simples et qui est consid r e comme n cessaire pour permettre la sous traitance dans le d veloppement du logiciel Dans HOOD l unit fondamentale de modularit dans la conception est l objet Un objet est un mod le d une entit du monde r el qui combine les donn es et les op rations qui agissent sur ces donn es Un objet poss de une partie visible l interface et une partie cach e le corps d sign en anglais par le terme internals laquel
93. EALABLES D finition IX 1 S quences franchissables de transitions Soit N C T V P Pr Post le RPO de l ObCS d une classe et M sa distribution initiale de jetons 227 IX 2 V rification de l ObCS d un serveur T est l ensemble des s quences finies de transitions de T L N M 6 a MS gt est l ensemble des s quences franchissables de transitions Soito e T etTDT i G T E T est la sous chaine de obtenue en enlevant de les occurrences de T T et LN M T 0 T o LN M Sice Tet te T alors o t est le nombre d occurrences de t dans o Pour un service s accept par un serveur on notera Sac sa transition d accord et sret sa transition de retour Tac et Tret sont respectivement les ensembles des transitions d accord et de retour de l ObCS d un serveur 2 VERIFICATION DE L OBCS D UN SERVEUR Les contraintes suivantes visent 4 assurer qu un serveur se comporte toujours correctement du point de vue de ses clients Dans l ObCS de sp cification un service offert appara t comme une seule transition et le fait d accepter une requ te ne peut pas tre dissoci de celui de renvoyer un r sultat Ce n est plus le cas dans l ObCS d impl mentation o l ex cution d un service s tend sur plusieurs transitions Afin que l on soit assur qu un serveur renvoie un r sultat si et seulement s il accepte une requ te son ObCS d impl mentation doit satisfaire les deux crit
94. Figure V 13 Figure V 14 Figure V 15 Figure V 16 Figure V 17 Figure V 18 Figure V 19 Figure V 20 Figure V 21 Table des figures D finition du syst me exemple 161 ObCS de Pclient tape 1 164 ObCS de ServeurG etape 2 2 22588 Rating ne Sei Batis ke Rires ere A 165 ObCS d extension de Pclient et ServeurG tape 3 168 D finition de la classe Cclient ss 168 ObCS d extension de Cclienti ss 169 Marquage initial du syst me exemple cecceesceesceeeceseceteceseceeeeaeensecseeeeeeneeees 170 acc s it ratif aux attributs publics 172 Implantation des acc s aux attributs dans le WSCS 173 WSCS du syst me exemple ss 174 Instanciation et invocation d une classe composite ce ceceeeseesseseeeteeeeeeeeeeeeeees 177 R seau de traduction pour l instanciation d une classe composite R seau de traduction pour l invocation d une instance composite D finition du syst me version 1 180 D finition du syst me version 2 181 WSCS de la table de philosophes 182 R seau simplifi de la table de philosophes 184 Chapitre VI Extension du formalisme Figure VI 1 Figure VI 2 Figure VI 3 Figure VI 4 Figure VI 5 Figure VI 6 Figure VI 7 Figure V1 8 Figure VI 9 Figure VI 10 Figure VI 11 Syntaxe graph
95. G n ration de code Ada partir d une approche Orient e Objets HOOD R seaux de Petri Proceedings of 314 International Workshop on Software Engineering and its Applications EC2 Toulouse France December 1990 PARNAS D L On the use of transition diagrams in the design of a user interface for an interactive computer system in Proc of 24th National ACM conference San Francisco Calif 1969 pp 379 385 PARNAS D L A technique for the specification of software modules with examples Communications of the ACM vol 15 N 5 pp 330 336 Mai 1973 PASQUIER A ESTEVE P ROUBINE O QUEINNEC C DELACOUR V FLTR3 Extensions a objets pour un langage temps r el fortement typ in GL17 89 pp 58 67 PETERSON J L Petri net theory and the modeling of systems Prentice hall 1981 Isbn 0 13 661983 5 PETRI C Kommunication mit automaten PhD Dissertation University of Bonn 1962 PITETTE G Programmation orient e objet avec Ada Possibilit s Difficult s Exp rience d Enseignement in BI GL 49 pp 92 102 PNUELI A Applications of Temporal Logic to the Specification and Verification of Reactive Systems A Survey of Current Trends LNCS N 224 pp 510 584 Springer Verlag 1986 POMELLO L Some equivalence notions for concurrent systems an Overview G Rozenberg edit Advances in Petri Nets 86 LNCS 222 1986 RAMCHANDANI C Analysis of asynchronous concurrent systems by timed Petri net models PhD the
96. INTEGER gt END_OP1 Cr CFD Figure V 3 La classe ServeurG Class Implementation Serveurs inherit ServeurG Services OP2 lt p INTEGER gt lt r Create lt c INTEGER gt is do Ready lt c gt end Create ObCS PS1 PS2 lt p INTEG SReady lt c INTEGE lt p gt END_OP2 END_OP1 Cp C c p Figure V 4 La classe ServeurS Une instance de Pclient cr e de mani re al atoire des instances de serveurG par occurrence de la transition T1 ou des instances de Serveurs par occurrence de la transition 72 Les instances de Serveurs re oivent par occurrence de la transition T3 une requ te sur leur service OP2 et le r sultat 146 V 2 Pr sentation de l exemple renvoy est stock dans la place P3 Chaque objet cr par T1 ou T2 re oit une requ te sur son service OP par occurrence de la transition T4 Les classes propos es en exemple permettent donc d illustrer les points suivants e Cr ation dynamique de nouvelles instances par occurrence de T1 ou T2 e Relation d utilisation dynamique entre instances une instance de PClient peut utiliser plusieurs instances diff rentes de ServeurG et Serveurs e Requ te de service non polymorphique par construction une occurrence de la transition T3 ne peut concerner que des instances de ServeurS e Requ te de service polymorphique une occurrence de
97. IV Syst mes d Objets Coop ratifs et organisation des classes Figure IV 1 Syntaxe de d finition d un syst me d Objets Coop ratifs 137 Figure IV 2 Univers Syst me d Objets et Environnement ccceseeseesecseeenseeseeeeeesseeeeeees 140 Figure IV 3 Sp cification de la classe Composite Exemple 148 Figure IV 4 D finition textuelle de l impl mentation de la classe Composite Exemple 149 Figure IV 5 D finition graphique de l impl mentation de la classe Composite Exemple 150 Figure IV 6 Configuration d une table de philosophes cceeeeeseseecseeseeeeceeteeceeeeeeeaeentenes 151 Figure IV 7 Impl mentation de la classe Philosophe 153 Figure IV 8 Sp cification de la classe Table 155 Figure IV 9 D finition textuelle de l impl mentation de la Table 155 Figure IV 10 D finition graphique de l impl mentation de la Table ote eeceeeeeeeseeneeeeene 156 Chapitre V S mantique formelle d un syst me d Objets Coop ratifs Figure V 1 G n ration d identificateurs oe eee eeeeeecneeeeceseeeeesecseeseceveessecseveeceaeeeeeaeeateaes 158 Figure V 2 Laclasse Pclient ci a sieaghoniicca ciency hel ante ocean 159 Figure V 3 sa Classe ServeurGs ne Me ne ee Rael et oie i Sette 160 Figure V 4 la class Serveurs transe Min don lei ni rie detre 160 258 Figure V 5 Figure V 6 Figure V 7 Figure V 8 Figure V 9 Figure V 10 Figure V 11 Figure V 12
98. L 14 Influence du tri sur la franchissabilit Dans l exemple de la Figure II 14 si la place PA n est pas tri e ou est faiblement tri e la transition T1 est franchissable avec les substitutions x 3 et x 4 par contre si la place est fortement tri e Hard Ascending x la transition n est pas franchissable car la substitution qui minimise le crit re de tri x2 ne v rifie pas la pr condition 62 II 2 Extension des RPO Dans la Figure II 15 la transition T1 est franchissable avec les substitutions x 3 et x 4 si aucune place n est tri e elle est franchissable uniquement avec la substitution x 3 si la place PA est d clar e Soft Ascending si la place est d clar e Hard Ascending la transition n est pas franchissable car le jeton lt 2 gt qui minimise le crit re de tri n est pas pr sent dans la place PB PA lt x INTEGER gt MAT Ascending x Soft PB PC lt x INTEGER gt Figure IL 15 Tri et unification D finition II 37 Places tri es et franchissabilit Soit R M un RPO muni d un marquage M m Val Soit t e T une transition de R et S une substitution des variables de t On dit que t est franchissable par S a partir de M ce qui est not MS si et seulement S1 1 Vpe P S Pr p t lt m p 2 si Pr viny vin est la pr condition de t alors la proposition Pr Val S vin Wal S vin est vraie 3 Vpe P telle que Pr p t 0 et Trip est un crit re
99. N d ordre 1093 THESE pr sent e en vue de l obtention du grade de Docteur de l UNIVERSITE PAUL SABATIER de Toulouse Sp cialit INFORMATIQUE par R mi BASTIDE OBJETS COOPERATIFS UN FORMALISME POUR LA MODELISATION DES SYSTEMES CONCURRENTS Soutenue le 6 F vrier 1992 devant la commission d examen compos e de MM C GIRAULT Pr sident P COINTE Rapporteur P SALLE Rapporteur R VALETTE Rapporteur M F BARTHET L FERAUD J C POUYTES C SIBERTIN BLANC Laboratoire d accueil LIS Universit Toulouse I Place Anatole France 31042 Toulouse Cedex R sum Cette th se propose un nouveau formalisme appel Objets Coop ratifs d di la mod lisation des syst mes concurrents qu il s agisse d ateliers flexibles de fabrication de logiciel temps r el de syst mes d information ou de toute autre syst me v nements discrets dans lequel la concurrence joue un r le important Deux objectifs ont guid la d finition de ce formalisme La recherche d un grand pouvoir d expression permettant de construire des mod les clairs et concis et la pr servation du caract re formel permettant l ex cution et l analyse des mod les Le travail pr sent se trouve au confluent de deux axes de recherche importants d une part les travaux portant sur l expression de la concurrence au sein de l approche Objet et d autre part les travaux relatifs aux R seaux de Petri de Haut Niveau et aux techni
100. PO Rappelons tout d abord la d finition originale D finition IL 31 Arcs inhibiteurs Hack 75 Un RdP arcs inhibiteurs est un RdP R lt P T Pr Post gt dont on modifie seulement la d finition de Pr Pr PX TO NU O Dans un RdP arcs inhibiteurs une transition t T est franchissable pour un marquage M si Vpe P Pr p t lt M p si Pr p t e N M p 0 si Pr p t Les l ments tels que Pr p t sont repr sent s graphiquement par un arc o un petit rond remplace la fl che La Figure II 9 illustre cette repr sentation la transition T2 ne peut tre franchie que si la place P1 ne contient pas de jeton La l gende montre la repr sentation intuitive que l on peut 57 II 2 Extension des RPO avoir en logique propositionnelle d une telle construction dans ce cas la proposition Px est vraie si M Px gt 0 T1 si P2 T2 si P2 et P1 Figure II 9 Arc inhibiteur Nous proposons une autre d finition des arcs inhibiteurs D finition IL 32 Arcs inhibiteurs Un RdP arcs inhibiteurs R lt P T Pr Post Inhib gt est d fini par l adjonction un RdP lt P T Pr Post gt d une fonction Inhib Inhib P XT gt N LU compl tion de N par un plus grand l ment Dans un RdP arcs inhibiteurs une transition t T est franchissable pour un marquage M si et seulement si 1 VpeP Pr p t lt M p 2 VpeP Inhib p t gt M p La d finiti
101. Petri Nets Bonn June 89 STEFIK M BOBROW D G Object Oriented programming themes and variations AI Magazine Vol 6 N 4 1986 pp 40 62 STROUSTRUP B What is Object Oriented Programming in ECOOP 87 pp 57 78 TARDIEU H ROCHFELD A COLETTI R La m thode Merise Edition des Organisations Paris 1983 TAUBNER D On the implementation of Petri Nets Proceedings of 8th European workshop on application and theory of P N ZARAGOZA 1987 TECHLOG S A SEDRIC Pr sentation g n rale et SEDRIC Manuel de r f rence TECHLOG Toulouse 1989 TECHNOLOGY OF OBJECT ORIENTED LANGUAGES AND SYSTEMS Proceedings of the Second International Conference TOOLS Bezivin Meyer Nerson Eds Angkor Paris 1990 TRIPATHI A BERGE E AKSIT M An Implementation of the Object oriented Concurrent Programming Language SINA Software Practice and Experience Vol 19 N 13 pp 235 256 March 1989 ISBN 0038 0644 Technique et Science Informatique Sp cial R seaux de Petri Vol 4 n 1 Janvier 1985 R VALETTE Analysis of Petri Nets by Stepwise Refinements Journal of computer and system science 18 3 1979 VALETTER Nets in Production Systems in LNCS 87 pp 191 217 VALETTE R THOMAS V BACHMANN S SEDRIC un simulateur v nements discrets bas sur les r seaux de Petri RAIRO APII Vol 19 n 5 pp 423 436 VALETTE R PALUDETTO M Approche Orientee Objet HOOD et r seaux de Petri pour la conception de
102. RPO pour d finir la pragmatique des objets d une classe a des cons quences importantes quant la typologie des objets que l on peut d crire et va nous permettre d exprimer des comportements et des constructions qui d passent le cadre des langages objets traditionnels e L utilisation principale des RdP est la mod lisation de syst mes qui voluent de mani re discr te mais pas forc ment s quentielle dans un syst me mod lis par objets l volution est provoqu e par l invocation par des objets de services qu offrent d autres objets Ces invocations cr ent alors des flots de contr le entre objets Un syst me d objets n est pas s quentiel si plusieurs flots de contr le peuvent voluer concurremment soit l int rieur d un objet soit entre plusieurs objets En utilisant les RdP pour d crire la structure de contr le des objets on dispose de toute leur expressivit pour la sp cification de flots de contr le concurrents e Si on consid re que les transitions de l ObCS de sp cification peuvent tre franchies concurremment chacun des flots de contr le qui traverse un objet peut voluer en parall le avec les autres On peut donc ais ment mod liser une concurrence interne l objet Il faut remarquer que d apr s la r gle de franchissement d crite plus haut III 4 5 b les flots de 116 11 6 Pouvoir d expression du formalisme contr le internes un objet n voluent pas simultan ment les transiti
103. Trip V lt Trip yj et on y ins re les deux doublets lt x V gt et lt V yj gt Apr s quelques insertions le marquage de la place P1 est de la forme MIN y17 lt Xj Yi Xp MAX gt avec Vi 1 n 1 Tripi lt Tripy et yj xi Lorsqu on d sire extraire de la place le jeton V qui parmi les jetons ins r s qui maximisent resp minimisent la fonction Trip il faut choisir deux doublets de la forme lt x V gt lt V MAX resp lt MIN V gt lt V x gt et y remettre le doublet lt x MAX gt resp lt MIN x gt La Figure IT 20 illustre done un tri d croissant on choisit la valeur qui maximise Trip Comme pr c demment nous illustrons le fonctionnement du motif par un exemple On donnera ici Trip x cos x et on a donc MIN 1 MAX 0 Le tableau ci dessous montre l volution du motif pour l introduction successive de 7 2 0 et 37 4 Marquage atteint Pl y y ae lt n n 2 gt lt n 2 0 gt lt n 1 2 gt lt n 2 0 gt lt 0 0 gt Entrer lt 3x 4 gt lt n 31 4 gt lt 37x 4 n 2 gt lt n 2 0 gt lt 0 0 gt 68 II 2 Extension des RPO lt n 31 4 gt lt 31 4 n 2 gt lt n 2 0 gt lt n 30 47 lt 37 4 0 gt Figure IL 21 Evolution des marquages pour le motif Place tri e Nous avons d crit le cas o on trie des jetons d arit 1 En toute g n ralit si on d sire trier par ce motif des jetons d arit n dans une place celle ci sera d arit 2n
104. VII Modes d invocation des services 1 2 Invocation gard e Les m canismes de temporisation des RPO d crits en II 2 8 sont utilisables lors de la d finition des ObCS On peut alors d crire pour un objet non seulement les s quences l gales d invocation de services et les contraintes sur leurs synchronisations mais aussi les aspects li s leurs dates ou dur es d ex cution Dans la suite nous utiliserons uniquement la notation des RPO arcs temporels aussi bien pour d crire cette extension que dans l tude de cas du VII 1 Lorsque l on introduit des temporisations dans la description de l ObCS d un serveur il devient significatif pour un client de se pr occuper du d lai de prise en compte d une invocation Un client peut notamment refuser d attendre longtemps qu un serveur soit pr t r pondre son invocation Il peut alors associer une garde un certain nombre d unit s de temps l invocation exprimant ainsi qu il accepte d attendre cette dur e avant que sa requ te soit prise en compte par le serveur Ce m canisme est comparable l attente gard e du langage Ada La s mantique intuitive d une invocation gard e est la suivante e Les jetons sont retir s des places d entr es de la TI et les param tres correspondants sont plac s dans la place d attente Deux choses peuvent alors se produire La transition d accord devient franchissable chez le serveur avant l expiration du d lai de garde Dans ce cas
105. a classe dans laquelle cette expression est d finie Le syst me de types propos par le langage distingue les types simples des types classe 2 1 Types simples Le domaine de valeurs d un type simple est un ensemble de constantes et une variable de type simple aura donc pour valeur une constante Les types simples sont soit des types pr d finis soit des types construits Les types pr d finis sont les suivants e INTEGER qui d note les valeurs enti res sign es e REAL qui d note des valeurs sign es virgule flottante BOOLEAN qui d note des valeurs bool ennes parmi les constantes TRUE et FALSE e CHAR qui d note des valeurs de type caract re e STRING qui d note des cha nes de caract res Les op rations que l on rencontre usuellement dans les langages de programmation pour ces types pr d finis affectation comparaison traitements num riques sont galement pr d finies dans le langage En ce qui concerne le type STRING les op rations classiques sur les cha nes seront donn es en utilisant la notation point e variable op ration liste de param tres et en utilisant les op rateurs de manipulation de cha ne fournis par le langage Eiffel Il faut toutefois remarquer que notre type STRING n est pas identique la classe STRING du langage Eiffel Meyer 90b en effet des l ments de ce type seront toujours manipul s par valeur Les types construits sont soit les types d finis par inter
106. a dur e minimale avant que la transition ne puisse tre franchie et tax permet de calculer la date avant laquelle la transition arm e doit effectivement tre franchie La date r elle de franchissement peut tre n importe quel point de l intervalle e Les RdP transitions temporis es Ramchandani 74 associent chaque transition t du r seau une dur e de tir r Ce mod le identifie une transition une activit dont r est la dur e 69 II 2 Extension des RPO Les RdP places temporis es Sifakis 79 constituent l approche duale de la pr c dente o une dur e r est associ e a chaque place Un jeton d pos dans la place p a la date u ne sera disponible pour le franchissement d une transition qu apr s la date u r Les RdP arcs temporis s Alla 87 associent le coefficient Gi chaque arc de Post p t permettant de sp cifier que le temps de s jour dans la place p d pend de la transition qui a d pos le jeton Les RdP arcs temporels Bastide 89 Bako 90 associent comme les RdP arcs temporis s le temps aux arcs du r seau mais avec une s mantique diff rente Dans ce mod le un intervalle de temps aij bij est associ chaque arc de Pr p t signifiant ainsi qu un jeton d pos dans la place p la date U ne pourra tre utilis que pour un franchissement de la transition t se produisant dans l intervalle u a u b Bako 90 d finit la temporisation au ni
107. a pour but de d crire formellement au sein de la th orie des RPO la r gle d volution des ObCS Ceci est r alis en montrant comment on peut rassembler les ObCS des classes qui composent un syst me en un seul r seau qui d crit la structure de contr le du syst me global Ce r seau sera appel WSCS acronyme pour l anglais Whole System Control Structure Ce m canisme de construction d crit galement comment le marquage initial du WSCS est d fini partir de l tat des objets primitifs du syst me Le WSCS que l on g n re est en fait un r seau Pr dicats Transitions Genrich 87 c est dire que tous les jetons qui circulent sont des constantes et non plus des r f rences d objet Toute la structuration qui r sulte de l approche objet est en quelque sorte remise plat par le processus de construction du WSCS Le WSCS d finit formellement la s mantique des Objets Coop ratifs dans le sens suivant Le comportement d un syst me d Objets Coop ratifs est exactement le comportement du WSCS de ce syst me Nous aurions pu tout aussi bien d finir le formalisme des Objets Coop ratifs en partant de la notion de WSCS qui n est rien d autre qu un r seau Pr dicat Transitions v rifiant un certain nombre de contraintes structurelles telles qu elle permettent de reconna tre les objets du syst me et leurs classes Nous avons pr f r cette d marche de s manticien une d marche orient e mod lisateur 143 V
108. accepte les services Ecrire Lire position et Aller_en un nombre quelconque de fois dans n importe quel ordre et en exclusion mutuelle L acceptation du service Fermer le replacera dans l tat Ferm Le paragraphe ci dessus peut tre consid r comme une description informelle du comportement d une instance de Fichier qui n chappe pas tous les probl mes qui d coulent de l utilisation du langage naturel On voit imm diatement l int r t de disposer d un formalisme qui permette d exprimer le m me comportement d une mani re concise formelle et non ambigu 8 Parnas 73 a montr combien il est dangereux d accorder trop d importance la s mantique des noms d op rations m me lorsqu on manipule des types bien connus Une bonne pratique consiste donc documenter le service par un commentaire qui a pour but de pr ciser la s mantique du service en essayant de trouver un juste quilibre entre le laconisme et le verbiage On doit notamment viter d introduire des indications s mantiques redondantes ou pire encore contradictoires avec l information qui est port e par l ObCS 95 IIT 3 Sp cification d une classe Class Specification Fichier Services Ouvrir Ouvre le fichier Fermer Ferme le fichier Aller_en lt position INTEGER gt Met position l indice du caract re courant Lire lt combien integer gt lt chaine STRING gt Renvoie une cha ne d au plus combie
109. ait par les UIMS disponibles et sa conception n est plus la charge du programmeur d applications e Le Dialogue traite des aspects syntaxiques de l interaction Ce composant structure la coop ration personne logiciel un haut niveau et assure la distribution du contr le entre l utilisateur et le syst me Il sert d interm diaire entre l Abstraction et la Pr sentation C est pour la conception de ce composant Dialogue que nous allons utiliser le formalisme des Objets Coop ratifs Il faut bien veiller consid rer le mod le Seeheim comme un mod le conceptuel et non pas comme un mod le d architecture des interfaces Les tentatives de structurer une interface suivant ce mod le se sont en effet heurt es des probl mes caract ristiques des architectures en couches les trois parties se r v laient avoir une architecture isomorphe cr ant ainsi des probl mes de couplage et de maintenabilit il tait le plus souvent impossible de faire voluer une partie ind pendamment des autres Dans une approche Orient e Objet il est plus judicieux de consid rer chaque objet comme un micro Seeheim lui tout seul et c est pr cis ment l approche promue dans le mod le PAC Coutaz 87 Il est remarquable de constater que les diff rents environnements disponibles bien qu offrant une interface de programmation tr s diff rente en terme de structures de donn es manipul es de fonctions disponibles pr sentent toutefo
110. al avec la place param tre est tiquet avec les variables d entr e de la transition qui servent de param tres r els d entr e du service 4 Une Place r sultat est introduite en entr e de chaque transition de completion Cette place est destin e recevoir les r sultats fournis par l appel du service Cette place a pour type la signature de sortie du service L arc qui connecte cette place avec la transition de compl tion est tiquet avec les variables de sortie de la transition qui re oivent les r sultats du service 5 Un l ment de type Identificateur est ajout aux types des places param tres r sultat et d attente Durant l activit du syst me le marquage d une place r sultat sera compos de tuples contenant les r sultats obtenus par invocation du service concat n s avec une estampille d appel c est dire un identifieur g n r par l occurrence de la transition d appel On ajoute aux tiquettes des arcs connect s ces places la variable id qui d notera l estampille d appel Les requ tes de cr ation d objet c est dire les transitions dont l action est de la forme variable Class create lt n uplet de param tres gt ne sont pas proprement parler des TI puisque elles ne s adressent pas un objet d j cr Elles sont toutefois tendues de la m me fa on lt lt x idp lt x id gt O lt id gensyn i gensym xid PO R 7 id place d attente lt i lt id gt X Y
111. alors d fini comme es DP op P Vind support Pr p t WU support Inhib p t D finition 11 34 Franchissabilit dans un RPO arcs inhibiteurs Dans un RPO arcs inhibiteurs une transition t T est franchissable a partir d un marquage M m Val si et seulement si il existe une substitution S S pour t s Vin U telle que 1 V p P S Pre p t lt m p 2 si Pr v Vp est la pr condition de t alors Pr Val S v Val S v V pe P S Inhib p t lt m p 3 Il faut remarquer que si la transition n a pas de pr condition ou plus pr cis ment si sd dr condition est identiquement vraie le point 2 de la d finition pr c dente se simplifie en VpeP S Inhib p t lt m p 3 On note lt et non pas gt car l ordre n tant pas total deux l ments peuvent tre non comparables 59 II 2 Extension des RPO Pour qu un arc inhibiteur n impose aucune contrainte au franchissement il doit tre de la forme Erreur o v n appara t pas sur les autres arcs v peut alors tre instanci par toute substitution Le cas d un arc inhibiteur sans pr condition est illustr en Figure I 11 en l absence de l arc inhibiteur la transition T2 est franchissable avec les substitutions a 3 a gt 4 et a gt 5 l arc inhibiteur r duit les possibilit s de franchissement la substitution a 5 lt a gt lt a gt T1 a si P2 a Tl T2 lt a lt a Figure IL
112. amique d crit les encha nements possibles d actions sur le composant et caract rise son volution au cours du temps Terme introduit dans la m thode TAXIS Barron 82 11 I 1 Les fondements de l approche Objet Les langages de programmation ou les m thodes de conception permettent divers titres d exprimer l interface et la pragmatique lors de la sp cification d un composant logiciel e L interface d un composant logiciel est en g n ral constitu e de services suivant les langages on parlera de proc dures et fonctions de m thodes de routines et d attributs c est dire de donn es dont la valeur est g r e par le composant Un service est un op rateur destin faire voluer l tat interne du composant ou obtenir une information sur cet tat L interface d finit pour chaque service son nom et sa signature c est dire le nom et le type des param tres accept s ainsi que leur mode de passage par variable ou par valeur et ventuellement le type de la valeur retourn e par le service si celui ci est fonctionnel Pour chaque attribut l interface du composant d finit son nom son type et ventuellement les droits d acc s que des composants ext rieurs ont sur cet attribut lecture criture ou lecture seulement Certains langages permettent enfin d inclure dans l interface d un composant des d finitions de type en g n ral parce que ces types sont pr sents dans la signature des s
113. ans le syst me au cours de son activit e C est un langage qui autorise le polymorphisme c est dire la possibilit pour un identifieur du langage d tre li un objet d une classe d riv e par h ritage de la sienne propre L h ritage introduit entre les classes une relation de compatibilit qui indique sous quelle condition une valeur d un certain type peut tre affect e une variable d un type diff rent Cette notion de compatibilit entre classes permet de rel cher de mani re contr l e l aspect fortement typ du langage Les sous chapitres HI 2 III 4 constituent en quelque sorte le manuel de r f rence du langage des Objets Coop ratifs d crivant a la fois ses aspects syntaxiques et s mantiques Les deux sous chapitres qui suivent la d finition du syst me de types en sont les plus importants ils d finissent comment une classe d Objets Coop ratifs est d crite suivant le point de vue externe sa sp cification III 3 et interne son impl mentation III 4 85 IIT 2 Le syst me de types 2 LE SYSTEME DE TYPES Le formalisme des objets coop ratifs fait partie de la familles des langages fortement typ s le type de chaque entit variable constante param tre du langage fait partie de sa d finition et l entit ne pourra tre li e qu des valeurs de ce type Le type d une expression quelconque du langage peut tre d termin de mani re statique au simple examen du texte de l
114. ant tre vide Il n existe pas de services proc duraux sans valeur de retour on consid re intuitivement qu un service renvoie au minimum un accus d ex cution informant le client que le traitement associ au service est termin Une liste de param tres vide en entr e ou en sortie est implicite et n est donc pas mentionn e dans la signature e Chaque param tre d entr e ou de sortie du service est d fini avec un nom et un type qui peut tre un type simple pr d fini un type export ou un type classe Le mode de passage des param tres d entr e d un service est toujours le passage par valeur et il n est donc pas n cessaire de le pr ciser Il faut bien entendu noter qu une variable de type classe est li e la r f rence d un objet si une telle variable est pass e en param tre sa valeur le nom de l objet qu elle d note ne changera pas mais l objet d not pourra lui m me tre invoqu et une invocation peut donc provoquer un effet de bord sur l objet d not par un param tre de type classe L interface publie galement la sp cification de l op ration create qui permet de cr er dynamiquement de nouvelles instances Cette op ration fait l objet d un paragraphe sp cial ci apr s en III 3 3 La classe exporte enfin un ensemble d attributs d fini comme les param tres d un service par un nom et un type Ces attributs sont accessibles en lecture seulement l ext rieur de la classe e Un
115. ant pr et post conditions peuvent ne plus tre v rifi s Il faut donc emp cher l interruption d un service en cours d ex cution car son contrat ne serait plus garanti Meyer propose de faire cohabiter les interpr tations s quentielle et concurrente du contrat au sein d un m me syst me en introduisant une notation particuli re de d claration des variables x separate A 22 1 2 Mod les d objets concurrents Cette notation d finit que tout objet d not par x pendant l ex cution est susceptible d tre ex cut par un autre processeur r el ou virtuel que l objet o cette d claration apparait Lorsqu on invoquera l objet x le client continuera s ex cuter en parall le avec l ex cution de sa requ te Toutes les pr conditions des services appliqu s x doivent alors tre interpr t es comme des conditions d attente Cette proposition nous para t poser probl me pour la raison suivante e Le fait qu une pr condition doive tre interpr t e comme une condition d attente n est pas li au fait que l objet serveur soit actif ou separate dans la terminologie de Meyer mais au fait qu un objet soit partag entre deux ou plusieurs objets actifs en voici un contre exemple Class Enfileur export INTEGER prends_une_file File feature separate Enfileur prends_une_file f File is Create do Create f enfiler 3 prends_une_file f end f d filer Fig
116. ant des possibilit s de validation formelle des mod les produits Les r seaux Place Transition classiques rendent ais e l expression des constructions relevant de la concurrence et offrent de grandes possibilit s d analyse et de validation statiques ou dynamiques ils souffrent toutefois de la faiblesse de leur pouvoir d expression et de leur absence de prise en compte de l interaction troite entre donn es et contr le au sein d un syst me Des mod les de R seaux de Petri de Haut Niveau RdPHN tels que les r seaux Pr dicat Transition ont t d finis afin de r soudre certains de ces probl mes et sont aujourd hui largement utilis s Ces formalismes sont d volus la mod lisation de syst mes concurrents dont on sait qu ils atteignent rapidement une complexit tr s grande Aussi les possibilit s de structuration sont elles primordiales Introduction afin de permettre au concepteur de manipuler des mod les qui n exc dent pas ses capacit s de compr hension et qui permettent la vision d un mod le diff rents niveaux d abstraction Les techniques de d composition fonctionnelle hi rarchique ont t les premi res appliqu es aux RdPHN et favorisent une approche descendante Elles apportent les m mes avantages et souffrent des m mes carences que lorsqu elles sont appliqu es la conception de logiciel Des techniques de composition de r seaux favorisant une approche ascendante ont galement t pr
117. ant l expiration d un certain d lai Ce mode peut s appliquer indiff remment aux HSER ou LSER HOOD ne sp cifie pas de contrainte quant aux param tres et valeurs de retour des op rations intuitivement il semble toutefois vident qu une invocation de type LSER ou ASER ne peut pas renvoyer de r sultat 3 2 La relation d utilisation La relation d utilisation permet de d finir le flot de contr le entre les objets du syst me Un objet A utilise un objet B si l interface de A mentionne que celui ci requiert une op ration fournie par B HOOD d finit un certain nombre de contraintes que doit respecter le graphe de la relation d utilisation Les objets actifs peuvent s utiliser mutuellement sans contrainte le graphe de la relation d utilisation entre objets peut notamment comporter des cycles et le terme de hi rarchie d utilisation est donc abusif en ce qui concerne les objets actifs Les objets actifs peuvent galement utiliser des objets passifs Les objets passifs ne peuvent utiliser que d autres objets passifs et le graphe de la relation d utilisation entre objets passifs ne doit pas contenir de cycles Les principes de forte coh sion et de faible couplage Parnas 73 sont v rifiables l examen du graphe de la relation d utilisation un objet doit utiliser aussi peu d objets que possible et tre utilis par le plus d objets possible 33 1 3 La m thode HOOD HOOD n interdit pas plusieurs objets act
118. appliqu quelques classes d objet afin d obtenir un mod le de fonctionnement d une partie du syst me e Si on supprime d un ObCS ses arcs d activation et de compl tion l objet n est plus un serveur et le WSCS qui en r sulte mod lise un sous syst me e Si au contraire on consid re uniquement l ObCS de sp cification l objet n est plus un client et le WSCS qui en r sulte est un mod le abstrait du syst me Ces deux techniques peuvent tre utilis es simultan ment afin d obtenir des mod les abstraits de sous syst mes 6 ANALYSE DES COMMUNICATIONS STATIQUES Une transition d invocation d crit une communication statique si toutes ses occurrences concernent le m me serveur C est le cas par exemple si le serveur est d sign par une r f rence qui n est jamais modifi e Quand toutes les communications d un syst me sont statiques le proc d de construction du WSCS peut tre simplifi puisqu il n est plus n cessaire de replier les ObCS des instances afin de produire les ObCS d extension ni de fusionner les places param tre et r sultat le long de la hi rarchie d h ritage Dans le cas d un syst me communications statiques il est de plus possible de v rifier si les clients utilisent leurs serveurs correctement i e en accord avec leur mode d emploi afin que ni les clients ni les serveurs n atteignent un tat de blocage Consid rons un objet client OC avec un ensemble Tiny de transitions d invoc
119. ar un RdP le m dium de communication entre les objets cf SIIL 4 Dans notre cas le m dium est uniquement compos de places mais les r sultats de Souissi 89 ne sont pas applicables car nos objets ont une communication de type question r ponse et donc bi directionnelle 3 3 Structuration Orient e Objet La m thode HOOD PNO L int gration des approches Objet et R seaux de Petri est un domaine ou la recherche est tr s active et certains formalismes on d ja t propos e par exemple Bruno 86 Nous pr sentons ici la m thode HOOD PNO Paludetto 91 dont les concepts sont les plus proches de ceux de notre propre formalisme La m thode HOOD PNO est une m thode de d veloppement de logiciel dont le domaine d application principal est le d veloppement de logiciel de commande en temps r el de proc d s industriels Elle propose un cycle de vie complet allant de l analyse jusqu la production de code en passant par la conception architecturale et d taill e Il s agit d une m thode toute Objet o toutes les phase du cycle de vie justifient du m me formalisme permettant ainsi une transition facile entre tapes et une trace ais e des entit s au cours du d veloppement En termes de conception architecturale la m thode HOOD PNO s appuie sur les concepts de la m thode HOOD cf 1 3 l id e directrice tant d utiliser les RdP pour la description formelle des ObCS et des OpCS 76 II 3 Structurati
120. aract res de listing l int rieur du rectangle La Figure III 4 montre un ObCS correspondant a la d finition de l interface de la Figure III 3 La fonction de disponibilit ajout e en l gende est d crite graphiquement par les arcs d activation et de compl tion et par la suite nous ne donnerons plus de d finition textuelle des fonctions de disponibilit 3 3 Instanciation et rapport Classe Instance La sp cification de chaque classe contient la d finition d une op ration de cr ation not e Create qui d termine de quelle mani re sont cr es les instances de cette classe Cette op ration n est pas un service elle ne peut pas tre appliqu e une instance d j cr e mais est not e comme une fonction qui prend une liste de param tres d entr e et a pour valeur de retour une liste un seul l ment dont le type est la classe consid r e et qui d note le nom de l objet nouvellement cr Un appel l op ration Create de la classe Cy sera not Vp Cp Create lt liste de param tres gt 93 IIT 3 Sp cification d une classe o Vp est une variable de la classeCp ou d une classe anc tre dans la hi rarchie d h ritage cf IV 2 Dans un LOO classique une classe d finit la structure de donn es de ses instances par un ensemble d attributs Toutes les instances ont donc la m me structure mais diff rent par les valeurs de ces attributs Les Objets Coop ratif respectent cet
121. aram tre en entr e qui d signe la nouvelle valeur de l attribut et a pour valeur de retour son ancienne valeur Il ne peut tre ex cut que si l attribut a t initialis soit par l op ration Create soit par un service d initialisation 100 IIT 3 Sp cification d une classe Ce lt ancien gt lt valeur gt lt valeur gt CHANG Eattribut lt Wleur gt lt ancien gt SETattribut Figure IIL S8 Services d initialisation et de mise a jour La structure de contr le et la s mantique de ces services de manipulation d attributs est illustr e en Figure III 8 Une classe ne publie pas forc ment les services SET et CHANGE sur chacun de ses attributs publics Pour qu un tel service soit disponible il faut qu il soit d clar dans l interface de la classe Le concepteur peut alors se dispenser de faire figurer les transitions associ es ce service dans l ObCS la place attribut tant invisible dans l ObCS la transition associ e un service d initialisation ou de mise jour semblerait non connexe au reste du r seau 3 6 D finition formelle D finition IIL1 Sp cification d une classe d Objets Coop ratifs La sp cification d une classe d Objets Coop ratifs est un sept uplet Spec lt R Att Ty Co Sv Sig Disp Mo gt o e R lt C T V P Pr Post gt est un RPO d fini comme au chapitre II R est muni d un ensemble de registres cf SIL 2 2 Att Onnote U Dom t l
122. ard de prise en compte du temps et ventuellement fournir les abr viations n cessaires Dans la troisi me partie de ce m moire nous pr sentons une tude de cas portant sur la mod lisation d un atelier de production Cette tude traite des aspects temporels du fonctionnement de l atelier et nous avons adopt pour la traiter la notation des arcs temporels illustr e en Figure 11 24 72 3 STRUCTURATION DES MODELES DE RESEAUX DE PETRI DE HAUT NIVEAU La difficult principale que l on rencontre lors de la mod lisation d un syst me par RdP de haut niveau est que l on se trouve souvent confront des r seaux trop grands pour tre ais ment compr hensibles La complexit de tels r seaux les rend difficiles analyser modifier et r utiliser Le probl me n est pas diff rent de celui de l explosion de la taille du logiciel et comme dans ce domaine deux approches peuvent tre suivies pour pallier ces probl mes e La premi re est la d composition hi rarchique Dans le domaine des RdP cette approche consiste substituer une partie d un r seau une autre partie plus d taill e mais qui est consid r e comme quivalente la partie initiale par une notion d quivalence qui doit tre pr cis e Cette quivalence peut tre d ordre essentiellement graphique Reisig 86 ou bien concerner explicitement le comportement du r seau Si le comportement est pris en compte la partie substitu e peut tre une
123. asse est alors consid r e davantage comme un Type Abstrait de Donn es et I h ritage formalise la notion de sous type Dans la suite nous adopterons le vocabulaire suivant si B h rite de A on dira que B est une classe d riv e ou descendante de A et que A est un anc tre de B a Heritage simple Les notions d extension et de sp cialisation sont souvent confondues dans les langages de programmation Orient s Objet et ne sont d ailleurs pas totalement ind pendantes Toutefois certains auteurs America 87 proposent de trancher plus nettement entre l h ritage consid r comme un concept li l impl mentation et le sous typage qui construit une hi rarchie conceptuelle de classes proposant une interface de messages compatible America d finit pour une classe une interface d utilisation et une interface d h ritage cette derni re constituant un ensemble coh rent d attributs et de services Dans le m me esprit Horn 87 introduit la notion de conformit conformance entre classes plus large que l h ritage o deux 14 I 1 Les fondements de l approche Objet classes peuvent tre conformes l une l autre sans tre explicitement reli es dans le graphe d h ritage c est dire sans forc ment partager le m me ensemble d attributs La vision conceptuelle de l h ritage qui identifie classe et type et sa vision pratique qui identifie classe et module peuvent parfois entrer en conflit par exemple Halbe
124. at de l objet cette modification est pr cis ment d finie par l volution du marquage qui r sulte du franchissement d une des transitions associ es au service d Acc s aux attributs publics Une classe d finit pour ses instances un ensemble d attributs ou variables d instance certains publics introduits d s la sp cification d autre priv s introduits en impl mentation que nous d crivons ci apr s Les attributs servent de registres l ObCS de la classe o ils sont d finis Ils peuvent donc tre utilis s dans n importe quelle transition de celui ci Les registres ont t d finis en 1 2 2 comme des extensions des RPO un registre repr sentant en fait une place cach e du r seau La question de l initialisation de ces registres et de l acc s leur valeur en lecture ou en criture par d autres objets se pose donc Les Objets Coop ratifs ne d finissent pas au contraire d Eiffel de politique d initialisation par d faut des attributs valeur NIL pour les r f rences 0 pour les entiers et les r els etc Nous n avons pas non plus retenu la solution de certains langages tels que Pascal pour lesquels une variable non initialis e a une valeur ind finie La solution retenue qui est conforme l identification que l on donne entre registre et jeton typ dans une place est notre connaissance unique un attribut non initialis est inaccessible et tout service ou op ration faisant acc s ce
125. ation d crivant des communications statiques avec un serveur OS Soient NC et NS les ObCS de OC et OS respectivement tendus comme d fini aux tapes 2 et 3 du proc d de construction du WSCS afin de permettre les communications et soient TC et TS l ensemble des transitions de N et NS Si Tac TS est l ensemble des transitions d accord de NS il est possible de d finir une fonction Lk Tiny gt Tac ou Lk tiny est la transition de Tac qui accepte le service invoqu par treq D finition IX 7 Compatibilit entre client et serveur On dira que NS est compatible avec NC ssi le langage des services demand s NS par NC est inclus dans le langage des services accept par NS i e L NS MS Tac 2 Lk L NS M9 Tiny 231 IX 2 V rification de l ObCS d un serveur Sous cette condition OS ne pose aucun probl me pour OC NC le m me comportement que les transitions de Tiny Soient consid r es comme des transitions ordinaires ou que les communications aient effectivement lieu Sibertin 91b Plus pr cis ment si N est le r seau r sultant de la fusion des places param tre et r sultat de NC et NS suivant Lk et si M est le marquage de N d duit de MC et MS ona L N M TS L NS M Ce r sultat peut tre utilis incr mentalement si un client utilise plusieurs serveurs il est compatible avec l ensemble des serveurs s il est compatible avec chacun individuellement et si un serveur est lui m m
126. ation sont d finis e Le formalisme autorise l instanciation dynamique de nouveaux objets pendant l activit du syst me e Les classes d objets sont structur es en une hi rarchie d h ritage qui permet d utiliser le principe du polymorphisme e On peut d finir des classes composites qui d crivent des sous syst mes d objets fortement coupl s et qui permettent de s abstraire de la complexit locale d un groupe d objet en relation troite e Les objets d un syst me communiquent par invocation et le formalisme permet la liaison tardive qui impl mente le polymorphisme e Le formalisme permet une explicitation compl te et formelle de toutes les communications entre objets Il permet de plus de distinguer les flots de donn es des flots de contr le Il est ais d exprimer la concurrence au sein d un syst me aussi bien entre les objets qu au sein de chaque objet Plusieurs flots de contr le peuvent voluer concurremment au sein d un syst me et chaque objet peut tre travers par plusieurs flots de contr le la fois e Le formalisme autorise la prise en compte du temps aussi bien en d finissant des liens de causalit entre v nements qu en sp cifiant des dates et des dur es L environnement d un syst me peut tre mod lis de mani re uniforme aussi bien comme un client que comme un serveur du syst me mod lis Cette uniformit de description permet de d placer volont la front
127. atique Langages Orient s Objet IRCAM Janvier 1986 BIGRE GLOBULE N 49 Juin 1986 Actes des journ es ADA AFCET ENST Paris Juin 1986 BIGRE GLOBULE N 57 D cembre 1987 Actes des journ es ADA AFCET ENST Le parall lisme en ADA Paris D cembre 1987 BJORNER D DRUFFEL L Position Statement ICSE 12 Workshop on Industrial Experience using Formal Methods in ICSE 12 pp 264 266 BLAKE E COOK S On Including Part Hierarchies in Object Oriented Languages with an Implementation in Smalltalk in ECOOP 87 pp 45 56 BLESER T FOLEY J D Towards Specifying and Evaluating Human Factors of User Computer Interfaces Human Factors in Computer Systems Proceedings march 1982 BOBROW D G STEFIK M The LOOPS Manual Technical report KB VLSI 81 13 Xerox Palo Alto Research Center Palo Alto Cal 1981 BOOCH G Software Engineering with Ada Benjamin Cummings Publishing California 87 BORNING A H INGALLS D H H Multiple Inheritance in Smalltalk 80 Proc of the AAAI Conference Pittsburg August 1982 pp234 237 BRACHMAN RJ What IS A is and isn t An analysis of taxonomic links in semantic networks IEEE Computer vol 16 n 10 pp 67 73 Oct 1983 243 Brams 83 Brauer 86 Brinch Hansen 72 Brinch Hansen 73 Briot 87 Bruno 86 Buetler 89 Buhr 84 Cardelli 84 Cardelli 83 Caromel 90 CNRS 88 Cointe 86 Colom 86 Coutaz 87 Cowan 9
128. aussi r f rence R f rence Attribut de type classe La valeur d une r f rence est le nom d un objet de cette classe Rendez vous Mode d appel par d faut lors de l invocation Du c t client le flot de contr le qui a conduit l invocation est suspendu jusqu ce que le service ait t men son terme par le serveur Rendez vous gard Mode d appel o le client d finit une garde sp cificant son d lai maximum d attente de la prise en compte de son invocation par le serveur Serveur Objet qui re oit une invocation concernant l un des services publi s par sa classe Serveur pur Objet dont l ObCS d impl mentation ne contient pas de TI Par extension Classe de serveurs purs feuille du graphe de la relation d utilisation Service Op rateur publi par une classe permettant de faire voluer l tat d une instance ou d obtenir une information sur cet tat Un service est d fini par son nom et sa signature Service d initialisation Service permettant de fixer la valeur initiale d un attribut des instances d une classe Service d interface Service pouvant tre invoqu par l environnement d un syst me d Objets Coop ratifs Service de mise jour Service permettant de faire voluer la valeur d un attribut de l instance Signature d un service Liste du nom et du type des ses param tres d entr e et de ses valeurs de retour TA Transition d Acc s transition qui contient l acc s un attribut pub
129. ble peut tre aussi d fini sur N et dans ce cas les coefficients sont positifs ou nuls Dans les r seaux de Petri Objets les coefficients seront uniquement pris dans N et on notera N E l ensemble des multiensembles sur E coefficients dans N On peut munir Z E de deux lois de composition l addition not e et la multiplication par un entier not e et d une relation d ordre partiel not e lt Q D finition II 2 Addition de deux multiensembles L addition de deux multiensembles est d finie par x y Erreur Erreur d finie ainsi est commutative associative elle poss de un l ment neutre la fonction identiquement nulle not 0 o tous les coefficients du multiensemble sont nuls d finie par 0e E 7 e 0 D finition II 3 Multiplication d un multiensemble par un scalaire La multiplication d un multiensemble par un entier relatif est d finie par n x n Erreur Erreur lavec n x e Z d finie ainsi est commutative associative et poss de un l ment neutre savoir l l ment unit de On peut d finir Z E par r currence partir des deux lois et 1 xeE gt xe Z E 2 x y Z E gt x ye Z E 3 ne Zxe ZE gt n xe Z E D finition II 4 Ordre partiel sur les multiensembles La relation lt d ordre partiel entre deux multiensembles est d finie par VXx YE ZE XO y Vee E x e lt y e 39 IL 1 Les R seaux de Petri Objet D fin
130. calculer des d lais et des gardes en fonction de la valeur des jetons manipul s La valeur de d lai qui est une constante dans ces deux figures peut tout aussi bien tre calcul e en fonction de la valeur des jetons qui transitent en Figure 11 23 par exemple la transition StartTj pourrait contenir une action de la forme d lai f a b Une utilisation possible de ce m canisme serait dans le cadre de la mod lisation des ateliers flexibles d exprimer le fait qu une op ration sur un poste de travail est fonction la fois de la pi ce manipul e et de la machine qui effectue cette op ration La technique du registre temporel nous parait tr s souple et permet d envisager des applications complexes de mod lisation li e au temps on pourrait par exemple prendre des d cisions dans un r seau en fonction de la dur e moyenne d attente d un jeton dans les places ou du temps coul depuis son introduction dans le r seau Cette technique permet galement de mod liser tr s facilement des op rations p riodiques qui doivent tre ex cut es intervalle de temps r guliers ou des activit s dont la date de d but est fix e il suffit de munir la transition d une pr condition de la forme Now d but Du point de vue m thodologique chaque domaine d application du formalisme application temps r el mod lisation d un atelier en vue d valuation des performances syst mes d information devrait d finir une politique stand
131. cat transition o toute la structure de donn es et de contr le des objets est mise plat L volution du syst me est alors compl tement d finie par e La structure du WSCS Le code des op rations internes Le marquage initial du WSCS Si on voulait obtenir un degr de formalisation sup rieur il faudrait soit se dispenser totalement d op rations internes algorithmiques le lecteur pourra v rifier qu elles sont tr s peu utilis es dans ce m moire soit s astreindre les exprimer elles m me par un RdP L volution du syst me ne d pendrait alors plus que de la structure et du marquage du WSCS et de la s mantique des op rateurs pr d finis sur les types pr d finis On peut faire une analogie entre le WSCS d un syst me d Objets Coop ratifs et la liste en langage d assemblage qui r sulte de la compilation d un programme informatique en langage de haut niveau comme cette liste le WSCS est construit par un processus automatique et sa structure pr sente assez peu d int r t pour le concepteur qui ne s y reportera que S il constate que son mod le fonctionne de mani re pathologique afin d effectuer des op rations de d bogage de bas niveau Toutefois c est le WSCS tout comme la traduction en langage d assemblage d un programme de haut niveau qui d finit in fine la s mantique du mod le et qui assure son ex cutabilit 168 V 6 Prise en compte des classes composites 169 Chapi
132. cation qui d signe l action de demander l ex cution d un service l objet d not par l identificateur La syntaxe et la s mantique de l invocation sont d finies pr cis ment en VI 1 La diff rence fondamentale entre types simples et types classe doit tre soulign e une variable de type simple est li e une valeur de ce type et les op rations portant sur cette variable ont une s mantique de valeur Une variable de type classe au contraire est li e au nom d un objet de cette classe et les op rations portant sur cette variable ont une s mantique de r f rence l affectation entre deux variables de type classe par exemple provoque une homonymie dynamique sur l objet r f renc s Il faut noter galement que les types construits sur des types classes sont toujours des types simples et sont donc manipul s par valeur 3 SPECIFICATION D UNE CLASSE La sp cification d une classe d Objets Coop ratifs fournit aux clients de cette classe toute l information n cessaire son bon usage Nous nous appuyons pour la d finition d une sp cification et la signification que nous donnons ce terme sur la discussion du I 1 2 Conform ment cette discussion la sp cification d une classe va d finir son interface et sa pragmatique L interface est d crite par une syntaxe inspir e du langage Eiffel et la pragmatique de la classe est d crite en utilisant le formalisme des RPO 3 1 Interface d une classe Le formalism
133. classe qui d finit le comportement de ses instances est d crit par un RPO et par la fonction de disponibilit Pour que la s mantique de cet ObCS soit claire et non ambigu il faut que soient clairement d finies la franchissabilit de ses transitions et la r gle de tir adopter d clenchement concurrent ou exclusif des transitions La franchissabilit et la r gle de tir des transitions sont d finies ci dessous de mani re intuitive la franchissabilit des transitions de l ObCS de sp cification est pr cis e dans sa d finition formelle I1 1 2 La r gle de franchissement parall le quant elle sera pr cis e au V 4 a Franchissabilit des transitions Dans le cas d un ObCS de sp cification la franchissabilit des transitions de service est d finie diff remment de celle des transitions priv es e Une transition priv e est franchissable en fonction du marquage de l ObCS conform ment la d finition de la franchissabilit dans les RPO cf Definition IL 19 98 U1 3 Sp cification d une classe Une transition de service est franchissable si et seulement si elle est franchissable au sens des RPO et il existe une invocation en attente pour le service consid r Les param tres r els de cette invocation du service sont alors unifi s avec les variables d entr e de l arc d invocation de la transition A un instant donn il peut exister plusieurs invocations en attente pour le m me servic
134. clientl est celui illustr en Figure V 10 lt r id gt lt x r self gt Figure V 10 ObCS d extension de Cclient1 Etape 4 D finition des marquages initiaux A ce stade nous pouvons d finir pour chaque classe C le marquage initial m de son ObCS d extension en conformit avec l tat des objets primitifs du syst me Soit e O l ensemble des noms des objets primitifs dont la classe est C P l ensemble des places de l ObCS d extension de C e mo la distribution initiale de jetons pour o O e pourtoutpe P Q l ensemble des o O tels que m P 0 Le marquage initial m est alors d fini par Vpe P m p S lt mo p o gt 0 O P e La place en entr e sortie de la transition d instanciation utilis e pour la g n ration de nouveaux noms d instance contient initialement un jeton avec une valeur enti re lt n gt calcul e pour viter de g n rer des noms d objets primitifs et ce pour toutes les classes du syst me Le syst me que nous traitons consiste en deux objets primitifs Pclient 1 et Pclient 2 tous deux de la classe Pclient 154 V 3 Construction du r seau global Ces deux objets sont munis d un marquage initial d fini au V 2 D apr s ces marquages initiaux le marquage de l ObCS d extension de Pclient est le suivant lt 4 Pclient 1 gt lt 5 Pclient 1 gt lt 12 Pclient 2 lt 1 Pclient 2 gt lt 12 Pclient 2 gt
135. clusion entre ces activations Cette description doit indiquer la fois l influence de l tat de l objet sur la disponibilit de ses services et l influence de l ex cution des services sur l tat de l objet Au stade de la sp cification cette vision de l interaction entre tat de l objet et ex cution des services reste n cessairement abstraite puisque la structure pr cise de l objet n est pas d finie Dans le formalisme des Objets Coop ratifs la pragmatique d une classe est d crite en d finissant pour ses instances une Structure de Contr le d Objets par r f rence la m thode HOOD on gardera la d nomination anglaise d Object Control Structure et on parlera d ObCS de sp cification Cet ObCS est d crit par un R seau de Petri Objets L ObCS d une classe est mis en relation avec son interface de la mani re suivante Chaque service d fini dans l interface de la classe est associ une transition au moins du RPO de l ObCS par la fonction Disp dite fonction de disponibilit qui chaque service fait correspondre un ensemble non vide de transitions Une transition associ e un service appel e Transition de Service TS est graphiquement mise en vidence par un arc d entr e et un arc de sortie qui ne sont reli s aucune place du r seau on parle d arcs pendants ces arcs seront appel s respectivement arc d activation et arc de compl tion Par la suite on d signera sous le nom d ObCS d une
136. d Objets Coop ratifs est alors d fini par un ensemble d objets primitifs chacun de ces objets tant lui m me d fini par son nom qui l identifie de mani re unique sa classe et le marquage initial de son ObCS y compris la valeur initiale de ses attributs qui peut tre diff rent de celui d fini par l op ration Create de sa classe La plupart des langages objet se contentent d un seul objet primitif souvent appel la racine du syst me pour d finir un syst me cet objet cr ant ensuite tous les autres pourquoi avoir autoris l existence de plusieurs objets primitifs dans un syst me d Objets Coop ratifs Le domaine d application du formalisme est la mod lisation des syst mes concurrents Dans une cat gorie tr s importante de tels syst mes les objets actifs de haut niveau sont connus en extension et ni leur nombre ni la structure des relations qu ils ont entre eux n voluent au cours de la vie du syst me que l on songe par exemple un atelier de fabrication ou les objets sont des postes robotis s des tapis roulants dont on connait au d part le nombre et la r partition physique dans l atelier Un tel syst me n utilise pas l instanciation dynamique au moins pour ses objets de plus haut niveaul0 I aurait paru tr s artificiel de d finir un tel syst me comme un seul objet qui commence par cr r tous ses composants et d finir leurs inter relations avant de les laisser leur volution normale Un exe
137. dans l exemple des philosophes V 6 L identification des processus s quentiels pourrait tre utilis e pour g n rer des squelettes de codes dans un langage parall le tel que Ada C est un des avantages du formalisme des Objets Coop ratifs que de pouvoir ignorer la notion de processus s quentiel pendant toute la conception pr liminaire et d obtenir cette d composition par analyse de la conception produite 167 8 CONCLUSION SUR LE RESEAU GLOBAL La complexit li e l existence du polymorphisme la cr ation dynamique d objets et la topologie dynamique de la relation d utilisation est traduite par une complexit accrue de la structure du r seau et de son marquage Tout le processus de construction du WSCS repose sur deux m canismes de base e L unification qui permet de retrouver dans le marquage de l ObCS d extension d une classe les jetons qui caract risent l tat d une instance 2 e La g n ration d identificateurs utilis e aussi bien pour la g n ration de nouveaux noms d objet que pour la g n ration d identificateurs d appel Le m canisme de liaison tardive g n ralement implant dans les langages objet par des cha nes de pointeurs vers des descripteurs de classe est implant ici par l unification op ration puissante mais relativement simple mettre en uvre et informatiquement bien ma tris e Une fois le WSCS construit le syst me est repr sent par un r seau pr di
138. dans la file require not plein do ensure not vide end enfile d file INTEGER is Renvoie le plus ancien l ment en l enlevant de la file require not vide do ensure not plein end d file Figure I 1 Une File d entiers en Eiffel e La postcondition en retour cr e une obligation pour le serveur elle d finit les conditions qui doivent tre v rifi es au terme de l ex cution du service enfiler pas pleine l l ment est ins r au d but besoin de traiter le cas o la file est pleine d filer pas vide plus ancien renvoyer Figure I 2 Les deux aspects d un contrat 13 I 1 Les fondements de l approche Objet L norme avantage de cette approche est de pr cis ment qualifier les responsabilit s au cours d une invocation Cette pratique permet d liminer les tests redondants qui sont une des sources de la complexit des logiciels en s assurant que les tests de validit des param tres sont effectu s une fois et une seule L exemple classique de la file permet d illustrer les principes de la programmation par contrat La Figure I 1 montre la sp cification de la classe File en ne donnant que les pr et post conditions des services La Figure I 2 r sume les obligations respectives du serveur et du client lors des invocations 1 4 Hi rarchie d h ritage Dans une d marche de mod lisation la d finition d une hi rarchie d h ritage entr
139. dans la place P afin que les transitions T et T2 soient initialement franchissables pour chacun de ces objets primitifs La d finition du syst me correspondant notre exemple est donn e en Figure V 5 3 CONSTRUCTION DU RESEAU GLOBAL 147 V 3 Construction du r seau global La construction du WSCS est un proc d complexe mais compl tement automatisable et ne n cessite aucune intervention du concepteur la mani re de l dition de liens d un programme informatique Son principe quant lui est relativement simple Les RPO des ObCS des classes sont augment s afin de prendre en compte les divers aspects li s la dynamicit du syst me Les matrices d incidences sont modifi es par ajout de places d arcs et par l adjonction de nouvelles variables aux arcs e Les ObCS ainsi augment s sont rassembl s par fusion de places introduites par les enrichissements Le proc d de construction du WSCS est pr sent ici en six tapes chacune traitant un probl me bien sp cifique e L tape 1 traite uniquement les Transitions d Invocation TT e L tape 2 s occupe de l ex cution correcte des services c t serveur e L tape 3 traite de l instanciation dynamique Ces trois premi res tapes proc dent des augmentations des ObCS e L tape 4 traite de la d finition du marquage initial du WSCS e Les tapes 5 et 6 proc dent des fusions de places afin d obtenir un seul r seau global
140. de 1 ObCS de sp cification Figure IV 3 Sp cification de la classe Composite_Exemple La Figure IV 3 montre la sp cification de la classe que nous allons utiliser pour illustrer la syntaxe de l impl mentation des classes composites On voit qu aucune mention n est faite au niveau de la sp cification du caract re composite de l impl mentation 131 IV 3 Hi rarchie de composition b Impl mentation d une classe composite L impl mentation d une classe composite doit d finir comment une instance composite est constitu e et plus pr cis ment e Combien d instances composantes sont pr sentes dans l instance compos e et quelles sont leurs classes e Quelle est la structure de la relation d utilisation entre instances composantes cette structure tant d termin e par la valeur de leurs r f rences ou par le marquage de leur ObCS e Quel est l tat initial des instances composantes c est dire leur tat au moment o l objet composite est cr On veut notamment pouvoir d finir pour les instances composantes un tat initial diff rent de celui d crit par l op ration create de leur classe e Comment un service publi par la classe composite est traduit en une invocation d un service publi par une des classes composantes D finition IV 3 Impl mentation d une Classe d Objets Composites Une classe d Objets Composites est d finie par e l ensemble des objets composants chacun de ces ob
141. de la m me mani re que la TI est franchie dans l ObCS du client avant toute expansion Il faut noter que le WSCS du syst me exemple est born Il en est toujours ainsi si les ObCS des classes sont born s et si les requ tes de cr ation d objet se produisent en nombre fini Sibertin 91b 159 V 6 Prise en compte des classes composites 6 PRISE EN COMPTE DES CLASSES COMPOSITES Nous n avons pas int gr le traitement des classes composites dans le proc d de construction du WSCS d crit en V 3 pour viter des digressions qui auraient compromis la lisibilit de la proc dure de construction Les classes composites ne sont pas d ailleurs un l ment fondamental du mod le mais essentiellement un outil des structuration et d abstraction Dans ce chapitre nous allons expliciter la mani re d int ger les classes composites dans la construction du r seau global Nous illustrerons cette int gration en compl tant l exemple des philosophes d crit au IV 3 2 Ceci nous permettra galement de d montrer la construction du WSCS sur un exemple significatif et de voir les enseignements que l on peut tirer de l analyse du WSCS L utilisation de classes composites introduit deux probl mes traiter dans la construction du WSCS e L instanciation d un objet composite plus complexe que celle d un objet atomique e La traduction de requ tes vers une instance composite en requ tes vers les composants Ces deux probl mes sont r
142. de livres Georges Perec Les choses Pr s de vingt cinq ans apr s les premiers efforts des pionniers Dahl 66 l approche par objets a pris une place pr pond rante dans la pratique actuelle du g nie logiciel Les intuitions g niales des pr curseurs de l approche objet que furent Dahl et Nygaard ont subi une lente maturation et forment aujourd hui un corpus de concepts et de techniques suffisamment tabli et structur pour en faire un outil majeur de la qualit du logiciel Les concepts fondamentaux de l approche objet se sont r v l s suffisamment f conds pour tre appliqu s dans des domaines tr s diff rents de l informatique Parmi les applications les plus convaincantes des mod les objets on peut citer e La repr sentation des connaissances humaines dans ce domaine l accent est mis sur la flexibilit la puissance d expression et les possibilit s d acc s associatif et d auto organisation des mod les Minsky 75 88 e La mod lisation des donn es et plus sp cialement les Bases de Donn es L important dans ce domaine est l expressivit du mod le pour la mod lisation de structures de donn es et de relations complexes mais essentiellement statiques e La construction de logiciel aussi bien en conception qu en d veloppement o les concepts d objets sont mis en uvre pour l obtention d une qualit sup rieure en termes de fiabilit de modularit d extensibilit et d volutivit
143. des taux d occupation des machines afin de les maximiser c Gestion des cellules au sein de llot La structure physique d un module de production est montr e en Figure VII 2 et son fonctionnement sch matique est illustr en figure VIL3 e Les blocs T1 T7 mat rialisent des portions de convoyage bandes transporteuses Elles sont param tr es par une capacit et un temps de transport e Le bloc Poste regroupe les actions d indexage d op ration technologique et de lib ration du produit un poste de l lot Cette action sera param tr e par une dur e globale de travail de l op rateur 14 Un atelier travaille en flux pouss si l issue du traitement qu elle a subi sur un poste chaque pi ce est automatiquement envoy e sur le poste suivant Le flux est dit tir si chaque fois qu une machine est libre elle appelle la prochaine pi ce traiter Le juste temps est la combinaison de ces deux strat gies Ces trois strat gies peuvent tre mod lis es ais ment par RdP Valette 90 192 VIL 1 Mod lisation d un atelier flexible Et D4 T7 anneau int rieur pousseur tireur T6 anneau ext rieur gt T3 T4 Poste TS D2 D3 Figure VIL3 Fonctionnement d une cellule de production e La cellule regroupe 4 centres de d cisions D D4 dont les r gles de fonctionnement sont les suivantes pour D1 et D2 Un produit venant de T1 est stopp et orient vers T4 via T2 s il est concern
144. e celui d un seul R seau de Petri Objets Cette vision intuitive se heurte l aspect tr s dynamique d un syst me d Objets Coop ratifs cette dynamicit r sultant de l instanciation dynamique et des relations entre objets e Instanciation dynamique de nouveaux objets peuvent tre cr s d autres peuvent dispara tre pendant l activit du syst me et l ensemble des r seaux qui communiquent ne peut donc pas tre d termin de mani re statique e Relations entre objets la relation d utilisation entre instances ne pr sente pas une topologie statique au contraire de la relation d utilisation entre classes les objets se connaissent par l interm diaire de leurs r f rences et ces r f rences peuvent changer de valeur au cours du temps Cette propri t est parfois r f renc e dans le domaine de la programmation concurrente sous le nom de topologie dynamique de processus Cette propri t une cons quence importante quand l architecture des ObCS chaque occurrence d une TI ne r f rence pas n cessairement le m me objet serveur m me la classe de l objet serveur r f renc ne peut tre d termin e statiquement elle peut varier suivant la hi rarchie d h ritage au cours des appels en conformit avec la r gle du polymorphisme On a d fini en IIL 3 5 et UI 4 5 comment un ObCS doit tre interpr t intuitivement par le concepteur afin que sa s mantique soit correctement comprise Ce chapitre
145. e Le choix parmi ces invocations est alors ind terministe en particulier la pr servation de l ordre d mission D finition I 6 n est pas garantie et une invocation peut tre accept e concurremment avec un autre concernant le m me service ou un service diff rent si les transitions de services associ es sont concurremment franchissables D finition 11 22 Nous pr sentons en VI 2 des extensions au formalisme de base de OC qui visent justement permettre de pr ciser l ordre de prise en compte des invocations en attente aussi bien en fonction de leur ordre d arriv e qu partir de crit res de priorit bien d finis b R gle de franchissement concurrent Les transitions d un ObCS de sp cification qu il s agisse de transitions de service ou de transitions priv es sont une description abstraite des op rations qui agissent sur l tat de l objet Au stade de la sp cification on ne peut pas pr juger de la mani re dont seront concr tis es par l impl mentation ces op rations abstraites Le cas le plus fr quent est qu une transition de l ObCS de sp cification sera clat e dans l impl mentation en plusieurs transitions et que l ex cution du service ne sera alors plus atomique On doit donc consid rer que plusieurs transitions peuvent tre tir es concurremment dans l ObCS de sp cification Plus pr cis ment e Toutes les transitions rendues concurremment franchissables par le marquage de l ObCS de sp cificati
146. e Information Systemes using TAXIS ACM conference on Office Information Systems Philadephia Pen June 1982 BARTHET M F SIBERTIN BLANC C La mod lisation d applications interactives appliqu es aux utilisateurs par des r seaux de Petri structures de donn e Actes du 3 colloque exposition de G nie Logiciel pp 117 136 Versailles mai 1986 242 Bastide 90 Bastide 91a Benoit 86 Berthelot 86 Bezivin 84 BI GL 48 BI GL 49 BI GL 57 Bjorner 90 Blake 87 Bleser 82 Bobrow 81 Booch 87 Borning 81 Brachman 83 Bibliographie BASTIDE R PALANQUE P Petri Net Objects for the design validation and prototyping of user driven interfaces Proceedings of IFIP conference Interact 90 Cambridge August 1990 North Holland BASTIDE R SIBERTIN BLANC C Modelling a flexible manufacturing system by means of Cooperative Objects Proceedings of IFIP conference CAPE 91 on computer applications in production and engineering September 1991 Bordeaux France BENOIT CH CASSEAU Y PHERIVONG CH LORE Un langage Objet Relationnel et Ensembliste in BI GL 48 pp 3 13 BERTHELOT G Transformations and decompositions of Nets In Brauer 86 BEZIVIN J Simulation et Langages Orient s Objet Secondes Journ es AFCET sur les langages Orient s Objet BIGRE GLOBULE N 41 pp 194 211 1984 BIGRE GLOBULE N 48 Janvier 1986 Actes des journ es AFCET Inform
147. e classes a plusieurs significations e Tout d abord l h ritage permet de favoriser la r utilisation en pratique un syst me ne se construit pas ex nihilo mais au contraire s appuie sur l exp rience acquise et profite de d veloppements ant rieurs En termes de conception orient e objet cela ce traduit par le fait qu on souhaite r cup rer la conception d une classe pr c demment d velopp e et simplement l adapter de nouveaux besoins sans avoir recommencer sa construction depuis le d but L h ritage est alors consid r comme un proc d essentiellement pratique permettant l extension ais e des classes existantes Dans cette approche une classe est consid r e comme un module dont on souhaite r cup rer et tendre les fonctionnalit s e L h ritage a galement un sens plus fondamental li aux th ories de repr sentation de la connaissance Minsky 75 Ici on cherche structurer l ensemble des classes en une taxonomie permettant de grouper des entit s conceptuellement proches Lorsque l on consid re l extension d une classe l h ritage porte alors une s mantique proche de l inclusion ensembliste Si une classe B h rite d une classe A alors l ensemble des instances de B est inclus dans l ensemble des instances de A L h ritage d crit alors la sp cialisation d une classe par une autre On dira alors qu un B est un A is a ou est une sorte de A a kind of ou AKO Brachman 83 Cardelli 85 La cl
148. e client d un autre serveur OSS si OSS est compatible avec OS et OS est compatible avec O alors le r seau qui r sulte de la fusion des places param tres et r sultat de NSS et NS est compatible avec N Par contre si un serveur est utilis par plusieurs clients L NS MS Tac est comparer avec le langage de requ tes de l union de ses clients l ajout d un nouveau client un serveur remet en question la compatibilit de celui ci avec ses clients pr c dents 232 Conclusion Le formalisme des Objets Coop ratifs d crit dans ce m moire permet de structurer le mod le d un syst me selon les concepts de l approche objet et de d crire sa dynamique en utilisant la th orie des R seaux de Petri Les principales caract ristiques du formalisme sont les suivantes e L unit de mod lisation est l Objet entit qui regroupe des donn es des op rations sur ces donn es et la structure de contr le qui r git l ex cution de ces op rations e Le formalisme est base de classe chaque objet est instance d une classe qui d finit sa structure et son comportement e l Encapsulation des donn es et du comportement des objets est assur e par la d finition pour chaque classe d une sp cification description destin e aux utilisateurs des instances de la classe et d une impl mentation description du fonctionnement exact d une instance Des crit res formels de compatibilit entre sp cification et impl ment
149. e des Objets Coop ratifs s appuie clairement sur une organisation fond e sur une coop ration de type client serveur entre les entit s du syst me Sef Meyer 90 pp 114 118 pour une discussion d taill e sur les s mantiques de valeur et de r f rence dans les langages de programmation 87 II 3 Sp cification d une classe Cette vision asym trique de la communication entre objets se retrouve d s la d finition de l interface l interface d une classe d Objets Coop ratifs doit fournir l ensemble des informations n cessaires la bonne utilisation d une instance de cette classe les informations contenues dans l interface d une classe sont donc pertinentes pour les clients potentiels de cette classe c est dire les autres classes pouvant tre amen es utiliser les services qu elle offre L interface doit fournir toutes ces informations et seulement ces informations il nous para t dangereux d inclure dans la sp cification des informations d une autre nature comme par exemple la liste des services ou des classes requises comme cela est propos dans HOOD cf 1 3 L introduction d une telle information va l encontre de plusieurs principes fondamentaux e La distinction sp cification impl mentation il est clair que l interface requise est d pendante de l impl mentation et l on peut fort bien fournir pour une classe plusieurs impl mentations radicalement diff rentes qui ne requerront pas les m mes
150. e des instances en les consid rant en temps que serveurs ou au contraire de se concentrer sur leur activit en temps que clients e La deuxi me est la relation d utilisation qui d crit la coop ration que peuvent avoir entre elles les instances de classes d objets Nous allons aborder ici un autre type de relation entre classes qui est une des caract ristiques fondamentales des syst mes objets la relation d h ritage dont nous avons d crit les aspects fondamentaux en I 1 4 2 1 H ritage simple Le formalisme des Objets Coop ratifs autorise la d finition de l h ritage entre classes en lui donnant la s mantique du sous typage ou de la sp cialisation qui nous para t plus appropri e dans une d marche de mod lisation que la s mantique de l extension surtout n cessaire pour tendre les possibilit s de factorisation et de r utilisation du code dans les langages de programmation La relation d h ritage sera d crite dans la sp cification des classes avec la syntaxe du langage Eiffel Pour faire de la classe Cs une descendante imm diate de la classe Cg il suffit d ins rer en t te de la sp cification de Cs la clause inherit Cg Une classe Cs descendante d une classe Cg d crit des objets plus sp cialis s que les instances Cg A tout instant une instance de Cs doit pouvoir tre consid r e comme une instance de Cg c est a dire tre capable de rendre les m mes services Un Objet Coop ratif est d
151. e et les m canismes d acc s concurrents cette donn e Des classes qui publient services data flows et ou attributs Ce sont des interm diaires entre des donn es et des processus Leur couplage avec l environnement est plus fort du fait de l implantation par places partag es des attributs et des data flows Enfin les objets passifs qui n offrent pas de services mais uniquement des data flows et ou des attributs Ce sont les donn es du syst me 185 186 VIA Objets passifs PARTIE Ill ETUDES DE CAS ET EXECUTION DES MODELES D OBJETS COOPERATIFS 187 Chapitre VII Etudes de cas Nous pr sentons dans ce chapitre deux tudes de cas trait es par les Objets Coop ratifs Nous avons choisi ces tudes dans deux domaines tr s diff rents dans le but de d montrer l tendue du domaine d application de notre formalisme Ces deux tudes ne sont pas des cas d cole mais au contraire des exemples r els et significatifs de leur domaine e La premi re qui consiste en la mod lisation d un atelier flexible de production est tir e d un cahier des charges mis par une soci t priv e dans le but de choisir un outil de simulation Fritschy 89 e La deuxi me une interface personne logiciel est extraite du dossier de sp cification d un logiciel d ordonnancement court terme d atelier destin l industrie a rospatiale et qui a t r ellement impl ment e par des techniques de programmation co
152. e formalisation du concept d objet dans une approche alg brique Une description par Type Abstrait vise obtenir une description compl te pr cise et sans ambigu t d une structure de donn es sans pour autant se fonder sur la repr sentation physique de cette structure de donn es Meyer 90b Un TAD est une abstraction d un concept pour lequel une impl mentation particuli re n est qu une instance Un Type Abstrait de Donn e d crit une classe de structures de donn es en fournissant un ensemble de services et en pr cisant les propri t s formelles de ces services e Les services sont d crits par leur signature c est dire leur espace de d part et d arriv e Ils donnent en quelque sorte la syntaxe du type e Les propri t s formelles sont de deux ordres les pr conditions et les axiomes Pr condition et axiomes donnent eux deux la s mantique du type Les pr conditions d finissent quand un service est applicable en fonction de l tat de l instance Les axiomes d crivent les propri t s s mantiques invariantes des instances du type L ex cutabilit des Types Abstraits est assur e par des techniques de r criture L aspect formel de cette approche de sp cification permet d effectuer des preuves de coh rence et de compl tude des mod les produits La notion de type abstrait s apparente celle d objet si l on accepte d associer chaque champ un domaine de d finition Cointe 86 C est le choix
153. e la classe car sa structure permet de g rer l volution d un nombre quelconque d instances On peut en voir l exemple en Figure V 8 pour les classes PClient et ServeurG 152 V 3 Construction du r seau global lt x self gt ce lt x self gt lt id gensyn i qensym Rel g y lt x id gt lt id self gt side V lt idselt gt lt idseit lt self id gt lt o id gt pnp V V lt o id gt O AA LILI lt o self gt lt o self gt lt o self gt lt o self gt lt o id self gt 0 1d self gt V V Q lt o s lf gt lt o id self gt lt o id self gt END_OP1 Cki c p i 7 V QE 72777 VILL id Q lt o self gt lt r self gt Kr self gt Figure V 8 ObCS d extension de Pclient et ServeurG tape 3 Nous illustrons par un petit exemple compl mentaire le traitement des attributs qui n est pas couvert par l exemple g n ral que nous tudions Class Implementation Cclientl Attribute attl INTEGER ObCS extrait PX lt x ServeurG gt PY lt x ServeurG r INTE r x service lt attl gt Figure V 9 D finition de la classe Cclient 153 V 3 Construction du r seau global Dans l ObCS de Cclient la Transition d Invocation T invoque le service OP en lui passant comme param tre un des attributs de l objet att1 de type INTEGER A la fin de l tape 3 apr s introduction de la place attribut att et de la variable self l ObCS d extension de C
154. e r solu car une analyse statique des classes du syst me peut permettre de d tecter avant l ex cution ces cas de blocage Ces points seront abondamment repris et comment s dans la deuxi me partie du m moire d volue la description du formalisme Une derni re remarque enfin sur les propositions de Meyer 90a la mention separate est associ e aux variables du syst me et non pas aux classes Une m me classe peut donc produire indiff remment des instances actives ou passives ce qui peut para tre surprenant et va en tout cas l encontre de la plupart des approches pr sent es ici voir par exemple l analyse des propositions de Caromel 90 plus loin dans ce chapitre 23 24 d R sum On peut caract riser une approche de type objet moniteur par les propri t s suivantes e Un objet moniteur n a pas de flot de contr le interne t che de fond activit spontan e Il n est actif que lorsqu il traite un message e Un objet ne traite qu un seul message la fois e Le plus souvent il existe un m canisme interne au langage permettant de mettre des processus en attente d une condition pr condition d attente de Meyer 90a files d attentes dans le langage Trellis Owl Dans une approche de ce type la concurrence d coule de trois m canismes L existence de processus entit s actives qui d clenchent les m thodes des objets moniteurs e L envoi d un signal a un autre objet sans atten
155. e requ tes de service 229 IX 2 V rification de l ObCS d un serveur 3 COHERENCE ENTRE SPECIFICATION ET D IMPLEMENTATION Soient NSPEC MSPEC et NIMP MIMP les ObCS de sp cification et d impl mentation d un serveur Il doivent remplir le m me contrat pour les clients de ce serveur Ceci est assur par le crit re suivant D finition IX 5 Crit re d impl mentation fid le Un ObCS d impl mentation est fid le un ObCS de sp cification s il est tel que il accepte une s quence de requ te si et seulement si elle est galement accept e par l ObCS de sp cification soit L NSPEC MSPEC Tag L Nimp Mimp Tad Ainsi du point de vue d un client il n y a pas de diff rence entre les ObCS de sp cification et d impl mentation 4 OBCS ET HERITAGE Soient C8 et CSPEC deux classes d objets telles que CSPE h rite de CS0 La s mantique de l h ritage relation est un impose qu un client puisse utiliser une instance de CSP exactement de la m me mani re qu une instance de C8 Ceci est assur par le crit re suivant D finition IX 6 Crit re d h ritage du comportement Un objet d une classe CSPEC d riv e d une classe C8 h rite du comportement de C 8 n s il accepte toute s quence d appels de service accept s par une instance de C8 L NSP MSP TSPEC e gt L NS M n TEEN Il faut remarquer que ce crit re est tr s contraignant car le plus souvent on a TB TSPC ac Ceci co
156. e_baguette_a_droite lt riz gt Pas de Pas d baguette baguette Garnir_le_plat bg bd gauche donne baguette _ droit droite donne_baguette_gauch lt bg Donne_baguette_gauche Donne_baguette_droite ji lt bg gt lt bd gt lt be gt lt bd gt lt bd gt Figure IV 7 Impl mentation de la classe Philosophe La classe Philosophe ci dessus pr sente un cas o le graphe d utilisation entre classes est cyclique c est m me un cas d utilisation r cursive cette classe est cliente d elle m me puisque son ObCS contient des invocations de service a d autres instances d elle m me droite donne_baguette_gauche gauche donne_baguette_droite 137 IV 3 Hi rarchie de composition La classe Baguette n est pas d taill e on s int resse ici uniquement l identit des baguettes et les variables qui les d signent servent uniquement sp cifier le flux des baguettes entre les diff rents philosophes On trouve ici une des caract ristiques de notre approche D autres approches auraient mod lis la Baguette comme une ressource en la munissant d op rateurs tels que Prendre et Reposer Bien que cette mani re de mod liser puisse fort bien tre suivie avec notre formalisme elle se r v le ici inutile le jeton typ qui identifie une baguette est suffisant pour mod liser une ressource l objet dont l ObCS contient le jeton est le possesseur exclusif de la ressource On peut s assurer que la ressource est
157. eau On peut facilement constater que toutes les transitions des ObCS de sp cification de Fichier et Fichier_prot g sont vivantes Le calcul de cycles dans les franchissements de transitions permet d identifier les t ches ou les proc dures qu effectue l objet Le r seau est vivant si toute transition appartient un cycle Un objet n a pas forc ment un ObCS cyclique au contraire un objet peut tre cr pour ex cuter une s quence d actions d termin es et ensuite dispara tre On dira qu un objet est mort si son marquage est tel qu aucune transition de son ObCS n est franchissable par exemple un marquage vide si toute transition de l ObCS a au moins un arc d entr e Une classe peut d finir un service nomm par convention suicide tel que la transition de service associ e vide compl tement le marquage de son ObCS Le caract re born des places des ObCS peut donner des indications pr cieuses quant leur s mantique on peut par exemple v rifier que la place Ecrivain de l ObCS de Fichier_prot g est born e 1 tablissant ainsi que le fichier tol re une seule ouverture en criture la fois La place Lecteurs au contraire n est pas born e car partir du marquage initial la transition Ouvrir_en_lecture est ind finiment franchissable ce niveau de description en effet on ne se soucie pas de limites physiques d impl mentation qui limiteraient forc ment le nombre de lecteurs Le calcul d invaria
158. en cours d dition t le s lectionner D truire D truire le n uplet en cours d dition En s lectionner un nouveau s il en reste sinon en cr er un avec des valeurs par d faut R tablir Annuler toute dition effectu e sur le n uplet et restaurer ses valeurs initiales S lectionner lt cl Identifiant gt S lectionner le n uplet ayant la cl sp cifi e et afficher la valeur de ses attributs Quitter Terminer le dialogue fermer la fen tre Create fen Fen tre is f fen D faut n_uplet Create end Create Edit lt o dup n_uplet gt S lectionn Liste D faut lt o n_uplet gt y Y ON lt o dup gt lt o dup gt lt o dup gt lt o dup gt remplacer o d truit lt o gt Eee PR ajouter o ajoute T2 lt o gt d truire x d truit x d truit o affiche lt self f gt 0 create o affiche lt self f gt Figure VII 26 Impl mentation de la classe Editeur 219 VIL2 Interfaces Personne logiciel Pour compl ter la d finition du Dialogue il faut associer les divers d clencheurs pr sents dans la repr sentation externe aux services offerts par la classe Editeur e Les quatre boutons poussoir de la zone de commande Ajouter D truire Remplacer R tablir sont associ s aux services de m me nom e La zone de d filement est associ e au service S lectionner L l ment de
159. endre les mod les produits plus concis La troisi me partie constitue un rappel bibliographique traitant des techniques de structuration des RdPHN et des approches int grant les concepts d objets et de RdP 37 IL 1 Les R seaux de Petri Objet 1 LES RESEAUX DE PETRI A OBJET Les R seaux de Petri Objet RPO Sibertin 85 font partie de la cat gorie des R seaux de Petri de Haut Niveau qui sont caract ris s par le fait que les jetons qui constituent le marquage des places ne sont pas des entit s atomiques et indiff renci es mais peuvent tre distingu s les uns des autres et portent une valeur La d finition formelle des RPO a un pr requis math matique assez important que nous rappelons dans la section II 1 1 Nous donnons ensuite de mani re tr s d taill e la d finition des RPO Les RdP en g n ral et les RPO en particulier b n ficient d une repr sentation graphique simple et attrayante qui facilite une compr hension intuitive du mod le il n est heureusement pas n cessaire de ma triser tous les points th oriques de la d finition des RPO pour produire des mod les corrects Le lecteur familier avec les techniques de manipulation des multiensembles et des suites finies d l ment peut se dispenser de la lecture du pr liminaire math matique S il a connaissance de mod les de RdP de haut niveau tels que les R seaux Color s Jensen 81 87 ou les r seaux Pr dicat Transition Genrich 87 il peut
160. ent Coop ration Create op ration Un client est toujours inform de l ach vement d une invocation qu il a adress e un serveur Si le service comporte des param tres en sortie le client est inform par la disponibilit des valeurs r sultats Sinon il l est par un signal appel Accus d ex cution Activit d un objet qui n est pas la cons quence d une invocation de service mais qui est entreprise de la propre initiative de l objet en fonction de son tat L activit spontan e d un objet est d crite dans l ObCS d impl mentation de sa classe Arc pendant en entr e d une transition de service tiquet par les param tres formels d entr e du service Lors de la construction du WSCS cet arc relie la place param tre la transition d accord du service Arc pendant en sortie d une transition de service tiquet par les param tres formels de sortie du service Lors de la construction du WSCS cet arc relie la place r sultat la transition de compl tion du service El ment de la structure de donn e d une classe et d fini dans son impl mentation par un nom et un type Si son type est un type classe l attribut est une r f rence si c est un type simple l attribut est une propri t Ou Classe d objets atomiques Classe feuille du graphe de la relation de composition Ses instances ne sont pas d composables en instances de classes plus simples par opposition classe composite Ou Classe d objet
161. ent sa lisibilit on s autorise repr senter graphiquement plusieurs fois la m me place Toutes les ellipses o figure le m me nom r f rencent donc la m me place et les arcs incidents cette place sont l union des arcs incidents ses repr sentations graphiques Certaines places qui d crivent des tats ou des conditions transitoires peuvent tre repr sent es par des ellipses anonymes Bien entendu chacune de ces ellipses anonymes d note une place diff rente 7Cette facilit graphique doit tre utilis e avec discernement car un usage abusif pourrait rendre la lecture de l ObCS plus difficile l encontre de l effet escompte 92 II 3 Sp cification d une classe Disp Sv1 T1 T4 Disp Sv2 T2 Disp Sv3 T3 lt pl p2 gt lt vl v2 gt Figure IIL 4 Syntaxe graphique de la pragmatique d une classe Le nom d une transition appara t c t du rectangle qui la repr sente Dans de nombreux cas on s abstiendra de faire figurer le nom des transitions sur la repr sentation graphique des r seaux Si la transition est associ e un service le nom de ce service appara t en gras l int rieur du rectangle qui la repr sente On a soulign le fait que le m me service peut tre associ plusieurs transitions de l ObCS On trouvera donc fr quemment dans un ObCS des rectangles portant le m me nom de service Si une transition comprend une action le texte de celle ci appara t en c
162. ent ais ment de d crire un univers d objets atomiques ainsi que les inter relations entre ces objets Toutefois les entit s du monde r el sont souvent per ues non pas comme atomiques mais au contraire comme compos es d autres entit s moins complexes Un avion par exemple est facilement d crit comme l assemblage d un fuselage de moteurs de trains d aterrissage On voit imm diatement que la relation d h ritage ne convient pas pour d crire ce genre d information un avion n est pas un fuselage on pourrait par contre tre tent de traduire la composition par la relation d utilisation en consid rant les objets composants comme des attributs de l objet compos Cette solution qui est effectivement adopt e par de nombreux langages objets Eiffel Smalltalk pr sente plusieurs inconv nients notables Mayer 91 e Elle ne permet pas de d crire des relations sp cifiques qui existent entre composants et compos par exemple des relations de type g om trique ou des contraintes topologiques e Elle encourage la confusion entre deux concepts bien distincts utilisation et composition qui existent dans le monde r l et qui doivent tre maintenus dans le mod le que l on en donne surtout si l on cherche fournir des mod les structur s l image du syst me qu ils d crivent Nous nous proposons donc d int grer dans notre formalisme la possibilit de d crire la relation de composition entre classes d ob
163. ent la s mantique d un syst me d Objets Coop ratifs En section II 2 nous proposons un certain nombre d extensions originales aux RPO que nous utiliserons au sein de notre formalisme Les sections II 3 et II 4 sont une tude bibliographique des techniques propos es pour la structuration des mod les de RdP de Haut Niveau La deuxi me partie est d volue la d finition du formalisme des Objets Coop ratifs et constitue l apport central de notre travail e Le chapitre III montre la mani re de d crire une classe d Objets Coop ratifs du point de vue de sa sp cification aussi bien que de son impl mentation e Le chapitre IV d crit la constitution d un syst me ex cutable d Objets Coop ratifs partir de la d finition des classes d objets et la mani re d organiser les classes en deux hi rarchies la hi rarchie d h ritage et la hi rarchie de composition e Le chapitre V est consacr la s mantique formelle d un syst me d Objets Coop ratifs Nous montrons comment construire partir de la d finition du syst me et de celle des classes qui le composent un r seau de Petri unique qui d finit la s mantique op rationnelle du formalisme e Le chapitre VI propose des extensions au formalisme de base afin de rendre plus facile la mod lisation ou d en tendre le domaine d application pp La troisi me partie pr sente deux tudes de cas et traite ensuite des possibilit s d ex cution et d analyse stat
164. entre deux dur es Date X Duration Date permettant d ajouter une dur e une date Date X Duration Date permettant de soustraire une dur e a une date Date X Date Duration permettant de calculer l intervalle de temps s parant deux dates 70 II 2 Extension des RPO Les dates et les dur es sont d autre part munies de la relation d ordre lt Pour prendre en compte le temps dans un RPO il suffit d introduire dans ce r seau un registre temporel Now lt Date gt 0 La mani re dont ce registre volue n est pas d finie dans le r seau On suppose alors que c est l environnement qui met jour la valeur de l horloge On peut galement utiliser les techniques d crites dans Richter 85 Oberweis 86 pour d crire l volution de l horloge au sein m me du r seau En tout tat de cause la seule hypoth se faite est que l volution de cette valeur est monotone et croissante Conform ment la d finition des registres II 2 2 toute transition du r seau peut acc der la valeur de Now qui est interpr t e comme la date courante au moment du franchissement de la transition Bien entendu comme l volution de la variable Now est ext rieure au r seau les transitions ne peuvent y faire que des acc s en lecture i e en partie droite des affectations lt b gt lt a gt ec lt b lt a gt LD GER lt al b gt EndTj lt a b gt Figure IL 23 mulation d une transition
165. ents de cette classe et d finit le comportement ou mode d emploi des objets instances Son impl mentation d crit le fonctionnement r el des instances et notamment comment elles se comportent elles m mes en tant que clients d autres objets Des crit res formels de coh rence entre sp cification et impl mentation sont d finis Un algorithme est fourni qui permet partir des r seaux de comportement des classes d un syst me de construire un r seau Pr dicats Transitions global pour tout le syst me Cet algorithme prend en compte les probl mes relatifs l instanciation la relation d utilisation dynamique l h ritage et au polymorphisme Le m moire est organis comme suit La premi re partie chapitre I et II est une tude bibliographique concernant les formalismes sur lesquels se fondent les Objets Coop ratifs L approche Objet et plus particuli rement la concurrence dans cette approche est d abord tudi e On donne ensuite une d finition d taill e des R seaux de Petri Objets et on tudie les techniques de structuration des r seaux de haut niveau La deuxi me partie est consacr e la pr sentation du formalisme et constitue l essentiel du travail pr sent Le chapitre II montre comment d finir les classes d Objets Coop ratifs aussi bien en sp cification qu en impl mentation Le chapitre IV traite de la d finition d un syst me d Objets Coop ratifs Le chapitre V d finit la
166. er flexible Class Implementation D rivation Attributes pr c dent d riv Transport ObCS Entree Sortie lt Palette gt Circule lt Palette gt Hard FIFO TRANSMETTRE Circule capa 2 ilot peut_traiter lt pal pal ilot transmettr Figure VII 12 Impl mentation de la classe D rivation 1 5 Mod lisation d un ilot Nous avons maintenant d crit les classes d objets l mentaires qui composent un objet composite de classe Atelier Nous allons d crire un Zot de quels objets est il constitu et par quels objets les services qu il rend sont ils assur s Tout d abord un Zot peut tre consid r comme un Transport il sait Transmettre des palettes et dire si il Peut_traiter une palette ou non La sp cification d Iot est donc identique celle de Transport ceci pr s que l Ilot n assure pas que les palettes soient restitu es dans l ordre FIFO La clause Hard FIFO doit donc tre supprim e 202 VIL 1 Mod lisation d un atelier flexible Class Specification Ilot inherit Transport ObCS Circule lt Palette gt Che TRANSMETTRE capa Figure VIL 13 Sp cification de la classe composite ot Il s av re que toutes les op rations publiques de Zot sont en fait des op rations de Entr e_Ilot Cela tient au fait que c est cette classe d objet qui assure l interface entre un distributeur et un Ilot Figure VII 14 Impl mentation de la classe composite Zlot 203 VIL 1 Mod
167. ert s lectionner les jetons susceptibles d tre utilis s pour le franchissement d une transition t en sortie de p On peut envisager deux interpr tations pour le tri e Tri fort hard Le tri lieu avant l tape de filtrage et peut bloquer la franchissabilit de t On ne peut construire une substitution qu avec le jeton qui optimise le crit re de tri e Tri faible soft Le tri sert choisir une substitution parmi celles qui rendent t franchissable on franchit avec la substitution qui optimise le crit re de tri On verra que ces deux interpr tations ne sont quivalentes que si la transition t n a pas de pr condition Dans les deux cas le tri peut tre ascendant Ascending si on cherche minimiser le crit re de tri ou descendant Descending dans le cas contraire Une place p fortement tri e suivant la fonction Trip sera not e P lt v1 Cis Vn C7 Hard Ascending Trip lt vj v gt ou P lt v1 Cis Va Cp gt Hard Descending Trip lt v Vp Un place p faiblement tri e suivant la fonction Trip sera not e P lt v1 Cis Vn Cp gt Soft Ascending Trip lt v v gt ou P lt v1 Cis gt va C gt Soft Descending Trip lt v Vn gt Avant de caract riser formellement l influence du type de tri sur la franchissabilit des transitions yp nous illustrons les tris forts et faibles l aide de deux exemples Exemples Figure I
168. ervices et seront donc n cessaires aux utilisateurs du composant De m me certaines constantes symboliques peuvent tre rendues publiques e La sp cification doit en plus d finir la pragmatique du composant par pragmatique on entend la fois son mode d emploi ses conditions d utilisation son comportement et le r le qu il peut jouer dans l architecture d un syst me La pragmatique d un composant inclut donc sa fonction et son fonctionnement Ces diff rentes facettes r unies donnent la s mantique du composant qui est une information tout aussi importante que l information syntaxique fournie par l interface Il convient de noter que de nombreux langages ne permettent pas d exprimer formellement la pragmatique dans la sp cification d un composant logiciel Ce que le langage Ada par exemple d signe sous le nom de sp cification d un paquetage n est en r alit que son interface et la pragmatique ne peut tre fournie que par des inscriptions commentaires pseudo code qui sont ext rieures au langage lui m me A l oppos Eiffel exprime la pragmatique d une classe en rendant publics des invariants associ s la classe et des pr conditions et postconditions associ es l ex cution des services offerts dans un esprit proche de la th orie de Types Abstraits de Donn es b Vue interne La vue interne d un composant d crit la mani re dont ce composant est impl ment c est dire comment il est fait et nota
169. es avec des d rivations avant et apr s chaque poste Les postes sont situ s sur la piste ext rieure Le fonctionnement des machines est asynchrone 189 VII 1 Mod lisation d un atelier flexible Une palette tournant dans un lot et concern e par un poste de travail passe de l anneau int rieur l anneau ext rieur via les d rivations pr vues cet effet Apr s l arr t devant un poste par deux bloqueurs la palette est index e pour assurer un positionnement pr cis puis l op ration a lieu Lorsqu elle est termin e la palette peut aller au poste suivant soit par l anneau ext rieur soit par l anneau int rieur Figure VII 2 D un point de vue m canique le transport des produits est assur par des tapis roulants En cas de blocage des palettes aux stoppeurs il y a glissement puis accumulation fifo module de transfert deux voies Maa Poste 4 I Poste 5 module de transfert une voie WE a pa pa mieu ILOT 2 Poste 1 Poste 2 Poste 3 piste droite piste gauche DISTRIBUTEUR IZA A ot ti d rivation Sra l Tm m EEA il za 5 a ON NO A Poste 1 Poste 3 L J Module a Module a poste nae i automatique doubles Figure VIL1 Plan g n ral de l atelier 1 2 Conduite du syst me de production La quantit de palettes qui circule dans l atelier d assemblage est fixe Chaque palette est cod e dynamiquement l information qu elle v hicule
170. es entre serveur et client e Op rations internes Les transitions de l ObCS d impl mentation qui ne sont pas des TI peuvent comporter une action qui est d finie comme Un appel d op ration interne proc durale de la forme op ration P1 P2r 1Pn Une affectation de la forme var expression o var est une variable de sortie de la transition ou un attribut de la classe et o expression peut contenir une combinaison arbitraire d appels d op rations internes fonctionnelles Le sous r seau compris entre une transition d accord et la transition de retour d un service est appel la Structure de Contr le de l Op ration ou OpCS Operation Control Structure par r f rence la m me notion dans la m thode HOOD L OpCS montre quels peuvent tre les encha nement d actions effectu es lors d une invocation concernant ce service Un OpCS peut tre purement s quentiel ou comporter du parall lisme d crit par la structure du sous r seau Un service pouvant avoir plusieurs transitions d accord il peut y avoir plusieurs OpCS pour le m me service ceci permet de sp cifier que le traitement d une op ration d pend de l tat de l objet serveur Certains crit res structurels doivent tre respect s par les OpCS visant notamment assurer qu un service accept pourra toujours tre men son terme Ces crit res sont d taill es au chapitre IX 107 II 4 Impl mentation d une classe 4 4 Exemples Nous allons
171. es messages PAST en sp cifiant si O attend un acquittement accus de r ception de la part de T avant de continuer ou s il continue sans acquittement On verra 1 3 que le premier cas correspond aux requ tes LSER et le deuxi me aux requ tes ASER de la m thode HOOD e Messages NOW Dans ce protocole O attend non seulement que T ait re u le message mais qu il ait termin le traitement associ et renvoy le r sultat Ce protocole d crit donc une communication de type question r ponse comparable un appel de proc dure distante Il correspond aux requ tes HSER de HOOD e Messages FUTURE ce protocole reprend essentiellement la s mantique de l attente par n cessit d crite en I 2 c Les objets ABCL sont s rialis s c est dire qu ils traitent les messages dans leur ordre d arriv e un seul message la fois Il est pr vu d introduire dans le langage des objets non s rialis s mais nous n avons pas trouv de description de ces objets dans les textes auxquels nous avons eu acc s En l absence d objets non s rialis s le parall lisme est exprim en ABCL de trois mani res e Activation concurrente des objets caus e par les messages PAST e Multi casting c est dire envoi simultan du m me message une famille d objets e Parall lisme interne le traitement associ un message peut d finir des flots de contr le parall le b R sum Les mod les d acteurs sont souvent caract r
172. essable par sa position par rapport au d but du fichier e La classe Fichier_ prot g d crit un fichier de m me type mais qui d finit en plus une politique de gestion pour ses acc s en lecture et en criture a La classe Fichier La sp cification compl te de la classe Fichier se trouve en Figure III 6 Cette sp cification ne publie ni types ni constantes et on y distingue quatre parties La d finition des services chaque service est d fini par un nom8 sa liste de param tres formels d entr e figurant entre lt gt et sa liste de de param tres formels de retour suivant la syntaxe d finie au III 3 2 Les mots cl s du langage directement emprunt s au langage Eiffel sont mis en gras e L op ration de cr ation Create dont le code appara t apr s la d finition de tous les services e La d finition des places de l ObCS pour chaque place d sign e par son nom cette partie d finit son type c est dire la mani re dont sont construits les n uplets de valeurs que cette place peut recevoir e Enfin la repr sentation graphique de l ObCS qui utilise les conventions cit es plus haut La fonctionnalit d crite par l ObCS de Fichier est tr s simple un objet instance de la classe Fichier est associ un fichier physique du syst me d exploitation Cet objet est cr dans l tat Ferm et ne peut alors accepter que le service Ouvrir qui le place dans l tat Ouvert Une fois ouvert un fichier
173. est fortement tri e suivant un crit re Trip nous allons d crire deux motifs diff rents Le premier est une simple abr viation des RPO mais n cessite de fournir explicitement les l ments de Type p pour lesquelles la fonction Trip prend son maximum et son minimum le second n a pas cet inconv nient mais utilise un arc inhibiteur qui en lui m me constitue une extension du pouvoir d expression des RPO 4 Le plus fr quemment les fonctions Trip seront tr s simples sinon triviales dans les exemples des Figures II 16 et II 18 la fonction Trip est l identit et les l ments fournir seraient MinInt et MaxInt respectivement limites de repr sentation des entiers d pendantes de l impl mentation Dans de tels cas les l ments pourraient bien entendu tre calcul s automatiquement 67 II 2 Extension des RPO Marquage initial lt MIN MAX gt lt x V gt lt V MAX gt lt V gt Figure IL 20 Motif se comportant comme une place tri e version 1 Le motif d crit en Figure 11 20 utilise un principe analogue au tri par insertion On notera MIN resp MAX la valeur pour laquelle la fonction Trip prend son minimum resp son maximum sur son domaine Le marquage initial de la place P1 est constitu du seul doublet lt MIN MAX gt Le principe qui guide l volution de ce motif est que pour ins rer le jeton V dans la place on retire de cette place un doublet lt xj yj gt tel Trip xj lt
174. est modifi e au cours du temps tat du produit op ration suivante par les postes de travail sur lesquels elle passe 190 VIL 1 Mod lisation d un atelier flexible a Gestion du distributeur Les r gles de gestion de l anneau de distribution sont les suivantes a une palette passe de l anneau de distribution vers un lot si celle ci est concern e par l lot b une palette concern e ne peut entrer dans l lot que si le stock amont de r ception de cet lot est apte la recevoir Si le test est n gatif la palette reste en attente sur l anneau de distribution jusqu l occurrence d une place libre c une palette peut sortir d un lot et rejoindre le stock central sur l anneau de distribution uniquement si toutes les op rations subir sur cet lot ont t r alis es d une palette sortant d un lot est prioritaire sur celles qui circulent dans le distributeur On peut toutefois concevoir un rebouclage sur l anneau int rieur de l lot si le stock aval de sortie sur le distributeur est plein b Gestion des lots Chaque lot fonctionne de la m me mani re Les r gles de gestion sont les suivantes a les palettes quittant le distributeur entrent dans un lot par son anneau ext rieur Cette contrainte li e l architecture m me du syst me de production impose un passage obligatoire du produit sur le premier poste de l lot pour subir ou non l op ration C est notamment le cas du produit
175. esult fpos stream end fposition FOuvrir is Ouvre le fichier external fopen language C do stream fopen chemin r end fOuvrir FFermer is Ferme le fichier external fclose language C do fclose stream end FFermer FAller_en position INTEGER is Met position l indice du caract re courant external fseek language C do fseek stream position 0 end FAller_en FLire combien INTEGER STRING is Renvoie une cha ne d au plus combien caract res lus partir du caract re courant external fread language C do fAller_en fPosition stream 108 II 4 Impl mentation d une classe tampon retailler combien fread tampon en_c 1 combien stream result tampon end Flire FEcrire chaine STRING is Ecrit cha ne partir du caract re courant external fwrite language C do fAller_en fPosition stream fwrite chaine 1 chaine longueur stream end FEcrire create lt nom STRING gt is Initialisation des attributs chemin nom D finition du marquage initial de l1 ObCS Ferm lt gt Create lt combien gt Lire Ecrire chaine Flire Fecrire lt position gt Position Aller_en pos Fpositior Faller_en Figure III 11 Impl mentation de la classe Fichier b Classe Fichier_prot g impl mentation L impl menta
176. et dont le nom est alors Ctrl _ lt nom du parent gt e Par plusieurs enfants dont l un au moins sera actif 3 34 1 3 La m thode HOOD ACTIVE STACK A Ctrl Active Stack EXCEPTION LOG Figure I 7 Syntaxe graphique des objets HOOD La Figure I 7 HRM 89 illustre la populaire repr sentation graphique des objets HOOD la relation d inclusion est mat rialis e par le fait que les objets enfants sont dessin s l int rieur du parent La relation d utilisation entre objets fr res est d crite par un arc de l objet utilisateur l objet utilis La figure montre galement quelques conventions graphiques de la m thode les objets actifs sont d sign s par la lettre A gauche de leur en t te les op rations qui ont des contraintes fonctionnelles d activation sont point es par une fl che en zig zag les fl ches gris es entre op rations mat rialisent le fait qu une op ration du parent est impl ment e par une op ration d un enfant l objet Exception_log est un objet Oncle c est dire un objet utilis par Active_stack au niveau sup rieur de d composition 3 4 Flots de donn es et d exceptions Les flots de donn es et d exception sont mentionn s sur la repr sentation des objets par des annotations graphiques sur les fl ches repr sentant la relation d utilisation Toutefois cette indication est assez peu lisible car on ne sait pas quelles op rations sont concern es par ces changes de donn
177. et en sortie aux places attribut attj 7 de l ObCS des classes Clj 7 pour 1 1 n 1 Les arcs incidents sont tiquet s par lt att 47 att gt Comme le syst me exemple que nous traitons tout au long de ce chapitre ne contient pas de TA nous illustrons cette op ration relativement complexe par un petit exemple compl mentaire Figure V 12 Class Implementation Cclient2 ObCS extrait Pl lt var Cserveurl gt a attl att2 Class Specification Cserveurl attl Cserveur2 Un attribut public de classe Cserveur2 156 V 3 Construction du r seau global Class Specification Cserveur2 att2 BOOLEAN Un attribut public Bool en Figure V 12 acc s cha n aux attributs publics L expression var att1 att2 pr sente dans la pr condition de l ObCS de CClient2 s value bien comme un Bool en La transition T1 est donc une TA avec n 2 Le WSCS g n r par ce fragment d ObCS est illustr en Figure V 13 On voit que l acc s aux attributs publics est implant d une mani re tr s diff rente que l invocation on acc de directement au marquage d une place d un autre ObCS sans passer par l interm diaire du m canisme de synchronisation r alis par les places param tre et r sultat et le couplage entre l objet client et l objet serveur en est d autant plus fort Ceci motive en grande partie les r serves m thodologiques que nous avons mises en III 3 quant l utilisation des attributs pub
178. ets Coop ratifs Dans l id al le processus de construction de la cl ture des classes devrait tre un processus interactif support par un environnement logiciel permettant l examen de chaque classe disponible et le choix entre son impl mentation ou sa sp cification En l absence d un tel environnement on d crira ici un syst me d Objets Coop ratifs par une notation textuelle la syntaxe simple et auto explicative illustr e en Figure IV 1 On y donne tout d abord la description des objets primitifs avec leur marquage initial La cl ture de la relation d utilisation est ensuite donn e en extension avec pour chaque classe le choix d utiliser sp cification ou impl mentation Dans le formalisme des Objets Coop ratifs la seule unit de conception reste donc la classe et un syst me est d crit avec un notation externe au formalisme Ceci permet de bien s parer la d finition d une classe de celle du syst me qui l utilise et favorise donc la r utilisation des classes au sein de syst mes diff rents et l exp rimentation en cours de conception 1 2 Le syst me et son environnement Lorsqu il entreprend la mod lisation d un syst me le concepteur doit d finir o se situe la fronti re entre le syst me qui est la partie qu il doit d crire et son environnement qui chappe sa description Il doit galement sp cifier comment le syst me qu il d crit interagira avec son environnement car aucun syst me r el n vo
179. eules op rations d finies sur tous les types simples savoir l affectation le test d galit et l utilisation en tant que param tre effectif cette restriction tant alors sp cifi e par le mot cl is private Un type classe C2 peut tre publi en mode private dans l interface d une autre classe C1 emp chant ainsi les clients de C1 d effectuer des invocations sur les param tres de classe C2 L interface contient ensuite la d claration de constantes symboliques Une constante est d finie par e Son nom qui la m me visibilit que les types export s e Son type qui est soit un type simple pr d fini soit un type simple export par la classe il n existe pas de constantes de type classe 88 II 3 Sp cification d une classe Les constantes symboliques sont utiles pour d signer des valeurs singuli res qui peuvent tre renvoy es par les services Un service est d fini par e Son nom qui identifie compl tement le service l int rieur de la classe Contrairement d autres langages tels que C on n autorise pas la surcharge des noms de service qui permet de fournir plusieurs versions du m me service qui est alors identifi par son nom et sa signatures e Sa signature c est dire la d finition de ses param tres d entr e et de sortie Tous les services sont fonctionnels ils ont une liste de param tres en entr e et une liste de param tres en sortie chacune de ces deux listes pouv
180. ew in LNCS 87 pp 20 61 FERBER J Quelques aspects du caract re self r flexif du langage MERING BIGRE N 41 D FRITSCHY Cahier des charges pour l acquisition d un outil de simulation temporelle des flux de production SORMEL Besan on 1989 GALTON A Editor Temporal Logics and their Applications Academic Press1987 Predicate Transition Nets in LNCS 87 Part I Vol 254 pp 207 247 GENIE LOGICIEL ET SYSTEMES EXPERTS N 17 D cembre 1989 Ada Les technologies Objets ISSN 0295 6322 GOLDBERG A ROBSON D Smalltalk 80 The Language and its Implementation Addison Wesley 1983 GUTTAG J Abstract Data Types and the Development of Data Structures Communications of the ACM Vol 20 n 6 June 1977 HACK M H T Analysis of production schemata by Petri Nets TR 94 MIT Boston 1972 HACK M Petri Nets Languages Comput struct Gr Memo 124 Project HAC M IT Cambridge Mass Juin 1975 HALBERT D C O BRIEN P D Using Types and Inheritance in Object Oriented Languages in ECOOP 87 pp 23 34 HAREL D LACHOVER H NAAMAD A PNUELI A POLITI M SHERMAN R STHUL TRAURING A STATEMATE A Working environment for the development of Complex Reactive Systems 10th IEEE International conference on Software Engineering Singapore April 1988 VAN HEE K M SOMERS L J VOORHOEVE M Executable Specifications for Distributed Information Systems in Informations Systems Concepts An In depth Analysi
181. f the ACM Vol 33 n 9 pp 125 141 September 1990 ALLA H L R seaux de Petri color s et R seaux de Petri continus application l tude des syst mes v nements discrets Th se de doctorat d tat de l institut national polytechnique de Grenoble Grenoble Juin 1987 AMERICA P Inheritance and Subtyping in a Parallel Object Oriented Language in ECOOP 87 pp 281 290 ANDRE C Use of the Behaviour equivalence in Place Transition Net Analysis in Application and Theory of Petri Nets IFB 52 Springer 1982 ANDRE C Syst mes volutions parall les mod lisation par r seaux de Petri capacit et analyse par abstraction Th se d tat Universit de Nice F vrier 1981 AUDUREAU FE FARINAS DEL CERRO L ENJALBERT P Th orie de la programmation et logique temporelle Premi re partie Validation d algorithmes s quentiels Technique et Science Informatique Vol 6 n 6 pp 527 540 1987 AUDUREAU FE FARINAS DEL CERRO L ENJALBERT P Th orie de la programmation et logique temporelle Deuxi me partie Validation d algorithmes parall les Technique et Science Informatique Vol 7 n 2 pp 181 200 1988 BAKO B Mise en uvre et simulation du niveau coordination de la commande des ateliers flexibles une approche mixte r seaux de Petri et syst mes de r gles Th se de L universit Paul Sabatier de Toulouse Toulouse Octobre 1990 BARRON J Dialogue and Processing Design for Interactiv
182. fini par trois composantes cf III 3 sa structure de donn es les services qu il offre et son comportement Il nous faut d finir comment ces trois composantes peuvent voluer le long de la hi rarchie d h ritage pour que cette compatibilit entre instances soit respect e a Heritage et structure de donn es La structure de donn es d une classe est d finie par un ensemble d attributs dont certains sont publics d clar s d s la sp cification et d autres priv s d clar s dans l impl mentation Les attributs priv s d une classe sont inaccessibles ses clients et donc sans int r t pour eux Il suffit donc pour que Cs soit compatible avec Cg en termes de structure de donn es que la r gle suivante soit respect e 126 IV 2 Hi rarchie d h ritage D finition IV 1 H ritage et structure de donn es Si Cs est une classe descendante de Cg l ensemble As des attributs de Cs est inclus dans l ensemble Ag des attributs de Cg Au niveau syntaxique on s abstiendra de r p ter les attributs h rit s dans l interface d une classe et yntaxiq p une classe pourra d finir de nouveaux attributs publics Aucune hypoth se n est faite sur les attributs priv s et deux classes reli es par la relation d h ritage peuvent avoir des ensembles d attributs priv s compl tement disjoints b H ritage et services L utilisation d un objet se fait par l interm diaire de ses attributs publics mais aussi et surtout par
183. ge Eiffel que B Meyer pr sente lui m me comme une impl mentation possible des TAD il est possible d exprimer des contraintes relatives aux s quencements possibles entre les invocations mais ceci n cessite souvent l introduction de variables d instance cet effet une impl mentation en Eiffel de la classe Fichier d crite en II1 3 4 publierait un attribut Ferm et le service Ouvrir aurait comme pr condition require Ferm e Avec la s mantique du contrat concurrent la granularit d ex cution est l ex cution d un service un service n est pas interruptible Il n est donc pas possible d exprimer des synchronisations ou du parall lisme au sein m me de l objet Cette contrainte provient du fait que le contrat d un objet est exprim par la logique du premier ordre qui est par essence s quentielle Une voie de recherche possible serait d exprimer le contrat d un objet par des assertions exprim es en logique temporelle Galton 87 qui souvent propos e en alternative aux RdP pour la mod lisation des syst mes concurrents 119 Chapitre IV Syst mes d objets coop ratifs et organisation des classes Le chapitre pr c dent tait d volu la description des classes d Objets Coop ratifs Le chapitre pr sent a pour objectif de montrer comment un ensemble de classes peut tre utilis pour la d finition d un syst me ex cutable IV 1 et comment cet ensemble de classes peut tre structur suivant les hi rarchies d h
184. gt lt ancien id Figure VI 8 Sp cification et s mantique d un service de mise jour Ces services ont des propri t s remarquables e Une invocation les concernant n a aucune influence sur le contr le interne du serveur la r partition du marquage dans son ObCS n est pas modifi e ni la valeur de ce marquage si l on excepte celui de la place attribut concern e par la modification D autre part l ex cution de ce service est atomique elle correspond au franchissement de la transition de service e Une telle invocation n a pas non plus d influence sur le contr le du client de l appel ce service est toujours disponible pour peu que l attribut concern ait t initialis et son ex cution est galement atomique Du point de vue du client l ex cution du service n est donc pas diff rente de l ex cution d une op ration interne algorithmique Ces deux propri t s sont les caract ristiques d un flot de donn es entre les objets Dans le cas d un service de mise jour ce flot de donn es est bidirectionnel la nouvelle valeur de l attribut est transmise du client vers le serveur et l ancienne est renvoy e du serveur au client L acc s en lecture un attribut public IIL 3 ou son initialisation constituent un flot de donn es mono directionnel l2Dans le cas ou l ObCS d extension serait non connexe on serait en droit de se demander si le mod lisateur a bien identifi un objet c est dire une entit for
185. gurent galement en sortie Vt te p Pr p t Pr p tj Post p ti Post p tj Les tiquettes des arcs adjacent p sont toutes identiques p peut tre omise sur la repr sentation graphique du r seau ainsi que tous les arcs qui lui sont adjacents Figure II 4 On introduit sa place dans la d finition du r seau un registre Reg Nom Type Val_ init avec Nom Pr p ti Type Type p Val_init mo p Cette construction pour inconv nient de dissimuler le fait que deux transitions utilisant le jeton de la place registre ne peuvent pas tre franchies concurremment Ceci nous parait largement compens par l all gement de la repr sentation graphique qui en r sulte et qui est illustr en Figure II 4 52 II 2 Extension des RPO Register lt reg INTEGER 0 gt Figure II 4 Place registre et notation abr g e 2 3 R gles d mission Le formalisme utilis dans la m thode Merise Tardieu 83 pour d crire la dynamique des processus utilise le m canisme de r gles d mission pour exprimer le fait qu une op ration ne se termine pas toujours de la m me mani re mais peut fournir des r sultats diff rents en fonction des valeurs avec lesquelles elle est franchie D finition IL 28 R gle d mission On appelle r gle d mission une place p P telle que p La place n a qu une transition d entr e Vtep t p A P Pr cond t TRUE la disjonction des
186. hissable Une clarification de vocabulaire s impose ici Il ne faut pas confondre les pr conditions de Eiffel ou des TAD avec les pr conditions que l on associe aux transitions des RPO e Dans Eiffel une pr condition est une expression bool enne portant sur param tres d entr e du service et des attributs de l objet serveur qui d finit les conditions pour qu une invocation soit correcte ou l gale Une invocation avec une pr condition non v rifi e est une erreur et ne devrait jamais se produire dans un syst me correct Si une telle erreur se produit effectivement ce ne peut tre que par suite d une erreur de programmation qui doit provoquer l arr t du programme e La signification d une pr condition d une transition d un RPO est toute autre elle sert uniquement choisir les entit s avec lesquelles une transition peut tre franchie lever des conflits effectifs II 2 1 entre transitions On pourrait toutefois envisager de faire jouer aux pr conditions d un RPO le m me r le que les pr conditions de Eiffel dans un cas bien pr cis le cas d une pr condition sur une transition d accord et qui porte uniquement sur les param tres d entr e du service e Avec la s mantique normale des pr conditions dans les RPO si une telle pr condition n est pas v rifi e le franchissement de la transition d accord ne pourra jamais avoir lieu et le client restera pour toujours en attente de l ex cution de sa requ
187. hode se combine avec l aspect par ailleurs fortement typ du langage Eiffel Un des aspects int ressants de l approche est la diff rence m thodologique qui est faite entre objets actifs les processus qui ex cutent leur op ration Live et objets passifs qui comme leur nom l indique attendent passivement d tre invoqu s L auteur souligne que le probl me potentiel d une telle approche est le partage d une entit passive par plusieurs entit s actives qui donne lieu aux probl mes d crits au 1 2 c La solution choisie pour r soudre ces probl mes est d interdire totalement un tel partage en se passant les param tres qui d notent des objets passifs par copie D autres postulats qui sont la base de l approche nous semblent poser de s rieux probl mes e L auteur pr suppose qu un processus qui n est pas accessible i e pour lequel aucun autre processus ne poss de de r f rence peut tre termin Ceci semble faux Outre le cas trivial du processus racine du syst me qui ne doit pas tre termin abruptement il faut consid rer le cas d un processus qui contr le la terminaison correcte d un ensemble d autres processus et qui ne doit pas tre interrompu avant d avoir achev sa t che Un processus non accessible peut cependant faire quelque chose d utile un exemple simple serait une horloge qui affiche l heure en haut et droite de l cran En toute g n ralit il faut envisager et d finir la s ma
188. i re entre le syst me mod lis et son environnement De m me objets sous syst mes et syst mes peuvent tre mod lis s de la m me fa on e La s mantique du formalisme est d finie formellement ce qui n est pas le cas pour tous les langages objets et moins encore pour les LOO concurrents en utilisant les R seaux de Petri l une des trois th ories math matiques reconnues pour l expression de la concurrence 233 Conclusion e Le formalisme peut tre ex cut par semi compilation ou interpr tation de mani re r partie e Enfin l utilisation des RdP permet d effectuer des analyses statiques des propri t s des mod les produits Formalisme de mod lisation ou langage de programmation Doit on situer les Objets Coop ratifs comme un formalisme de mod lisation des syst mes pour en sp cifier et ou en concevoir le fonctionnement ou comme un langage de programmation pour en implanter les fonctionnalit s En temps que formalisme de mod lisation les Objets Coop ratifs prennent en compte les aspects fonctionnels ce que fait un syst me et structurels comment il est fait Le formalisme traite notamment les aspects li s au comportement la communication entre les composants et avec l environnement au parall lisme au s quencement et la dur e des op rations e Les Objets Coop ratifs disposent des m canismes indispensables pour permettre l intelligibilit du mod le d un syst me com
189. i r sultant de la modification e Apr s quelques actions d dition successives il pourra choisir de Remplacer transition T5 le n uplet courant par celui qu il a diter d Ajouter transition T6 un nouveau n uplet avec les nouvelles valeurs d attribut ou de R tablir transition T7 les valeurs initiales du n uplet Apr s quelques it rations de ce processus de modification et d ajout de n uplets on se retrouve dans l tat illustr par la figure VII 23 la place Liste contient un certain nombre de jetons de type lt n_uplet gt les places S lectionn et D faut sont vides et la place Edit contient un jeton indiquant ainsi qu un n uplet est en cours de modification Dans la zone de commande seuls les boutons Remplacer Ajouter et R tablir sont activables car les Transitions de Service auxquelles ils sont reli s TS T6 et T7 respectivement sont franchissables La figure VII 25 montre un message d erreur d clench par l valuation de la pr condition de la transition T6 dans le cas o le n uplet ne v rifie pas les contraintes d int grit La sp cification du dialogue que nous fournissons pr sente par ailleurs certains choix arbitraires qui peuvent tre discutables sur le plan ergonomique Le service Quitter par exemple n est activable que si aucun n uplet n est dit 1 e si le marquage de la place Edit est vide ce qui est sp cifi par l arc 220 VIL2 Interfaces Personne logiciel inhibiteur Il p
190. iblement coupl e afin qu il corresponde effectivement un sous syst me du syst me global On souhaiterait de plus d duire le comportement ou les propri t s du syst me global partir de celles se ses composants Pour que cela soit possible il est n cessaire que le protocole de communication entre les composants soit formellement d fini Ces deux approches ne sont pas mutuellement exclusives et toutes deux sont utiles au concepteur La premi re permet de consid rer un syst me diff rents niveaux d abstraction et est bien adapt e un processus de conception descendant alors que la seconde permet de se concentrer sur diff rentes parties ou fonctions d un syst me et correspond mieux un processus ascendant 73 II 3 Structuration des mod les de R seaux de Petri de Haut Niveau L approche Objet est ce jour la meilleure synth se de ces deux approches ses concepts permettent de consid rer un syst me comme une composition de parties qui sont tout d abord consid r es d un point de vue abstrait Ces parties sont ensuite con ues plus en d tail donnant lieu des sous syst mes sur lesquels il est possible d it rer le m me processus de d composition jusqu ce que l on obtienne le mod le souhait Booch 87 Nous allons dans la suite pr senter trois propositions caract ristiques qui appliquent aux RdP respectivement la d composition hi rarchique la composition par r seaux communicants et la d c
191. ication d une classe d crit un comportement abstrait qui ne fait r f rence aucune autre classe L impl mentation d une classe au contraire fera le plus souvent usage d autres classes qui devront leur tour tre examin es dans le processus de cl ture 10La m thode HOOD est principalement destin e la mod lisation de ce genre de syst me bien que cette restriction ne soit pas explicitement mentionn e dans les documents qui la d crivent 122 IV 1 Syst mes d Objets Coop ratifs System exemple Primitive objects Trois objets primitifs de classes diff rentes Op 1 Classel is Marquage initial de 1 OBCS de Op 1 D fini par l op ration create de la classe create Un param tre r el end Op 1 Op 2 Classe2 is Marquage initial de l OBCS de Op 2 D fini en extension 10 jetons dans une place d sign e de son OBCS Une_Place 10 lt gt end Op 2 Op 3 Classe3 is Marquage initial de l OBCS de Op 3 D fini en combinant les deux m thodes pr c dentes Autre Place 5 lt gt create end Op 3 Classes Liste des classes qui interviennent dans la cl ture de la relation d utilisation en pr cisant si on consid re leur impl mentation ou leur sp cification Classel Implementation Classe2 Specification Classe3 Specification Figure IV 1 Syntaxe de d finition d un syst me d Obj
192. ications entre objets et par l m me la coop ration qui est n cessaire entre l objet d crit et d autres objets du syst me e Elle montre enfin comment est structur le code algorithmique qui doit tre ex cut lors de l appel d un service Comportement et coop ration L activit d un Objet Coop ratif peut avoir trois origines e Il r pond des invocations agissant alors en tant que serveur Il invoque d autres objets se pla ant alors en position de client e Il ex cute des op rations internes agissant sous son propre contr le L ObCS d impl mentation doit d crire ces trois aspects Il est structur comme l ObCS de sp cification mais est plus d taill et contient des informations qui ne sont pas pertinentes pour les clients e R ponse des invocations Comme pour l impl mentation l ObCS d impl mentation d finit la disponibilit des services il d crit en plus tr s pr cis ment le traitement associ e ce service chaque service d fini dans l interface de la classe est associ non plus une ou plusieurs transitions mais des couples de transitions pour lesquels une des transitions comporte en entr e un arc d activation tiquet par les param tres d entr e du service cette transition est appel e transition d accord du service et d finit sous quelle condition une invocation relative ce service peut tre accept e par l objet 105 II 4 Impl mentation d une clas
193. ier gt Lecteurs lt conn Connexion pos Figure 11 12 Impl mentation de la classe Fichier_ prot g L impl mentation introduit un nouvel attribut c_ qui m morise le nombre de lecteurs connect s cet attribut est utile pour d terminer quel moment le Fichier utilis doit tre effectivement ouvert ou 110 II 4 Impl mentation d une classe ferm on n ouvre le fichier que pour la premi re connexion et on ne le ferme qu la d connexion du dernier lecteur s il n y a pas d crivain L enrichissement de la structure de l ObCS n cessite la mise jour de l op ration Create cette op ration initialise maintenant l attribut c_ z ro et cr e l instance de Fichier qui sera utilis e dans les TI On peut examiner de plus pr s les OpCS de quelques op rations qui sont caract ristiques des structures de contr le internes associ es aux services L op ration Ouvrir en_ criture effectue un test d crit par une r gle d mission sur l attribut c 1 afin de d terminer si le Fichier doit tre ouvert Elle g n re un nouvel identifieur de connexion forc ment unique car il s agit d un nouveau nom d objet qui est renvoy au client L OpCS d crit pr cis ment l effet de bord de l ex cution du service sur l objet serveur le jeton de classe Fichier manipul passe de la place Pas_d crivain la place Ecrivain lt f gt lt conn 0 f gt conn Connexi
194. ifs d utiliser le m me objet passif mais ne sp cifie pas non plus la s mantique d une telle construction qui correspond une donn e partag e entre plusieurs processus 3 3 La relation d inclusion La relation d inclusion est le m canisme propos par HOOD afin de permettre une d composition hi rarchique descendante top down du probl me Un objet parent est alors d compos en un ensemble d objets enfants qui offrent collectivement la m me fonctionnalit que le parent Ce processus de d composition peut alors tre appliqu r cursivement chacun des enfants Une correspondance doit tre donn e entre les op rations offertes par l objet parent et celles offertes par ses enfants Cette correspondance est forc ment fonctionnelle 1 1 Si une op ration du parent est impl ment e par plusieurs op rations des enfants correspondance 1 n un objet enfant d di OP_ Control object doit tre introduit pour assurer cette correspondance L objet OP_ Control est un objet terminal dont le corps se limite l OpCS de l op ration qu il contr le Un objet HOOD non terminal n a pas d l ment qui lui soit propre mais n est constitu que par les d clarations de ses enfants et des indirections des services qu il offre vers ceux ci Les interactions entre flots de contr le sont d crites dans l ObCS de l objet parent Au niveau des enfants cet ObCS peut tre impl ment Par un enfant d di forc ment actif
195. illustr en Figure II 18 Pour que le motif fonctionne comme attendu il suffit que la place Sommet soit initialement marqu e avec un nom d objet quelconque Comme pr c demment nous illustrons l volution des marquages en supposant le m me ordre d arriv e des jetons Exemple Type Any Personne Mathieu Marc Luc Jean Places Sommet lt a ANY gt Pile lt p Personne devant ANY derri re ANY gt Empiler lt avant gt lt xX gt Figure IL 18 Un motif se comportant comme une Pile 66 II 2 Extension des RPO Marquage atteint Empiler lt Mathieu ANY 1 ANY 2 gt lt Mathieu gt lt ANY 1 gt lt ANY 2 gt Empiler lt ANY 3 gt hieu lt Marc gt lt ANY 4 gt NY 5 gt A A w o K ct Q gt Z K pa N gt D Pz K N w V S A un Noe D D D Z Dp pP Zp Pez ZKIZZKIZZZKIZZK ZK K J KHIK KK A N V Empiler lt Luc gt Empiler lt A lt Jean gt D piler lt ANY 4 gt athieu ANY 1 A 2 gt lt Jean gt arc A 2 3 gt Luc A 3 4 gt D piler lt ANY 3 gt hieu gt lt Luc gt arc Figure IL 19 Evolution des marquages pour le motif Pile lt D W VV w K at ar lt Luc at ar A AIA AAA Q D Z ZK ZZZK ZZK ZK A KAIK KHHKK A A ZK Une place g r e en pile sera not e par le mot clef hard LIFO c Place tri e Pour exprimer qu une place p
196. inition 11 34 Franchissabilit dans un RPO arcs inhibiteurs cccecccecceeceeseeeteeseeteenseenees 68 D finition II 35 Crit re d tr d une place nn nn ete nine 70 D finition 11 36 Place tri es ne ee A ee le TA Rte ee ST ne a 71 D finition 11 37 Places tri es et franchissabilit 72 Chapitre Ill D finition des classes d Objets Cooperatifs D finition III 1 Sp cification d une classe d Objets Coop ratifs ccceccsseeseceseeseeerseeseeseeeeeeees 113 D finition II 2 R gle d volution d un ODCS siens 114 D finition III 3 Relation d utilisation ss 129 Chapitre IV Syst mes d Objets Coop ratifs et organisation des classes D finition IV 1 H ritage et structure de donn es en iono nor E E E ORE 142 D finition IV 2 D EAA S 2 E A lene ee 142 D finition IV 3 H ritage multiple et renommage des services ccecsesceesseeeeeeeeeeceeeeeeeesseeeeeees 143 D finition IV 4 Crit re de non duplication a 154 Chapitre VI Extension du formalisme D finition VI I Services Data ElGWt nel en M hee Pd SE ht dae 198 Chapitre IX Analyse d un mod le d Objets Coop ratifs D finition IX 1 S quences franchissables de transitions csscceseceeeeseeeseeeeeeeeeseeeseeeeeeeeeneeees 244 D finition IX 2 Critere d honn tet 2224 ARR Rae Mn ee SUN den rites 245 D finition IX 3 Crit re deCo
197. intes que nous donnons ne sont pas d finies au niveau du WSCS mais au niveau des ObCS des objets eux m mes en accord avec la s mantique intuitive de leur ObCS d crite en III et ne sont pas li es la structure des communications entre objets Ces contraintes peuvent de la sorte tre v rifi es d s la conception de la classe sans r f rence aux syst mes dans lesquels la classe est susceptible d tre utilis e La formulation de ces contraintes fait r f rence aux RPO des classes c est dire leur ObCS amput de la fonction de disponibilit Disp 1I1 3 6 qui d finit l association entre services offerts et transitions de service TS du RPO De m me les Transitions d Invocation TI sont consid r es comme des transitions ordinaires et les objets serveurs sont suppos s ne jamais soulever de probl me Cette formulation a donc pour cons quence que la valeur des param tres fournis par les clients aux TS ne peuvent pas tre pris en compte ni la valeur des param tres de sortie des services invoqu s De plus toutes les instances d une classe ont la m me distribution initiale de jetons mais avec des valeurs initiales diff rentes Ainsi pour que les contraintes soient significatives pour toute instance elles doivent tre d finies sans r f rence aux valeurs des jetons et les pr conditions et actions des transitions sont donc ignor es les r seaux sont examin s au second niveau du II 1 3 1 DEFINITIONS PR
198. invocation des services publi s par sa classe La r gle respecter pour l volution des services correspond la contrainte de sous typage d crite par America 87 que nous rappelons ici D finition IV 2 H ritage et services Si Cs est une classe d riv e de Cg alors pour tout service S P1 typeCg1 Pi tyPeCgi Pn tyPeCgn type_r sultatCg export par Cg alors Cs poss de un service de m me nom S p1 typecs1 Pi typeCsi Pn typeCsn type_r sultatcs tel que Vie 1 n typeCgi est un sous type de typeCsi et type_r sultatc est un sous type de type_r sultatCg Une classe d riv e peut donc rajouter de nouveaux services ou accepter des param tres plus g n raux dans les services dont elle h rite On ne donnera la signature d un service h rit dans une classe d riv e que si cette signature volue cette volution devant respecter la r gle ci dessus c H ritage et comportement Dans Eiffel la pragmatique d une classe est d finie formellement par des pre et post conditions portant sur les services et par des invariants maintenus par la classe des r gles pr cises d finissent comment ces clauses peuvent tre modifi es au sein de la hi rarchie d h ritage afin qu une classe d riv e puisse effectivement tre consid r e comme une sp cialisation de ses anc tres Nous les avons rappel es au chapitre I D finition I 3 Pr servation de la s mantique
199. ion Entree_il t Cellule gt fit partiecds CS classe d objets composites gt h rite de E classe d objets l mentaires Figure VII 6 Graphes d h ritage et de composition a La classe Palette Une palette portant toujours un et un seul produit il n est pas utile d introduire une classe Produits La classe Palette est une classe d objets passifs elle ne publie que des data flows et a donc un ObCS trivial et se ram ne une structure de donn e elle m morise l tat courant du produit en cours de fabrication et permet de faire voluer cet tat par l interm diaire du service process Les gammes de fabrication sont ici tr s simples une s quence fixe d op rations sans alternative On pourrait tr s bien envisager de mod liser des gammes plus complexes par un RdP qui en l occurrence servirait d ObCS la classe Palette 196 VIL 1 Mod lisation d un atelier flexible Class implementation Palette Types Op rations Al A2 A3 A4 Bl B2 B3 B4 Gamme array 0 3 of Op rations Constants GammeA Gamme Al A2 A3 A4 GammeB Gamme Bl B2 B3 B4 GammeC Gamme Cl C2 C3 C4 Attributes priv s gamme Gamme oper 0 3 Data Flows publics Op ration_suivante Op ration is do result gamme oper end LA LA process is do la derni re op ration d une gamme correspond au d chargement du produit et la r initialisation de la palette oper o
200. ipale des moniteurs appara t alors clairement il s agit d un m canisme structurant qui permet d encapsuler et de rationaliser l utilisation des s maphores dont l utilisation anarchique pouvait rendre la maintenance des syst mes concurrents extr mement difficile tout comme l utilisation du GOTO rend illisible les programmes s quentiels La s mantique ex cutoire des moniteurs est malheureusement rendue complexe en raison des axiomes relatifs l ex cution des primitives e Les proc dures d un moniteur s ex cutent en exclusion mutuelle la cons quence implicite de cet axiome peu souvent mentionn e est qu il doit exister une file d attente globale pour le moniteur des processus en attente d une proc dure e Un processus r veill par c signaler reprend son ex cution l instruction qui suit imm diatement la primitive c attendre qui l a bloqu La n cessit d exclusion mutuelle entre les op rations d un moniteur impose une contrainte suppl mentaire sur le m canisme de r veil lorsqu un processus p r veille un processus q p et q ne peuvent tre maintenus simultan ment actifs On impose donc p de se bloquer jusqu ce que g se bloque lui m me ou sorte du moniteur Pour viter le blocage ind fini de p il faut en plus imposer que le transfert de contr le de p q soit ininterruptible et garantir qu un processus temporairement bloqu par l op ration signaler soit r veill avant qu un nouveau process
201. ique d un mod le Laboratoire d accueil LIS Universit Toulouse I Place Anatole France 31042 Toulouse Cedex Introduction e Le chapitre VII pr sente une tude portant sur la mod lisation d un atelier flexible de production VII 1 et une autre portant sur la conception d une interface personne logiciel VIL2 e Le chapitre VIII est consacr aux possibilit s d ex cution r partie du mod le et montre comment un syst me peut tre ex cut au niveau de chaque objet de chaque classe d objets ou du syst me dans son ensemble e Le chapitre IX d crit quelques unes des possibilit s d analyse statique des mod les qui d coulent de l utilisation des RPO pour sp cifier la dynamique des Objets Coop ratifs Laboratoire d accueil LIS Universit Toulouse I Place Anatole France 31042 Toulouse Cedex PARTIE I OBJETS ET RESEAUX DE PETRI POUR LA MODELISATION DES SYSTEMES CONCURRENTS Chapitre I Mod lisation par objets des syst mes concurrents Une brique de verre servirait de cendrier Une bo te ronde en cuir noir d cor e d arabesques l or Jin serait remplie de cigarettes La lumi re viendrait d une vieille lampe de bureau malais ment orientable garnie d un abat jour d opaline verte en forme de visi re De chaque c t de la table se faisant presque face il y aurait deux fauteuils de bois et de cuir hauts dossiers Plus gauche encore le long du mur une table troite d borderait
202. ique d une invocation non confirm e 0 0 ee eeeeeeeeeeeteeeeeeeeeeeeeeees 188 S mantique d une invocation non confirm e 189 Syntaxe d une invocation gard e 190 S mantique d une invocation gard e cccceccceescesseesceeeceeeceeeceeceseessecseeeseeeaeeaes 191 Exemples de la syntaxe d invocations gard es cccccesceeseceseeteceeeeeseeneeeneeeneenes 194 Invocation d un service prioris ceeceseceeesceesseeseeeseeeeceeeeseceseceaecesecseeseeeneeses 195 WSCS d ns rvice LIFO it EAU au AR A ie Aled ne 196 Sp cification et s mantique d un service de mise jour 197 Classe Cserveur publiant un data flow 198 ObCS d extension de Cserveur i i a a aa 199 WSCS g n r par l invocation d un data flow 200 Chapitre VII Etudes de cas Figure VII 1 Figure VII 2 Figure VII 3 Figure VII 4 Figure VILS Figure VII 6 Figure VII 7 Figure VII 8 Figure VII 9 Figure VII 10 Plan g n ral de l atelier nan einen 206 Architecture d une cellule de production 208 Fonctionnement d une cellule de production 209 Param tres des composants de l atelier cccesceesecsceesceeseeeseeeeeeeeeeeeeeesenseenseens 210 Liste des op rations par poste 210 Graphes d h ritage et de composition 212 Laclass Palette nuci nn sise nn ner RE anise 213 Classe composite Atelier
203. ires Le concepteur doit s attacher minimiser de tels cas 2 2 Programmation par v nements Il est tr s clairant de comparer l organigramme d une application conventionnelle pilot e par menus par exemple avec celui d une application pilot e par v nements Figure VII 21 Lire une yE Effectuer un traitement Figure VII 21 Structure de contr le d une application interactive conventionnelle e L application conventionnelle une structure de syst me transformationnel r cursif Acquisition des donn es Traitement de ces donn es et Sortie du r sultat o la partie Traitement peut elle m me invoquer r cursivement la m me structure 212 Etat du dialogue VIL2 Interfaces Personne logiciel Enregistrer les Invoquer la boucle principale du gestionnaire Invoquer le traite v nements appropri Figure VII 22 Structure de contr le d une application dirig e par v nements A l inverse l application pilot e par v nements pr sente une structure plat et consiste seulement en un ensemble de proc dure de gestion d v nements event handlers ou traite v nements qui ne s invoquent pas mutuellement Un module d di le gestionnaire d v nements conceptuellement ext rieur l application elle m me g re une file d attente d v nements et assure leur interpr tation en les ventilant vers le traite v nements qu ils concernent Dans la plupart des sy
204. is s par une grande dynamicit les acteurs sont cr s en grand nombre et souvent avec une dur e de vie tr s courte le calcul d une factorielle par acteurs par exemple cr erait un acteur pour g rer chaque tape de multiplication 28 29 Cette grande dynamicit a conduit plusieurs auteurs proposer des solutions pour ma triser la complexit de la relation d utilisation entre les acteurs e Kaplan 89 d crit la relation d utilisation entre les acteurs par un graphe et utilise les graph grammars pour sp cifier les changements possibles de la topologie de ce graphe Engelfriet 90 d crit l volution d un syst me d acteurs par un r seau de Petri qui sp cifie les cr ations les destructions et l volution des r f rences entre acteurs L analyse de ce r seau permet de d tecter par exemple les cas de r f rence pendante ou un acteur garde une r f rence vers un autre acteur mort Stefik 86 souligne que les langages d acteurs ont besoin des concepts structurants de classe et d h ritage en pratique ces langages disposent de clich s de programmation qui mulent les formes habituelles d h ritage emprunt es aux langages objet plus conventionnels 29 3 LA METHODE HOOD HOOD Hierarchical Object Oriented Design est une m thode de conception architecturale con ue en premier lieu pour du logiciel destin tre d velopp en Ada Les fondements de la m thode HOO
205. is une architecture pratiquement identique ceci s explique par leur origine commune qui remonte aux premiers travaux effectu s par l quipe d Allan Kay et Adele Goldberg autour du langage Smalltalk Goldberg 83 Les caract ristiques principales des UIMS sont les suivantes e Orientation Objet Les diff rents l ments de l interface fen tre menus boutons sont d crits en termes d Objets Window Objects ou widgets avec un comportement minimal par d faut Le programmeur est alors libre de les surcharger par h ritage ou par manipulation de pointeurs de fonctions dans les langages qui n int grent pas l h ritage tels que C e Programmation par v nements Les interfaces produites par de tels environnements sont des syst mes r actifs par opposition aux syst mes transformationnels Pnueli 86 ils sont passifs par rapport leur environnement et r agissent aux stimuli qu ils en re oivent en d clenchant des op rations internes En r gle g n rale le contr le de l application est externe c est dire que l application ne d finit pas ses propres encha nements de proc dures mais se contente de r pondre aux invocations qu elle re oit De m me l application ne r clame jamais de donn e l utilisateur ce qui l entra nerait dans un dialogue bloquant sauf dans des cas o 211 VIL2 Interfaces Personne logiciel une confirmation imp rative ou un param tre suppl mentaire sont absolument n cessa
206. iste consid rer l environnement comme un client du syst me Certains objets primitifs peuvent tre d sign s pour assurer l interface du syst me avec son environnement il faut alors sp cifier quels sont parmi les services d finis par leur classe ceux qui sont susceptibles d tre invoqu s par l environnement Ces services sont d sign s sous le nom de services d interface L interaction entre le syst me et son environnement provoque alors une action sur la structure de contr le du syst me l environnement peut initier des flots de contr le en invoquant les services d interface Dans un syst me r el les services d interface serviraient mod liser des p riph riques physiques g n rateurs d interruptions tels que capteurs clavier dispositifs de pointage etc Dans une optique de simulation ou de test on peut d finir avec cette approche un sc nario d interactions qui sp cifie quels services d interface vont tre invoqu s et quels seront les valeurs des param tres re us par ces services La deuxi me approche consiste consid rer l environnement comme un serveur du syst me ceci peut tre fait de deux mani res L environnement peut tre d fini par un ensemble de primitives et l interaction s effectue dans le code des op rations internes des classes par appel de ces primitives Dans l impl mentation de la classe Fichier d crite en III 4 4 l environnement est le syst me d exploitation qui four
207. itif Place d attente Place param tre Place r sultat D crit le comportement externe d un objet tel qu il est per u par ses clients Il sp cifie le mode d emploi de l objet les s quences ex cutables d activation de ses services Objet dont la classe poss de un ObCS qui contraint l activation des services qu il offre Objet dont la classe ne publie que des Data Flows Un objets passif poss de un ObCS trivial Objet qui pr existe l initialisation d un Syst me d Objets Coop ratifs Place introduite lors de la construction du WSCS Pour chaque TI une place d attente se trouve en sortie de la transition d appel et en entr e de la transition de compl tion Elle est marqu e si une invocation du service est en cours Son marquage est la concat nation des variables d entr e de la TI avec l estampille d appel Place introduite lors de la construction du WSCS Pour chaque TI une place param tre se trouve en sortie de la transition d appel et en entr e de la transition d accord Elle contient les param tres de l invocation et l estampille d appel Place introduite lors de la construction du WSCS Pour chaque TI une place r sultat se trouve en sortie de la transition de retour et en entr e de la transition de completion Elle contient les r sultats de l invocation et l estampille d appel 238 Glossaire Propri t Attribut de type simple ou de type construit Les propri t s sont manipul es par valeur Voir
208. ition II 5 Suites finies d l ments Soit E un ensemble L ensemble des suites finies d l ments de E not E se d finit par N pn E SNNET Les l ments de E sont appel s n uplets et not s lt e j gt avec n N eje E De plus on a B lt gt E E D finition II 6 Concat nation de n uplets La concat nation de n uplets not e o est d finie par r currence sur E 1 xe E gt X0OS X 2 xe E ye E gt xoy lt X 0065 Xp Y gt o est associative et poss de un l ment neutre not Ops lt gt Ainsi d fini E o est le monoide libre sur E D finition II 7 Longueur d un n uplet A 2 La fonction longueur est d finie sur E par r currence longueur E N 1 longueur Ops 0 2 xe E ye E longueur xoy longueur x 1 D finition II 8 Multiensemble de suites finies Soit E un ensemble De m me que dans la d finition 3 on d finit l ensemble des multiensembles de suites finies de E not Z Z f E gt Z f de support fini fe Z E si f Erreur Exemples Soit E x y z un ensemble On a x 2 ye Z E lt x y gt E lt x gt 2 lt x y gt E Soit a et b e Z E avec a lt x gt 2 lt y gt et b lt y gt 3 lt z gt Les op rations d finies ci dessus sont utilis es ainsi a b lt x gt 2 lt y gt lt y gt 3 lt 7 gt lt x gt 3 lt y gt 3 lt
209. iture consomme le jeton pr sent dans la place Pas_d ne clipes qui emp che tout d clenchement ult rieur des transitions Ouvrir _en_lecture et Lire On remarque galement que le service Aller_en pour un lecteur peut tre ex cut concurremment avec d autres services accept s par l objet par exemple Ecrire 97 II 3 Sp cification d une classe Class Specification Fichier prot g Services Ouvrir en_lecture lt conn Connexion gt Ouvrir en criture lt conn Connexion gt Fermer lt conn Connexion gt Position lt conn Connexion gt lt pos INTEGER gt Aller_en lt conn Connexion position INTEGER gt Ecrire lt conn Connexion quoi STRING gt Lire lt conn Connexion combien INTEGER gt lt chaine STRING gt Create lt nom STRING gt is Pas_d crivain lt gt end Pas_d crivain lt gt Lecteurs Ecrivain lt c Connexion gt Ouvrir_en_lecture Ouvrir_en_ criture Ly lt conn gt lt conin 0 gt lt conn combien gt lt conn chaine gt lt conn pos gt lt conn pos Eee re chaine lt conn pd lt gt lt conn pos gt CORIN lt conn pos gt Figure IIL 7 Sp cification de la classe Fichier_prot g 3 5 Interpr tation de l ObCS de sp cification L activit d un objet consiste ex cuter son ObCS un service offert par l objet s ex cute lorsque une des transitions associ e ce service est franchie L ObCS d une
210. jet d not par ma_file est partag par d autres objets c est dire si d autres objets poss dent eux aussi des r f rences vers l objet d not par ma _ file En effet entre l valuation du pr dicat ma_file vide et l appel ma_file d filer l objet partag peut servir un nombre quelconque d invocations pouvant notamment le rendre vide Meyer propose donc de modifier la s mantique des pr conditions dans le cadre de la programmation concurrente une pr condition de la forme require not vide s interpr te comme une condition d attente sp cifiant ainsi que l invocation est bloqu e jusqu ce que la pr condition devienne vraie par suite de l ex cution par l objet serveur de services r clam s par d autres clients Meyer souligne que Jes objets apparaissent alors plus proche des moniteurs que des processus en effet la s mantique des pr conditions d attente est exactement celle de la primitive d attente propos e par Kessels 77 en r ponse aux probl mes soulev s par la primitive signal des moniteurs cf 1 2 1 Une des cons quences de ce nouveau mod le concurrent du contrat est que l ex cution d un service n est pas interruptible en effet on rappelle que l invariant d une classe doit tre v rifi avant et apr s l ex cution de chaque service et que la pr resp post condition de chaque service doit tre v rifi e avant resp apr s son ex cution Au cours de l ex cution d un service invari
211. jets tant d crit par sa classe et son tat initial qui comprend notamment la valeur de ses r f rences e l ensemble des services ou des attributs qu elle publie Une fonction de traduction qui d finit comment une requ te sur un service ou un attribut publi par la classe compos e doit tre traduite en requ te sur un des composants 132 IV 3 Hi rarchie de composition Compound Class Implementation Composite Exemple Attributes Les seuls attributs d une classe composite sont des r f rences vers les objets composants Cl Classel C2 C3 Classe2 Translation Fonction de traduction Renommage des attributs offerts en attributs d instances composantes attl Cl attcl Renommage des services Svl lt P1 Typel gt C1 Svx Sv2 lt P2 Type2 gt lt R Type3 gt C3 SvyY Instanciation des composants Create P4 Type4 is 1 Cr ation des instances composantes Cl Classel create P4 C2 Classe2 create C3 Classe3 create Initialisation des instances composants Sfinit les relations d utilisation refl1l C2 ref2 C373 ref2 C2 Figure IV 4 D finition textuelle de l impl mentation de la classe Composite_Exemple L impl mentation d une classe composite peut tre d crite de mani re textuelle ou de mani re graphique On pr f rera la description graphique qui met en valeur la structure du graphe de la rela
212. jets par la notion de classe d objets composites ou plus simplement classe composite Stefik 86 La composition introduit la relation est une partie de entre classes ou plus pr cis ment la relation inverse a une partie puisque la partie n a pas n cessairement connaissance de son tout Blake 87 Cette possibilit va nous permettre d examiner un syst me complexe diff rents niveaux d abstraction et non pas directement au niveau des objets atomiques qui le composent ou de d finir r cursivement un objet composite en termes d objets plus simples jusqu atteindre le niveau des objets atomiques La notion d objet composite est tr s proche de la notion d objets parents enfants ou relation d inclusion dans la m thode HOOD la d finition que nous allons en donner reste compatible avec 129 IV 3 Hi rarchie de composition celle donn e par HOOD cf 1 3 et un arbre de conception HOOD aura une traduction directe en termes d Objets Coop ratifs composites Un ensemble d objets donne lieu une entit composite si cet ensemble constitue un sous syst me d objets fortement coupl ou selon Stefik 86 un groupe d objets interconnect s qui sont instanci s ensemble une extension r cursive de la notion d objet Un composite est d fini par un moule template qui d crit ses sous objets et leurs connexions On peut caract riser un tel sous syst me par les propri t s suivantes Il est constitu de
213. l invocation par le serveur et non pas sur la fourniture des r sultats Toutefois l OpCS d un service peut tre d fini de telle sorte que l ordre de fourniture des r sultats soit le m me que celui de la prise en compte 177 VI 2 Ordonnancement des invocations Class Client Class Serveur Services ObCS Sl lt param INTEGER gt lt retour INTEGER gt Hard L PO Pl lt i INTEGER gt P2 lt a Serveur gt P3 lt a Serveur c Intege ObCS PX lt x INTEGER gt PY lt x y INTEGER gt Ge lt param gt lt param xp END S1 retour f param x lt retour Figure VI 6 Invocation d un service ordonnanc A titre d exemple nous illustrons comment une TI r f ren ant un service g r en pile LIFO doit tre tendue par le proc d de construction du WSCS On peut v rifier que le service est bien g r en pile au niveau de chaque instance de la classe serveur et non pas au niveau de la classe elle m me L ordre de traitement entre les diff rentes instances de la m me classe demeure ind terministe La figure VI 6 montre des extraits des ObCS du client et du serveur La figure VI 7 montre le WSCS g n r par les extraits correspondants Il faut remarquer comment le marquage de la place Sommet est initialis chaque instanciation de la classe Serveur par occurrence de la transition Create 178 VI
214. la transition T4 peut concerner indiff remment une instance de ServeurG ou Serveurs Par contre elles n illustrent pas l acc s aux attributs priv s dans l ObCS d un objet ni l acc s des attributs publics par des objets clients Ces cas seront trait s par de petits exemples ad hoc au cours de la discussion Le traitement des classes composites quant lui est expos en V 6 System exemple Primitive objects Deux objets primitifs Pclient t Pclient Pclient Pclient 1 Pclient is Marquage initial de l ObCS de Pclient quelques jetons dans la place Pl Pl lt 4 gt lt 5 gt lt 12 gt end Pclient l1 Pclient 2 Pclient is Marquage initial de l ObCS de Pclient Pl 2 lt 1 gt lt 12 gt end Pclient 2 Classes Liste des classes qui interviennent dans la cl ture de la relation d utilisation en pr cisant si on consid re leur impl mentation ou leur sp cification Pclient Implementation ServeurG Implementation serveurs Figure V 5 D finition du syst me exemple On s est dispens de d finir un op ration Create pour la classe Pclient en effet l tat initial de notre syst me consiste simplement en deux instances de PClient et aucune op ration de cr ation dynamique n intervient sur cette classe Dans notre exemple les deux objets primitifs re oivent chacun un marquage initial consistant en quelques jetons
215. le les objets externes ne peuvent pas acc der e L interface d finit les op rations fournies et requises par l objet ainsi que les types param tres et exceptions associ s e Le corps constitue l impl mentation de l interface fournie en utilisant des op rations des donn es ou des objets internes Le corps mod lise donc la structure interne de l objet Le corps d un objet est d crit par les composantes suivantes Un OpCS Operation Control Structure pour chaque op ration L OpCS d crit le flot de contr le interne associ l ex cution de l op ration par exemple de mani re algorithmique Un ObCS Object Control Structure global l objet qui d crit les interactions possibles entre ex cutions d op rations Dans la Figure I 6 Vielcanet 89 cet ObCS correspond la bo te centrale Interactions de contr le Les relations d inclusion et d utilisation que nous d crivons ci apr s 31 1 3 La m thode HOOD Interface Interactions de Interface offerte requise entrants sortants de l objet internes Figure 1 6 Dynamique des objets actifs HOOD La communication entre un objet client et un objet serveur2 est accomplie par l ex cution d une op ration appartenant l objet serveur La s mantique de cette communication d finie par l op ration appel e peut tre d finie de deux mani res e Dans une op ration s quentielle le flot de contr le appelant est transf r dans le co
216. le serveur ex cute le service comme dans un simple rendez vous Le d lai de garde expire avant que la transition d accord ne devienne franchissable L invocation est alors annul e et la variable locale timeout est mise VRAI Les r sultats de l invocation sont alors ind finis Une r gle d mission cf II 2 3 est toujours associ e aux invocations par rendez vous gard afin de d finir quelles sont les actions effectuer par le client en cas de timeout Figure VI 3 b lt a END Service retour f param x lt retour Figure VI 3 Syntaxe d une invocation gard e Ce type d invocation doit tre pris en compte lors des tapes 5 et 6 de la construction du WSCS e Apres l tape 5 il existe pour chaque service une seule place param tre et une seule place r sultat provenant de la fusion des places param tres et r sultat pour toute la hi rarchie d h ritage Si il existe dans le syst me une invocation gard e de ce service on connecte la place 173 VII Modes d invocation des services param tre et la place r sultat par l interm diaire d une transition d annulation dont l occurrence a pour effet de court circuiter le traitement normal associ au service Le type de la place param tre est tendu par l adjonction d un l ment d notant le d lai associ l invocation On utilise pour d crire la temporisation la notation des RdP arcs temporels Bastide 89 cf
217. li par la classe d un autre objet de la forme variable attribut soit dans sa pr condition soit dans son action soit dans le code d une op ration interne qu elle appelle TI Transition d Invocation transition dont l action est une invocation de la forme lt r sultat gt variable service lt liste de param tres gt Transition d Acc s voir TA Transition d accord Dans l ObCS d impl mentation transition dont la franchissabilit d finit sous quelle condition une requ te de service peut tre accept e par l objet en fonction du marquage de son ObCS Peut tre confondue avec la transition de retour Transition d appel Transition introduite lors de la construction du WSCS Toute TI est clat e en une transition d appel et une transition de compl tion connect es par une place d attente Transition d instanciation Transition introduite lors de la construction du WSCS pour mod liser l op ration create Transition d Invocation voir T1 239 Glossaire Transition de compl tion Transition introduite lors de la construction du WSCS Toute TI est clat e en une transition d appel et une transition de compl tion connect es par une place d attente Transition de retour Dans l ObCS d impl mentation transition qui produit dans l un de ses arcs de sortie les valeurs de retour d un service Peut tre confondue avec la Transition d accord Transition de service Transition Priv e Type classe Type const
218. lic d un autre objet e Les Transitions Priv es TP toutes les autres y compris les transitions de retour pr fix es par END qui d notent l ach vement du traitement associ un service La franchissabilit des transitions d un ObCS d impl mentation se d finit comme pour l ObCS de sp cification Les transitions d accord de l ObCS d impl mentation ont la m me r gle de franchissement que les transitions de service de l ObCS de sp cification c est a dire que leur franchissabilit est conditionn e la pr sence d une requ te en attente sur ce service Une TA n est franchissable que si l attribut consid r a t pr c demment initialis b R gle de franchissement concurrent La r gle de franchissement des transitions de l ObCS d impl mentation peut tre pr cis e un objet effectue une seule op ration la fois mais n est pas bloqu dans son volution pendant l ex cution des services qu il r clame d autres objets On doit donc diff rencier dans l ObCS d impl mentation les TI des TA ou des transitions qui ne font appel qu des op rations internes de la classe e Les transitions dont l action ne contient pas d invocation de service sont franchies en exclusion mutuelle Les TI peuvent tre tir es concurremment entre elles ou avec des transitions priv es TP Cette r gle est justifi e par la s mantique d une transition dont l action contient une demande de service Nous allons pour cela p
219. lics Nous verrons en VIII que cet acc s pose galement probl me lorsque on veut r aliser une implantation r partie du mod le ObCS d extension de Cserveuri ObCS d extension de Celient lt a self gt lt attl sel ObCS d extension de Cserveur2 Figure V 13 Implantation des acc s aux attributs dans le WSCS Il n est toutefois pas douteux que l acc s a des attributs d autres objets soit utile dans de nombreux cas de figure Le cas trait ci dessus en est un exemple typique on peut valuer un attribut dans une pr condition en pr servant l atomicit de celle ci ce qui serait impossible si on devait passer par une invocation pour acc der la valeur de l attribut Dans le chapitre VI nous introduisons les notions de services de consultation qui permettent d tendre les possibilit s d acc s aux attributs L tape 6 que nous venons de d crire termine le processus de construction et le WSCS de notre syst me exemple est illustr en Figure V 14 157 V 3 Construction du r seau global Figure V 14 WSCS du syst me exemple 158 4 REGLE DE TIR POUR LE RESEAU GLOBAL La r gle de tir qui doit tre appliqu e au WSCS est la suivante un nombre quelconque de transition peuvent tre tir es au m me instant pourvu que la variable self reste li e des noms d objets diff rents Cette r gle de tir est conforme la s mantique naive des ObCS chapitre IJI qui est que plusieurs objets sont actif
220. lors s exprimer de mani re formelle Meyer 90 D finition I 3 Pr servation de la s mantique Soit s un service export par la classe A et s une surcharge de s dans A descendante de A Pr s la pr condition de s doit tre plus faible ou gale Pr et sa postcondition Posts doit tre plus forte ou gale celle de s soit Pr s gt Pr s et Posts Post gt d signant l implication logique Le Polymorphisme une entit peut faire r f rence pendant l ex cution des entit s de classes diff rentes On parlera alors pour une entit de son type statique c est dire la classe par laquelle elle est d finie et de son type dynamique c est dire la classe de l instance qu elle r f rence pendant l ex cution Cette possibilit est contrainte par la construction suivante e La Coh rence de type une entit de classe A ne peut r f rencer que des entit s qui sont des occurrences des descendants de cette classe 15 I 1 Les fondements de l approche Objet e La Liaison tardive La surcharge permet de fournir plusieurs impl mentations du m me service pour une hi rarchie d h ritage et le polymorphisme autorise une entit r f rencer des occurrences de diff rentes classes il est donc n cessaire d avoir un m canisme qui permette pendant l ex cution de choisir l impl mentation correcte du service appeler en fonction de la classe de l objet serveur Ce m canisme est conn
221. ltalk in Yonezawa 87 YONEZAWA A MATSUDA H SHIBAYAMA E An Approach to Object Oriented Concurrent Programming A language ABCL in BI GL 48 pp 125 134 YONEZAWA A TOKORO M eds Concurrent Object Oriented Programming MIT Press Cambridge Mass USA 1987 253 Table des definitions Chapitre concurrents D finition I 1 D finition I 2 D finition I 3 D finition I 4 D finition I 5 D finition I 6 Chapitre D finition II 1 D finition II 2 D finition II 3 D finition II 4 D finition II 5 D finition II 6 D finition II 7 D finition II 8 D finition II 9 D finition II 10 D finition IT 11 D finition II 12 D finition II 13 D finition II 14 D finition IT 15 D finition II 16 D finition II 17 D finition II 18 D finition II 19 D finition II 20 D finition IT 21 D finition II 22 D finition II 23 D finition 11 24 D finition II 25 D finition 1 26 D finition 11 27 D finition II 28 D finition II 29 Mod lisation par Objet et Classe d Objets objets des syst mes SOUS LYP A rene Are ne rite bess E S E EE nee trs Pr servation de la s mantique Monite 55 RE en N Bei E Conditions d un moniteur Axiome de pr servation de l ordre de transmission Multiensemble Il Les r seaux de Petri de Haut Niveau Addition de deux multiensembles 00 0cccccccceecsccecsssceceesseeecessececssseeceesseeeesssseees Multiplication d un multiense
222. lue en vase clos 123 IV 1 Syst mes d Objets Coop ratifs Dans le domaine des r seaux de Petri on rencontre fr quemment des mod lisations en syst me clos o l environnement est tout simplement ignor un exemple classique d une telle approche est la solution du probl me des philosophes de Dijkstra trait en IV 3 Une autre technique plus r aliste consiste crire un RdP comme un syst me ouvert et sp cifier comment il communique avec son environnement La communication d un RdP avec son environnement peut tre mat rialis e par des transitions sources c est dire des transitions sans arcs d entr e Valette 85 Suivant la d finition usuelle de la franchissabilit dans les RdP ces transitions sont toujours franchissables Pour mod liser l interface avec l environnement on pr f re d finir la franchissabilit des transitions sources d une mani re had hoc par exemple en associant ces transitions une fr quence de tir al atoire ou en les d clenchant lorsqu une condition logique d finie l ext rieur du RdP est v rifi e Cette technique est fr quemment utilis e lorsque les RdP sont utilis s des fins de simulation car elle permet d tudier tr s facilement l influence de l environnement sur le comportement du syst me Techlog 89 Dans le formalisme des Objets Coop ratifs on peut utiliser une version tendue de cetteltechnique avec deux approches La premiere approche cons
223. mble par un scalaire Ordre partiel sur les multiensembles cccceescessceeseesceeeeeeeceeceseensecsseeeenaeenaes Suites finies d l ments Concat nation de n uplets Longueur d un n uplet Multiensemble de suites finies tn Re Rat ann tr Prolongement canonique Prolongement lin aire Support d un multiensemble de n uplets Domaine d un type Valeur d une entit Marquage d un Compatibilit des types R seau de Petri Objets Jetons simples et jetons typ s RPO esos Substitution des variables d une transition ccc cecccceessececeesceeecsseeceessseeeseaeeees Franchissabilit d une transition Entit s cr es par un franchissement Marquage atteint par un franchissement Transitions concurremment franchissables 0 0 ccccccccccsseccceesseeecssceceessseeeessseees Pond ration d un r seau Invariant alg brique Fonction uniforme Conflit structurel et conflit effectif Registres d un RPO R gle d mission Franchissabilit d un RdP priorit s 255 Table des definitions D finition II 30 RPO X priorite Sea rime rien te ll en nt ti de 64 D finition IL 31 Arcs inhibiteurs Hack 751 66 D finition II 32 Arcs inhibiteurs er tt Re RH ON Art Re AR in ee RAS 67 D finition 1 33 RPO Xares MmmMhiteUrs ss RRS a Din AT frire 67 D f
224. ment orient e vers la commande de proc d Les Objets Coop ratifs sont simplement un formalisme ou peut tre un langage de programmation voir ce sujet la conclusion de ce m moire ce titre notre objectif a t de le rendre le plus g n ral possible afin d tendre au maximum son domaine d application Nous avons donn peu d indications m thodologiques consid rant que chaque domaine d application rel ve de sa propre m thode de conception 77 II 3 Structuration des mod les de R seaux de Petri de Haut Niveau HOOD PNO conserve le mod le de structuration de HOOD qui est extr mement statique Nous avons introduit dans les Objets Coop ratifs les constructions dynamiques rencontr es dans la plupart des langages Orient s Objet avec notamment l instanciation dynamique et la relation d utilisation dynamique entre objets Enfin les Objets Coop ratifs int grent compl tement les m canismes li s la classification et l h ritage g rant notamment l h ritage multiple et le polymorphisme concepts qui sont absents de la m thode HOOD Nous pensons que l h ritage lorsqu il a la s mantique d une sp cialisation ou sous typage et non pas d une extension cf I 1 4 est un outil conceptuel extr mement important dans un processus de conception l utilisation de l h ritage en tant que m canisme d extension par contre rel ve essentiellement de l activit de conception d taill e ou de codage 78 II 3
225. mment comment il utilise d autres composants du syst me pour remplir sa fonction La vue interne indique notamment les choix qui ont t faits pour la structure de donn es du composant et pour les algorithmes qui impl mentent ses fonctions ces choix devant autant que possible tre cach s ses utilisateurs Il est essentiel que l impl mentation d un composant respecte sa sp cification la pragmatique d un composant est souvent sp cifi e de mani re informelle e g en langage naturel ou semi formelle e g par des formalismes graphiques Ward 85 Harel 88 Buhr 84 alors que l impl mentation est 12 I 1 Les fondements de l approche Objet limit e au cadre formel d un langage de programmation Le saut de niveau d abstraction tr s important entre ces deux descriptions rend le plus souvent impossible toute v rification de conformit entre la sp cification et l impl mentation de la pragmatique d un composant 1 3 Programmation par contrat Le concept de programmation par contrat est un des apports les plus int ressants du langage Eiffel Meyer 90b Les pr conditions et les postconditions d un service peuvent tre consid r es comme le contrat pass entre le service et ses clients e La pr condition cr e une obligation pour les clients Elle d finit les conditions que doit satisfaire un appel pour tre l gitime Class File export nfile d file plei vide feature enfile x INTEGER is Ajoute x
226. mple caract ristique d un tel syst me topologie statique se trouve au chapitre VII 1 La construction d un syst me d Objets Coop ratifs se fait donc comme suit e 1 tape le concepteur d signe les objets primitifs du syst me instances de classes dont il dispose Il d finit pour ces instances un marquage initial Ce marquage peut tre Le marquage d fini par l op ration Create On peut alors pr ciser les param tres r els fournir cette op ration Un marquage initial arbitraire diff rent de celui d fini par l op ration Create et sp cifi avec la m me syntaxe Une combinaison des deux possibilit pr c dentes un marquage compl mentaire est ajout celui d fini par l op ration Create e 2 tape A partir de l ensemble des objets primitifs on peut d terminer automatiquement l ensemble des classes des instances qui sont susceptibles d tre cr es pendant l volution du syst me il suffit pour cela de construire la cl ture transitive de la relation d utilisation partant de l ensemble des classes des objets primitifs Cependant le concepteur peut intervenir dans la mani re dont cette cl ture est construite pour chaque classe examin e il a le choix entre utiliser son impl mentation ou sa sp cification ces deux descriptions tant galement ex cutables Par d finition la sp cification d une classe est une feuille du graphe de la relation d utilisation un serveur pur la sp cif
227. mplir un ensemble d op rations appartenant aux gammes des palettes qui circulent dans l atelier Les op rations assur es par chaque poste sont list es en Figure VILS ILOT 1 ILOT 2 Op ration I Op ration 2 sur palette Poste 1 Chargement ler chargement ler D chargement de PB composant de PA composant de PC sur palette Al C1 Poste 2 chargement ler Assemblage 2 me Assemblage 3 me composant de PB composant de PC composant de PB sur palette B1 C2 B3 A2 B2 C2 Poste 4 Assemblage 3 me Assemblage 2 me Assemblage 3 me Assemblage 3 me composant de PA composant de PB composant de PC composant de PB A3 B2 C3 B3 Poste 5 D chargement de PA D chargement de PC D chargement de PB A4 C4 B4 Poste 3 Assemblage 2 me Assemblage 2 me Assemblage 2 me composant de PA composant de PB composant de PC Figure VILS Liste des op rations par poste 194 VIL 1 Mod lisation d un atelier flexible L atelier comprend e 50 palettes dans le syst me Au lancement toutes les palettes sont dispos es sur l anneau du distributeur selon un certain ordre D s la mise en production toutes les palettes se meuvent simultan ment e 2 op rations technologiques Op et Op2 par op rateur e 1 op rateur robot par poste de travail e 1 poste de travail par cellule e 5 cellules par lot e 2 flots dans atelier 1 4 Mod lisation de l atelier Nous avons choisi de structurer le syst me de production en
228. mportant comme une file Une place peut mod liser une file d attente une des structures de base de la technique informatique exprimant le fait que les jetons seront captur s lors du franchissement des transitions de sortie dans l ordre o ils ont t d pos s dans la place par les transitions d entr e On connait ce mode de gestion sous son appellation anglaise de FIFO First In First Out Le fait qu une place doit tre g r e en FIFO sera pr cis dans sa d finition textuelle par la mention Hard FIFO Un telle d claration donne lieu l extension illustr e par la Figure II 16 Cette abr viation fait un grand usage de l unification et de la g n ration de noms d objets C est un bon exemple de la puissance d expression des RPO qui m rite une explication d taill e Les valeurs des objets pr sents dans les places T te_de_file et Queue_de_ File ne sont d aucune utilit seule l identit de ces objets est importante puisque elle sert l unification sur la transition D filer Ces deux places sont donc d finies de type lt x ANY gt ou ANY C est une classe d objets quelconque on pourrait choisir la racine de la hi rarchie d h ritage Un autre solution moins l gante mais qui utilise des m canismes plus simples serait de stocker dans ces places des entiers la transition enfiler ex cutant l action apr s avant 1 64 II 2 Extension des RPO La transition Enfiler a une variable de sortie apr s
229. n 90 Le probl me auquel est confront le concepteur du dialogue est justement de mod liser cet tat qui repr sente l volution du dialogue entre application et utilisateur il lui faut notamment pallier l absence de structure de contr le explicite par un formalisme qui lui permette de valider sa mod lisation et notamment de prouver l absence de blocage cas ou une commande ne peut plus redevenir accessible ou d assurer une r troaction feedback informative et permanente a tout instant l interface doit montrer quelles actions sont l gales et lesquelles sont provisoirement inhib es Les solutions prouv es en mati re de sp cification du dialogue dans les applications conventionnelles Augmented Transition Networks Parnas 69 Denert 77 ou grammaires Olsen 83 sont malheureusement inad quates dans le domaine des applications dirig es par v nements elles tendent en effet mod liser l utilisateur comme un fichier s quentiel que l on peut soumettre une analyse syntaxique alors que les interfaces modernes souhaitent favoriser un comportement non s quentiel de l utilisateur qui peut volont interrompre ou diff rer une t che et entretenir des dialogues concurrents avec plusieurs parties de l application 2 3 Interpr tation du formalisme Nous nous proposons de donner quelques indications m thodologiques pour guider la conception du dialogue d une application interactive par les Objets Coop ratifs Dan
230. n La classes n uplet que nous allons d crire va donc tre une classe g n rique qui n est pas destin es tre instanci e mais plut t servir d anc tre des classes qui elles d criront la structure r elle de n uplets de la BD 216 VIL2 Interfaces Personne logiciel Cette classe est une classe d Objets Passifs cf VI 4 c est dire que ses instances se comportent comme de simples structures de donn es Passive Class Specification n uplet Attributes ident Identifiant La cl du n uplet Services correct lt r BOOLEAN gt Le n uplet v rifie t il les contraintes d int grit Affiche lt f Fen tre gt Afficher les valeurs du n uplet dans f Ajoute Ajouter le n uplet la table relationnelle D truit D truire le n uplet Figure VII 24 Sp cification de la classe n uplet La figure VII 24 montre la sp cification de la classe n_uplet Un n uplet poss de un identifiant dans l exemple on consid re que l identifiant peut se repr senter comme une cha ne de caract res mais toute autre repr sentation serait possible par exemple une ic ne ou une image Le service correct permet au n uplet de v rifier si il r pond aux contraintes d int grit s d finies par le mod le de la BD par exemple assurer la non duplication des identifants ou la v rification de d pendances fonctionnelles Il faut remarquer que l valuation du pr dicat correct sur une instance
231. n caract res lus partir du caract re courant Ecrire lt cha ne STRING gt Ecrit cha ne partir du caract re courant position lt p INTEGER gt Indice du caract re courant dans le fichier Create lt nom STRING gt is Ferm lt gt end l objet est associ au fichier physique d sign par nom Initialement le fichier est ferm la place Ferm est marqu e par un jeton simple a la cr ation de l instance ObCS D finition du type des places Ferm Ouvert lt gt Les places Ferm et Ouvert re oivent desjetons simples Up lt combien gt Ly lt position gt Figure IIL 6 Sp cification de la classe Fichier b La classe Fichier_protege La classe Fichier_prot g d crit la solution que nous proposons pour le probl me des lecteurs r dacteurs grand classique de la programmation concurrente s il en est Cette classe d crit un fichier du m me type que celui mod lis par la classe Fichier mais elle impose en plus une politique de gestion des acc s en lecture et en criture Les demandes d ouverture du fichier sont maintenant qualifi es par leur type un client ouvre le fichier en vue d y effectuer soit des lectures soit des critures Toute demande d ouverture satisfaite 96 II 3 Sp cification d une classe renvoie un identificateur de connexion qui devra tre ensuite pass en param tre de to
232. nalyse statique des propri t s des mod les est certainement une des caract ristiques des RdP qui a le plus contribu d velopper leur utilisation Les divers mod les de RdP de Haut Niveau et les RPO plus particuli rement se sont attach s pr server ces possibilit s d analyse tout en permettant de construire des mod les plus concis que les RdP simples Trois niveaux d analyse sont possibles pour un R seau de Petri Objet e Le premier niveau traite uniquement le r seau sous jacent du RPO c est dire un RdP obtenu en ne gardant de la d finition du RPO que ses places ses transitions et ses arcs et en ne conservant pour le marquage des places et les fonctions Pr et Post que le cardinal des 47 IL 1 Les R seaux de Petri Objet multiensembles qui les repr sentent Le r seau sous jacent est un RdP ordinaire o le marquage et les fonctions d incidences sont d crits par des entiers positifs ou nuls e Le second niveau ignore les pr conditions et les actions des transitions Les classes des jetons sont prises en compte mais leur valeur n est pas trait e et on ne conserve que le point i des d finitions 11 17 I1 19 et IL 21 relatives au marquage la franchissabilit et au marquage atteint par un franchissement e Le troisi me niveau traite tous les l ments de la d finition des RPO Pour chacun de ces niveaux un calcul d invariant est d fini Les invariants des RdP ordinaires sont bien con
233. ne place param tre qui contiendra le tuple de param tres de l appel est introduite en entr e de la transition d accord et de m me une place r sultat est introduite en sortie de la transition de retour accord retour Figure IIL16 S mantique intuitive d une invocation 114 II 4 Impl mentation d une classe Il faut bien pr ciser que le r seau de la Figure III 16 ne sert qu donner une vision intuitive du traitement associ une invocation de service Ce r seau ne prend notamment pas en compte les probl mes li s la dynamicit des appels une TI ne concerne pas toujours le m me serveur l auto concurrence ventuelle des invocations de services et la liaison tardive Une d finition formelle de la communication entre objets traitant ces probl mes et compatible avec cette vision intuitive est donn e en IX Cette construction mod lise une communication synchrone entre objets pour qu une invocation s ex cute compl tement il faut qu un flot de contr le chez le client se synchronise avec un flot de contr le chez le serveur D autres modalit s possibles de communication sont d crites au chapitre VI 4 7 D finition de la relation d utilisation On peut maintenant d finir formellement la relation d utilisation entre deux classes d objet D finition IIL 3 Relation d utilisation Une classe d objets C utilise une classe d objets Cy si une des transitions de l ObCS d impl mentation de C co
234. ne seule lors de la cr ation du moniteur On voit que plusieurs des concepts principaux de l approche Objet apparaissent dans cette d finition l identit l encapsulation la dissimulation d information l instanciation dynamique L aspect encapsulation est encore plus marqu lorsque l on examine les primitives de synchronisation offertes par un moniteur les conditions Krakowiak 85 D finition I 5 Conditions d un moniteur Les synchronisations entre processus d sireux d acc der la ressource s expriment dans les proc dures d un moniteur au moyen de conditions Une condition c est une entit du langage qui ne peut tre manipul e qu au moyen de trois op rations ou primitives c attendre bloque le processus p qui ex cute l op ration et le place en attente de c c vide fonction valeur bool enne vrai si aucun processus n est en attente de c c signaler si c vide alors lt r veiller un des processus en attente de c gt fsi Nous voici nouveau en pr sence d un Objet la condition peut tr s bien tre d crite comme un objet offrant les trois services cit s ci dessus et qui encapsule une file des processus en attente La condition est alors une version labor e du s maphore Dijkstra 65 Il nous parait surprenant que le moniteur et la condition aient si rarement re u une d finition explicite en termes d objets 18 1 2 Mod les d objets concurrents La motivation princ
235. neeses 234 L diteur de n uplets avec un message d erreur modal 235 Impl mentation de la classe Editeur 236 Chapitre IX Analyse d un mod le d Objets Coop ratifs Figure IX 1 Serveur sournois et Serveur rANSPparent 246 260 229 230 Table des figures 261
236. nisme sera lev au moment de l ex cution par un m canisme de commande ext rieur au syst me par exemple une interpr tation au sens de Valette 86 117 7 COMPARAISON AVEC L APPROCHE AXIOMATIQUE On peut comparer notre approche qui consiste d finir la pragmatique d une classe d Objets c est dire la fois sa s mantique et sa dynamique par un RPO avec l approche axiomatique classique promue par le langage Eiffel et h rit e des Types Abstraits de Donn es Dans cette approche la s mantique d une classe d objets est d finie par un invariant portant sur la classe et par des pr et post conditions portant sur l ex cution des op rateurs B Meyer Meyer 90a a montr comment le mod le de la programmation par contrat peut tre adapt aux syst mes concurrents nous avons pr sent cette discussion en I 1 3 La solution propos e est celle du contrat concurrent qui interpr te les pr conditions comme des conditions d attente l ex cution d un service C est bien l interpr tation que nous avons retenue dans notre formalisme mais les pr conditions au lieu d tre d crites par des pr dicats portant sur les attributs de l objet sont d crites par la structure m me de son ObCS Une requ te concernant un service pour lequel aucune Transition de Service TS associ e n est franchissable correspond une pr condition fausse et l invocation correspondante est mise en attente jusqu ce qu une des TS devienne franc
237. nit des primitives de gestion de fichier et d entr e sortie L environnement peut tre d fini dans le formalisme Objet par la donn e d une Classe Environnement dont on ne connait que l interface consistant en un ensemble d attributs ou de services qui sont invoqu s dans les actions des transitions du syst me Il existe alors un seul objet primitif de la classe Environnement nomm par convention ENVIRONMENT Les techniques de temporisation d crites au II 2 8 rel vent de ce m canisme l horloge est un attribut public de l environnement auquel en toute rigueur on devrait acc der par la notation ENVIRONMENT NOW La caract ristique de cette approche est que l interaction avec l environnement n a pas d action sur la structure de contr le du syst me l environnement est compl tement passif par rapport au syst me 124 IV 1 Syst mes d Objets Coop ratifs Ces deux techniques peuvent bien entendu tre utilis es ensemble pour un syst me donn Cette vision unificatrice de l interaction entre syst me et environnement est f conde et offre deux caract ristiques int ressantes e Le mod lisateur peut d placer son gr la fronti re entre le syst me et son environnement Ceci est particuli rement int ressant dans une d marche d analyse qui commence par d crire un syst me dans son entier pour ensuite sp cifier la composante logicielle du syst me e Il est possible de mod liser de mani re uniforme
238. nt On appelle ensemble des entit s cr es par un franchissement l ensemble V iew 7 Vout i Vind L occurrence de la transition peut pr ciser les valeurs d not es par les variables v telles que v ce V t new i Sive V aew est de type simple la valeur Val v est ind finie l issue du franchissement sauf si l action de la transition contient une affectation v lt Expression gt qui fixe explicitement sa valeur ii Sive V aew est de type classe on dira que la transition instancie la variable v A l issue du franchissement v est li e un nouveau nom d objet qui n existe nulle part ailleurs dans le syst me La valeur de l objet est d finie par le code de l op ration de cr ation not e Create de sa classe L action de la transition peut comporter des expressions de la forme v op ration liste de param tres qui permettent de pr ciser l tat l issue du franchissement de l instance cr e La possibilit de g n rer des nouveaux noms d objets peut tre formalis e comme suit e Pour chaque type classe C il existe une place PC au marquage initial infini qui contient le nom de toutes les instances de la classe qui n ont pas encore t instanci es 46 IL 1 Les R seaux de Petri Objet e Toute transition qui instancie une variable v de type classe C est reli e en entr e seulement Pc par un arc Pr Pc t lt v gt qui n est pas figur sur le r seau A l issue du franchissement
239. nt e par un rectangle englobant la d finition des composants En en t te de ce rectangle figure le nom de la classe et la d finition des param tres formels de l op ration Create de cette classe L interface de l objet les services offerts figure dans un rectangle la fronti re du corps de l objet e Chaque instance composante est elle m me repr sent e par un rectangle L en t te de ce rectangle contient le nom de la r f rence correspondante dans la classe composite et sa classe e Dans le corps du rectangle figurent les attributs initiaux de l instance composante c est dire les param tres qu il faut passer l op ration Create pour initialiser le composant On donne le nom du param tre formel de l op ration Create et la valeur correspondante Cette valeur peut tre une constante ou un param tre de l op ration Create de la classe composite Dans l exemple l op ration Create de la classe Classe a pour signature Create init Typel e Les arcs qui connectent les rectangles mat rialisent la relation d utilisation entre instances par exemple l arc tiquet ref entre l instance C et l instance C2 se traduit par l invocation du service d initialisation Cl SETref1 lt C2 gt e La fonction de traduction est mat rialis e par des arcs gris s qui connectent l interface du composant avec les interfaces des compos s 134 IV 3 Hi rarchie de composition 3 2 Exemple de classe composite la
240. nt de comportement Apr s traitement d un message un acteur remplace son comportement courant par un nouveau comportement par la primitive become En quelque sorte en ex cutant la primitive become un acteur pousse devant lui un nouvel acteur qui commence instantan ment traiter les messages en attente pendant que l ancienne version de l acteur continue le traitement du message initial avant de dispara tre g P 27 28 a ABCL Un exemple caract ristique de langage fond sur les concepts d acteurs est le langage ABCL Yonezawa 86 Ce langage toutefois introduit un axiome fondamental qui n existe pas dans le mod le d origine des acteurs et qui simplifie beaucoup sa s mantique d ex cution D finition I 6 Axiome de pr servation de l ordre de transmission Si un objet O envoie deux messages successifs un objet 7 la r ception de ces messages par l objet T doit tre ordonn e de la m me fa on que leur mission Le langage ABCL qualifie galement plusieurs protocoles de transmissions de message que nous avons d j rencontr ou que nous rencontrerons sous des formes voisines dans d autres approches e Messages PAST si un objet O envoie un message M de type PAST un objet T O continue son volution d s l envoi de M sans attendre de r ponse de la part de T C est le mode de communication unidirectionnel et asynchrone qui est la base des mod les d acteurs On peut pr ciser le protocole d
241. ntexte de l op ration appel e L OpCS associ d finit alors la suite de l volution Apr s ach vement de l op ration le contr le revient dans l objet appelant La s mantique d une op ration s quentielle est donc celle d un appel de proc dure e Dans une op ration parall le le contr le n est pas transf r mais un flot de contr le ind pendant est cr dans l ObCS de l objet serveur qui re oit une requ te d ex cution execution request La r ponse cette requ te va d pendre de l tat du serveur L ObCS d finit le flot de contr le entre op rations dans l objet client alors que l OpCS d finit une logique interne s quentielle pour chaque op ration Une requ te d ex cution peut donc initier terminer interrompre ou r activer des flots de contr le internes au serveur HOOD distingue deux types fondamentaux d objets e Les objets passifs un objet passif n a pas d ObCS et sa s mantique ne fait pas r f rence aux flots de contr le Lorsqu une op ration est invoqu e sur un objet passif le flot de contr le appelant est transf r directement cette op ration qui s ex cute s quentiellement Les objets passifs n ont donc aucune influence quant la structure de contr le globale du syst me 2HOOD n utilise pas explicitement cette terminologie mais parle d objet utilisateur ou utilis Les concepts recouverts tant exactement les m mes nous conserverons donc la terminologie client serveur
242. ntient une expression de la forme Vp Service lt liste de param tres gt ou Vp Attribut ou Vp Cp Create lt liste de param tres gt ou Vp est une variable de classe Cp Aucune restriction n est impos e priori quant la structure du graphe de la relation d utilisation Ce graphe peut notamment comporter des cycles et une classe peut tre en relation d utilisation avec elle m me ce qui est le cas par exemple quand on d crit une structure de donn e r cursive telle qu un arbre Certains domaines d application pourraient imposer ce graphe d tre un arbre ou un treillis logiciel structur en couches par exemple Lorsqu on construit le graphe de la relation d utilisation pour un ensemble de classes on peut distinguer trois types de n uds e Les n uds standards qui ont la fois des ant c dents et des suivants dans le graphe Ce sont des classes qui jouent la fois le r le de client et de serveur e Les n uds racines qui n ont pas d ant c dents ce sont des clients purs dont aucun service n est r clam par une autre classe e Les n uds feuilles qui n ont pas de successeurs ce sont des serveurs purs qui ne r clament les services d aucune autre classe La classe Fichier d crite au II1 3 4 a est un serveur pur 115 5 COHERENCE ENTRE SPECIFICATION ET IMPLEMENTATION La coh rence syntaxique entre sp cification et impl mentation de la structure d une classe est facile assu
243. ntique du cas ou le graphe de la relation d utilisation entre processus comporte plusieurs racines ou n est pas connexe e De plus on suppose que le fait qu aucun processus n a de r f rence vers le processus p peut tre refl t par un attribut nomm J_am_alone du processus p cette proposition connue sous le nom de comptage des r f rence est d crite dans Meyer 90b pp 434 435 qui conclut que cette approche est totalement irr aliste m me dans un langage s quentiel cause de son co t en effet chaque op ration traitant des r f rences y compris une simple affectation de la forme a b modifie les compteurs de r f rence dans ce cas le compteur de r f rence de l objet pr c demment associ a doit tre d cr ment alors que celui de l objet associ b doit tre incr ment Cette technique ne traite pas par ailleurs le cas des structures cycliques L utilisation d un tel m canisme dans un contexte distribu porte bien entendu ces probl mes un ordre de magnitude sup rieur qui donnent lieu de nombreuses recherches sur les approches de ramasse miettes appliqu es aux processus concurrents 2 3 Objets en tant qu acteurs Le mod le des Acteurs pour la programmation concurrente a t l origine propos par C Hewitt et son quipe au MIT Hewitt 73 Hewitt 77 Les concepts qui sont la base de ce mod le se retrouvent peu ou prou dans les deux approches d crites plus haut l approche
244. nts cf IL 1 3 peut permettre d tablir des propri t s importantes de l objet telles que l exclusion mutuelle entre services ou des contraintes de s quence chapitre IX 103 4 IMPLEMENTATION D UNE CLASSE Le fonctionnement d un syst me est d crit dans le formalisme des Objets Coop ratifs par la coop ration entre les objets qui le composent et qui entretiennent des relations de type client serveur en communiquant par invocation La sp cification d une classe d crit comment les instances se comportent du point de vue de leurs clients L impl mentation d une classe va d crire son fonctionnement interne Comme dans un langage classique l impl mentation d une classe d Objets Coop ratifs d crit une structure de donn es une structure de contr le et des algorithmes L impl mentation d une classe doit galement d finir comment ses instances vont utiliser d autres objets du syst me soit pour remplir les services offerts par sa sp cification soit pour ses besoins propres 4 1 Structure de donn es La sp cification d une classe peut exporter une liste d attributs qui sont qualifi s d attributs publics de la classe Dans l impl mentation on peut compl ter cette liste par la d finition d attributs priv s accessibles seulement l int rieur de la classe La structure de donn es d une classe est alors l ensemble de ses attributs publics et priv s Les types export s par la sp cification d une classe sont connu
245. nus Lautenbach 74 Les invariants alg briques du second niveau sont assez proches des pr c dents Au troisi me niveau les invariants sont tr s diff rents puisque ce sont des pr dicats portant sur les valeurs des jetons La r gle de franchissement tant de plus en plus contraignante du niveau 1 au niveau 3 un invariant v rifi un niveau reste v rifi au niveau sup rieur Le calcul des invariants des niveaux 2 et 3 est d fini dans Sibertin 85 et de mani re plus d taill e dans Sibertin 86 Nous pr sentons ici de mani re succincte les invariants alg briques de niveau 2 D finition IL 23 Pond ration d un r seau Selon Jensen 82 une pond ration not e W d un RdP est un vecteur de longueur P dont les l ments sont des fonctions W Fp pe P avec Fp Z Uarite P Z U o arit p est l arit de la place p Z U est le Z module g n r par 108 l ensemble des sommes formelles d l ments de U avec des coefficients positifs ou n gatifs et Fp est une fonction lin aire dont la d finition sur Z U tE P est l extension de sa d finition sur Uatite P D finition IL 24 Invariant alg brique Une pond ration W d un r seau R est un invariant alg brique si et seulement si V met m deux distributions de jetons sur R on a m gt m gt W m W m avec W m Erreur Pour un RdP ordinaire une pond ration est un vecteur d entiers de longueur P et es
246. nventionnelles toutefois 1 MODELISATION D UN ATELIER FLEXIBLE 1 1 Pr sentation g n rale de l atelier L atelier propos est bas sur une architecture modulaire dite en marguerite La fabrication est multi produits 3 produits PA PB et PC Ces produits circulent sur des palettes Ces palettes portent un code qui d termine les op rations que doit subir le produit Il est donc possible d affecter chacune d elles une gamme de fabrication diff rente qui permet de d finir la circulation des palettes au sein de l atelier ainsi que les op rations effectuer sur chaque poste de travail Le plan de l atelier est montr Figure VII 1 Il se compose de 3 l ments e un lot d assemblage J ot pour la fabrication compl te du produit PA et pour la fabrication partielle de PB e un flot d assemblage lof2 pour finir la fabrication du produit PB et pour la r alisation compl te du produit PC un syst me de convoyage appel Distributeur qui d une part assure la distribution des palettes vers les lots et qui d autre part joue un r le de passerelle Ilotl Ilot 2 Il est constitu de modules de transfert 1 seule voie et de module de d rivation vers les ilots Chaque lot est constitu de 5 modules de production comportant chacun un poste de travail robotis multi op rations Figure VII 1 et de 3 modules de transports reli s entre eux Ces modules se composent de 2 circulateurs en anneau ou pist
247. nvoqu es et un ObCS de sp cification qui indique les s quences d invocations que l objet est m me d accomplir L impl mentation quant elle d crit comment l objet est effectivement constitu et pr cise comment l objet se comporte lui m me en temps que client en invoquant d autres objets La s mantique de la communication entre objets est d crite en restant dans le cadre formel de la th orie des r seaux de Petri ce qui permet de caract riser formellement le comportement d un syst me d objets qui communiquent le comportement de chacun des objets du syst me tant lui m me d crit par un RdP Ce chapitre est consacr la d finition des classes d Objets Coop ratifs aussi bien en ce qui concerne la sp cification que l impl mentation Le chapitre IV d crit la structure d un syst me d Objets Coop ratifs et les techniques de structuration de l espace des classes Le chapitre V est consacr la description de la s mantique formelle d un syst me d Objets Coop ratifs et le chapitre VI d crit des extensions du formalisme destin es en faciliter l usage ou tendre son domaine d application 84 1 PRESENTATION DU FORMALISME Le formalisme des Objets Coop ratifs est un langage de conception Orient Objet qui pr sente les caract ristiques suivantes e C est un langage base de classe qui force op rer une distinction claire entre le concept de classe et celui d instance Une classe est
248. objets s quentiels 2 1 Objets en tant que moniteurs Dans un article corrosif Leslie Lamport dresse l histoire de ce qu il appelle la concurrence standard ce par quoi il entend l tat de l art en mati re de concurrence diff rentes poques Lamport 83 17 1 2 Mod les d objets concurrents Variables partag es S maphores Moniteurs CSP Figure I 3 Histoire de la concurrence selon Lamport Il est remarquable de constater que les formulations initiales des Moniteurs les secr taires de Dijkstra 71 puis Brinch Hansen 72 Hoare 74 peine post rieures aux premi res publications sur Simula Dahl 66 offrent d j une indiscutable saveur Orient e Objet Il serait int ressant de retracer le cheminement des id es et des concepts de Dahl et Nygaard jusqu Hoare Rappelons la d finition des moniteurs Hoare 74 Krakowiak 85 D finition I 4 Moniteur Un moniteur est un m canisme de structuration permettant de contr ler l acc s des ressources communes Il regroupe les ressources partageables et les proc dures de gestion de ces ressources Un moniteur est constitu par un ensemble de variables d tat et un ensemble de proc dures qui manipulent ces variables Certaines de ces proc dures dites externes sont accessibles aux utilisateurs du moniteur et constituent l unique moyen de manipuler ses variables d tat Un moniteur contient enfin un programme d initialisation ex cut une fois et u
249. omposition Orient e Objet 3 1 Approche par d composition Une des techniques de structuration des RdP par une approche de d composition hi rarchique les plus abouties est celle pr sent e par Huber Jensen et Shapiro Huber 89 introduite pour structurer les mod les de RdP color s Le but de cette approche est d introduire dans les RdP des concepts comparables aux sous mod les de SADT Ross 79 ou aux sous programmes des langages de programmation Le mod le d int gration des sous r seaux dans un r seau global n est pas toutefois celui de l appel de sous programme mais plut t celui de la substitution en ligne de macro instruction Pour sp cifier comment le sous mod le sp cifi s int gre dans le r seau de niveau sup rieur on d finit des n uds de substitution qui sont des macro places ou transitions reli es aux sous mod les et la s mantique de substitution est d finie de telle sorte que l on puisse partir d un mod le structur hi rarchiquement reconstruire automatiquement un RdP color non hi rarchique quivalent sauf pour un des modes de composition la transition d invocation que nous d taillons plus loin Cette construction pour cons quence que les mod les substitu s doivent se comporter comme des places ou comme des transitions Cinq constructions hi rarchiques sont propos es e Les transitions de substitution o le n ud substituer se comporte comme une transition Le sous r seau
250. on cf D finition 11 22 peuvent tre franchies en parall le La r gle de franchissement n impose pas toutefois qu elles le soient et toutes les combinaisons de franchissements concurrents ou s quentiels sont licites pour autant qu elles restent compatibles avec la d finition du franchissement dans les RPO cf Definition II 19 e Si deux transitions associ es au m me service sont franchissables elles ne peuvent tre franchies concurremment que pour des invocations diff rentes c Description de l interaction tat traitements On a d j soulign l interd pendance tr s forte qui existe dans tout syst me entre les donn es qui le composent et les traitements auquel il peut donner lieu cf I 1 C est justement la reconnaissance de cette interaction qui a donn ses fondations au mod le objet qui rassemble en une seule entit ces deux composantes d un syst me ainsi qu aux RPO Nous pouvons pr sent expliciter comment le formalisme des Objets Coop ratifs r pond un de nos objectifs de mod lisation savoir exprimer avec une notation concise et non ambigu l interaction entre l tat de l objet et l activation de ses services e L activabilit d un service d pend de l tat de l objet un service est activable pour un objet si le marquage de l ObCS de cet objet rend franchissable une des transitions associ es ce service 99 II 3 Sp cification d une classe L ex cution d un service modifie l t
251. on h ritage composition pour d crire les aspects structurels ou statiques d un syst me tout en profitant de l expression claire concise et formelle de la concurrence qui est une des caract ristiques de l approche r seaux de Petri On peut envisager d utiliser ce formalisme dans les domaines suivants Le mod le peut servir de sp cification fonctionnelle du syst me mod lis On doit alors fournir un mod le qui se comporte comme le syst me et dans cette optique les qualit s primordiales d un formalisme sont le pouvoir d expression un formalisme de haut niveau facilite la communication des mod les au sein d une quipe et le caract re formel pour viter toute interpr tation subjective de la sp cification e Le mod le peut servir la conception du syst me Les aspects structurels du mod le sont alors les plus importants et les facilit s d abstraction et de structuration sont primordiales Pp p p Le mod le peut servir la simulation ou au prototypage du syst me Le formalisme doit alors tre suffisamment formel pour tre ex cutable Laboratoire d accueil LIS Universit Toulouse I Place Anatole France 31042 Toulouse Cedex Introduction Le mod le peut tre analys afin d tablir certaines propri t s du syst me mod lis Le mod le peut permettre d assister la g n ration de code dans un langage informatique qui servira l impl mentation du syst me final Le
252. on II 15 des R seaux de Petri Objets Certaines de ces extensions sont nouvelles places tri es arcs inhibiteurs g n ralis s d autres ont d j t introduites dans diff rents dialectes de RdP Ces derni res n ont pas toutes re u une d finition qui prenne en compte les nouvelles possibilit s offertes par les RdP de Haut Niveau et plus particuli rement par les RPO aussi en proposerons nous de nouvelles d finitions Ces extensions peuvent tre class es en trois cat gories en fonction de leur objectif Certaines registres r gles d mission et places capacit sont uniquement des abr viations dont le but est d accro tre la concision des mod les en fournissant en tant que primitives des constructions fr quemment utilis es Pour chacune de ces extensions il existe un algorithme tr s simple permettant de se ramener un r seau quivalent mais qui utilise uniquement la d finition de base des RPO Les abr viations n augmentent donc pas le pouvoir d expression du formalisme La concision et la lisibilit tant des facteurs clef de la valeur d usage d un formalisme ces abr viations sont largement utilis es dans le reste de ce m moire D autres extensions arcs priorit arcs inhibiteurs ordonnancement des places ont pour objectif de donner au concepteur des moyens de ma triser le non d terminisme des mod les un r seau de Petri simple peut d crire des situations de choix non d terministe
253. on creat lt conn gt Figure IIL 13 OpCS de l op ration Ouvrir_en_ criture L OpCS de l op ration Lire pr sente une caract ristique int ressante le r sultat de la lecture est renvoy au client par la transition END Lire avant que le traitement de l op ration soit compl tement termin pour le serveur qui doit encore calculer la nouvelle position du Fichier 111 II 4 Impl mentation d une classe lt conn combien Lire lt conn pos gt f Aller_en lt pos gt lt conn f combien lt conn combien gt Pas_d crivain END Lire ch f Lire lt combien gt lt ch gt lt conn f gt pos f position Figure III 14 OpCS de l op ration Lire L exemple ci dessus illustre une des caract ristiques de notre formalisme les jetons qui circulent dans un ObCS sont fr quemment des r f rences d objet qui en quelque sorte d signent un autre ObCS du syst me Dans notre exemple l ex cution de l op ration Ouvrir_en_ criture va provoquer au moins deux changements d tat dans le syst me elle va s il n y a pas de lecteurs faire passer l objet Fichier de l tat Ferm l tat Ouvert cf l ObCS d impl mentation de Fichier Figure III 11 et va faire passer le jeton qui d note l objet Fichier de la place Pas_d Ecrivain la place Ecrivain dans l ObCS de Fichier_prot g on ne consid re pas ici le changement d tat que va subir le client du service Ouvrir_en_ criture
254. on des mod les de R seaux de Petri de Haut Niveau Cette utilisation syst matique des RdP permet de pallier aux d fauts les plus importants de la m thode HOOD qui sont dus au manque de formalisation des ObCS et OpCS Dans la m thode HOOD on recommande de d crire ObCS et OpCS par les constructions des t ches Ada En suivant cette recommandation on s expose plusieurs inconv nients e On fixe tout d abord de fa on pr matur e le langage de programmation car des constructions quivalentes aux t ches sont peu souvent disponibles dans d autres langages e On utilise un outil dont la d finition formelle est pour le moins insuffisante que l on songe par exemple aux probl mes li s la terminaison des t ches imbriqu es ce qui compromet les possibilit s de raisonner sur une conception ou de la valider e On travaille enfin avec un mod le d ex cution s quentiel dans le cadre duquel il est difficile de d crire des entit s au comportement concurrent On court alors le risque de rechercher trop t t les processus s quentiels qui composent le syst me L utilisation des RdP permet galement d viter la centralisation du contr le d un objet parent dans un seul de ses objets enfants CTRL_ parent cf 1 3 qui conduirait mettre en place une d pendance verticale entre les objets d une hi rarchie On contraire on distribuera en g n ral le contr le d un parent de mani re quitable entre ses enfants La
255. on du marquage M atteint depuis M par occurrence de t est identique celle des RdP simples Si Inhib p t p n impose aucune contrainte sur le franchissement de t de m me que lorsque Pr p t 0 Un arc p t tel que Inhib p t 1 fonctionne comme un arc inhibiteur de Hack Cette d finition est plus puissante que celle de Hack puisqu elle autorise les arcs inhibiteurs a tre pond r s permettant alors de d finir qu une transition est franchissable quand une place contient moins d un certain nombre de jetons Elle permet en outre comme illustr en Figure II 10 de combiner arc inhibiteur et arc standard entre une place et une transition sp cifiant dans cet exemple ue la transition T1 n est franchissable que si la place P1 contient un jeton et un seul q q p J 58 II 2 Extension des RPO Figure IL 10 combinaison d arc inhibiteur et d arc standard L extension de la D finition 11 32 aux RPO est tr s simple la fonction Inhib subissant le m me enrichissement que la fonction Pr SIL 1 2 D finition IL 33 RPO arcs inhibiteurs Un RPO arcs inhibiteurs R lt C T V P Pr Post Inhib gt est d fini par l adjonction un RPO lt C T V P Pr Post gt d une fonction Inhib Inhib PXT N VUU telle que i support Inhib p t V V ii Vv e Inhib p t longueur v arit p iii Vv e Inhib p t type v type p L ensemble des variables d entr e d une transition est
256. on entre des objets du syst me ce qui interdit en pratique ou rend tr s difficile la d finition de relations d utilisation dynamiques ou un objet client ne fait pas toujours r f rence aux m mes objets serveurs au cours du temps 36 Chapitre Il Les R seaux de Petri de haut niveau Trois grands mod les de la concurrence sont actuellement utilis s pour la description et l analyse des syst mes parall les La logique temporelle Audureau 87 88 Pnueli 86 les approches relevant de l alg bre des processus Hoare 78 Milner 80 83 et les R seaux de Petri RdP Un litt rature tr s abondante existe sur les r seaux de Petri leurs fondements th oriques leurs applications pratiques et les divers dialectes de RdP de Haut Niveau d riv s du mod le initial propos par C A Petri Petri 62 Parmi la bibliographie de base sur les RdP citons notamment Brams 83 Peterson 81 TSI 85 ainsi que les deux copieux tomes des Lecture notes in Computer Science LNCS 87 actes d un cours avanc sur les RdP qui s est tenu Bad Honnef en 1986 La premi re partie de ce chapitre est consacr e la d finition des R seaux de Petri Objets RPO Sibertin 85 qui est le dialecte de R seaux de Petri de Haut Niveau RdPHN que nous utilisons pour d finir la dynamique d une classe d Objets Coop ratifs La deuxi me partie d finit plusieurs extensions originales des RPO destin es en accro tre le pouvoir d expression ou r
257. on synchrone Le mode d invocation standard d un service est le rendez vous qui correspond au requ tes HSER Highly Synchronous Execution Request de la m thode HOOD tablissant une communication de type question r ponse L invocation non confirm e correspond aux requ tes ASER ASynchronous Execution Request et l invocation gard e permet de d finir des requ tes TOER Timed Out Execution Request Malgr nos efforts nous ne sommes pas parvenus a trouver une construction simple permettant d muler dans tous les cas les requ tes LSER Loosely Synchronous Execution Request ou l appelant est bloqu jusqu la prise en compte de son appel et peut ensuite continuer son ex cution Intuitivement la construction qui mulerait ce mode de communication consisterait en une fusion de la transition d appel du client avec la transition d accord du serveur malheureusement cette solution est impossible car le m me service peut tre invoqu par plusieurs transitions diff rentes dans l ObCS du client et surtout par un nombre ind termin de clients de classes diff rentes Le probl me est encore compliqu par le polymorphisme car la classe de l objet qui re oit l appel peut varier suivant la hi rarchie d h ritage Pour pouvoir muler une requ te LSER il faudrait donc que le service concern soit invoqu dans une seule transition du syst me et que l entit qui d note le serveur soit une constante ou soit d une classe fe
258. oncept d objet par son aspect faiblement coupl encapsul et autonome semble bien se pr ter une impl mentation distribu e o chaque objet peut voluer concurremment en changeant des messages avec son environnement Au del de cette intuition de base les approches propos es diff rent non seulement par les solutions techniques ou syntaxiques adopt es mais souvent aussi par les axiomes fondamentaux sur lesquelles elles se basent Nous avons tent de classifier les diff rentes approches des LOO concurrents en trois grandes cat gories essentiellement en fonction de leur mani re d organiser objets ou processus l int rieur d un syst me les approches par moniteurs par processus ou par acteurs Les limites entre ces cat gories sont bien entendu assez floues et certaines approches ont des caract ristiques qui les placent cheval sur ces fronti res quelque peu sch matiques Nous esp rons toutefois que cette classification puisse au moins servir de base de r flexion car il nous appara t que dans chacune de ces cat gories les syst mes exhibent une topologie statique et une volution dynamique assez caract ristiques Nous n tudierons dans chacune de ces cat gories que les aspects directement li s la concurrence Tous les langages examin s font en effet preuve dans les autres domaines de l approche objet classification h ritage instanciation d une vari t aussi grande que les langages
259. ons priv es sont franchies en exclusion mutuelle mais concurremment La granularit d ex cution d un objet est le franchissement d une transition priv e de son ObCS En associant plusieurs transitions au m me service on peut sp cifier qu une requ te a des conditions d activation et des effets diff rents suivant l tat de l objet serveur On peut facilement au sein du formalisme d crire un objet actif c est dire un objet qui peut provoquer un changement de son propre tat sans pour cela tre sollicit par un flot de contr le en provenance de son environnement et qui a la possibilit de g n rer de nouveaux flots de contr le de sa propre initiative Un objet coop ratif peut donc avoir une activit spontan e qui n est pas d clench e par l activation d un de ses services Cette activit spontan e qui peut repr senter la t che de fond de l objet est mod lis e par des transitions priv es de l ObCS c est dire des transitions qui ne sont pas associ es une invocation de service Les r seaux de Petri permettent de d crire des syst mes dont l volution n est pas d terministe La sp cification d un comportement non d terministe peut signifier que le syst me d crit est lui m me essentiellement non d terministe ou que le niveau d abstraction auquel on se trouve ne permet pas encore de d finir pr cis ment comment le choix est fait entre plusieurs alternatives d volution ou encore que l ind termi
260. onservant un r seau pour chaque classe d objets du syst me et en rassemblant par pliage le marquage d un nombre quelconque d instances de cette classe On a indiqu au chapitre IIL 3 que les attributs d finis pour une classe d objet sont utilis s comme registres de son ObCS Le chapitre II 2 a montr que les registres des RPO taient une facilit syntaxique pour d signer des jetons pr sents dans des places cach es du r seau L ObCS de chaque classe est modifi de la mani re suivante 1 Introduction des places attribut une nouvelle place est ajout e pour chaque attribut de la classe et le type de cette place est le m me que celui de l attribut Chaque place attribut est connect e en entr e et en sortie chaque transition o l attribut associ est utilis et les arcs sont tiquet s avec le nom de l attribut Par utilisation d un attribut on doit entendre Affectation d une valeur l attribut au sein de l action de la transition Utilisation de la valeur de l attribut au sein d une expression Appel d une op ration interne qui utilise dans son code l attribut Test de la valeur de l attribut dans une pr condition Utilisation de l attribut comme param tre r el d un appel de service 2 Certaines transitions TI ou transitions priv es peuvent n avoir aucune place d entr e dans l ObCS d crivant ainsi des services ou des actions internes qui sont toujours activables Si le cas se pr sente on ajo
261. ortie d une transition t De plus ona Vi Vin t U Vout 7 A chacune des transitions d un r seau on peut associer une pr condition Une pr condition est une expression bool enne associ e une transition t T dont l ensemble des variables est inclus dans V t 8 A chacune des transitions d un r seau on peut associer une action Une action est un ensemble d instructions qui sont soit l invocation c est dire l appel d un service publi par la classe d un objet not variable op ration liste de param tres avec variable V soit l affectation dont la syntaxe est lt variable variable gt lt expression expression gt avec out et expression est une expression retournant une valeur du m me type que variable et variable V dont les variables sont dans V t Remarque Dans la repr sentation graphique des RPO l arc correspondant Pr ou Post est dessin si et seulement si Pr p t 0 qui est l l ment neutre de N VUU NWOU a Marquage d un RPO D finition IL 16 Jetons simples et jetons typ s Soit R un RPO et U Pea C Dom t son univers On appelle jeton de R un l ment j je U Si longueur j 0 on dira que j est un jeton simple sinon on dira que j est un jeton typ D finition 11 17 Marquage d un RPO Soit R un RPO Un marquage de R not M m Val est donn par une fonction de r partition qui distribue des jetons dans les
262. oser dans les tapes classiques d un cycle de vie que sont l analyse des besoins la sp cification la conception et l impl mentation Des m thodes sp cialement adapt es la prise en compte des besoins de l utilisateur dans le processus de conception ont t propos es Barthet 88 Le formalisme des objets coop ratifs quant lui est plus particuli rement adapt l tape de conception de l interface et pourrait s int grer dans les approches m thodologiques cit es ci dessus Les progr s tr s rapide du mat riel on donn lieu une mutation radicale des interfaces propos es aux utilisateurs de logiciel L tat de l art est aujourd hui aux stations de travail graphiques pourvues d un dispositif de pointage la souris permettant la d signation directe L interaction entre l utilisateur et la machine se fait par interaction avec des repr sentions symboliques iconiques de l information Ce type d interfaces est aujourd hui suffisamment r pandu et bien ma tris pour qu il soit possible de les normaliser et plusieurs standards sont propos s pour fixer une pr sentation look et un mode d interaction feel commune plusieurs constructeurs IBM 89 Motif 89 Open Look 90 2 1 Le mod le Seeheim Le mod le Seeheim Pfaff 85 est un mod le g n rique de l interface personne logiciel qui prouv sa f condit en offrant un cadre structurant aux diverses recherches dans ce domaine Il se trouve de mani re plus o
263. osites e Le WSCS d crit le fonctionnement du syst me avec un grand luxe de d tails notamment le transfert d une baguette entre un philosophe client et un philosophe serveur est d taill en L envoi d une requ te du client au serveur La prise en compte de la requ te par le serveur Le retour du r sultat de la requ te ici un simple jeton au client On peut analyser le WSCS en calculant les invariants qui en clairent le fonctionnement e Un invariant d crit le flux des baguettes entre les philosophes Cet invariant Baguette gauche PS Baguette droite P2 Baguette gauche montre qu une baguette passe continuellement de la main gauche d un philosophe la main droite de son voisin e L invariant compl mentaire Pas de baguette gauche Pl Pas de baguette droite P4 Pas de baguette gauche d crit le flux de l absence de baguette Le WSCS peut en outre tre simplifi par simple regroupement des deux macro transitions soulign es en Figure V 20 par des tons de gris diff rents et en identifiant les deux places voisin de droite et voisin de gauche devenues redondantes en une seule Ce faisant on ne d taille plus la s quence d op rations demander une baguette attendre la baguette et r cup rer la baguette obtenue Il faut remarquer qu un tel regroupement nest possible que si un service est invoqu par une seule TI du syst me et que le syst me est sans h ritage Au prix d une sim
264. ourrait tre plus judicieux dans ce cas de demander une confirmation l utilisateur ce qui serait repr sent dans l ObCS par une pr condition rempla ant l arc inhibiteur L un des int r t de notre approche est justement de permettre de telles discussions en autorisant un prototypage de la dynamique de l application tout en offrant une sp cification la fois formelle concise et compl te de la structure du dialogue Un autre int r t est de profiter des possibilit s d analyse des RdP pour v rifier des propri t s de notre mod lisation Il est ainsi trivial de d monter que les places S lectionn et Edit sont born es 1 et qu elles sont mutuellement exclusives tablissant ainsi la propri t souhaitable que l on n dite qu un seul n uplet la fois On peut galement d montrer que quel que soit le marquage atteint une et une seule parmi les transitions associ es au service Editer est franchissable montrant ainsi que l utilisateur eut interagir avec les l ments de la zone d dition quand il le souhaite p g q 221 VII 2 Interfaces Personne logiciel 222 Chapitre VIII Ex cution d un mod le d Objets Coop ratifs Une fois construit le WSCS le mod le d un syst me peut tre ex cut par un interpr te de r seau pr dicat transition permettant ainsi au concepteur d exp rimenter la dynamique de son syst me De nombreux interpr tes de RdP de haut niveau sont disponibles certains distribu s
265. oustrup 87 Meyer 90b BI GL 49 BI GL 57 entre autres 24 25 Quoi qu il en soit le mod le de programmation concurrente promu par le langage Ada est bien connu et a donn de nombreuses preuves de son efficacit Le mod le de base de communication est le rendez vous synchrone et asym trique o un client invoque une entr e de t che et o la t che appel e d finit sous quelles conditions et dans quel ordre elle acceptera les requ tes sur ses entr es Il nous apparait surprenant que le mod le des t ches Ada simple et prouv n ait pas davantage trouv sa place dans des propositions visant introduire la concurrence dans l approche Objet L id e d un objet ex cutant un corps de type boucle infinie et sp cifiant divers points de cette boucle quels sont les messages qu il accepte avec ventuellement un ind terminisme sur le choix du message accept para t pourtant intuitivement int ressante Il faut par ailleurs remarquer que c est la construction Ada du type t che qui est le plus souvent utilis e lorsqu on veut muler en Ada les m canismes des langages objets Pitette 86 b Caromel 90 L intuition fondamentale qui sous tend l approche propos e dans Caromel 90 est la poursuite de la d marche unificatrice promue par l approche objet L approche objet confondu les concepts de module et de type dans le concept unique de classe d objets On souhaite aller plus loin en unifiant les concep
266. outer la classe biblioth que la liste de ses anc tres Le seul probl me pos par l h ritage multiple est la possibilit de conflit de nom entre des caract ristiques services ou attributs h rit es de diff rents anc tres Les langages ou les formalismes supportant l h ritage multiple proposent divers m canismes pour lever ces conflits Ducourneau 87 les techniques les plus fr quemment pr sent es sont la sp cification d un mode de parcours du graphe d h ritage Stefik 86 qui conserve la premi re d finition rencontr e de la caract ristique ou le renommage explicite au niveau de la classe des caract ristiques en conflit Meyer 90b 16 2 MODELES D OBJETS CONCURRENTS Object languages differ even in the fundamentals M Stefik D G Bobrow Le rapport Le Temps R el CNRS 88 tabli par le Groupe de R flexion Temps R el du CNRS d signe La mod lisation objets des entit s manipul es v nements et actions et de leurs interactions comme un Probl me non r solu dans la sp cification d une application temps r el Le probl me de la Programmation Orient e Objet Concurrente COOP Agha 90 est cependant au c ur d une quantit impressionnante de travaux de recherche dont nous pr sentons ici un simple aper u La concurrence a d ailleurs t d s l origine associ e au concept d objet puisque le LOO Simula le premier a introduit une forme de concurrence par coroutine Le c
267. pas de corps ou tache de fond et n est actif que lorsqu il traite un message Les objets peuvent communiquer e Par une primitive de type question r ponse ask pour lequel l appelant demande l valuation d un message et est bloqu tant que l appel n a pas fourni une r ponse au moyen de la primitive reply 20 1 2 Mod les d objets concurrents e Par une primitive de communication asynchrone send pour lequel l appelant n attend pas de r ponse et n est donc pas bloqu l appelant et l appel peuvent alors avoir une volution concurrente On voit que seule la primitive send peut causer une volution parall le des objets dans le syst me le couple ask reply bloquant le flot de contr le appelant et fonctionnant comme un appel de proc dure distante L originalit du langage SINA Tripathi 89 est de permettre de mod liser la fois la concurrence entre objets et la concurrence interne un objet La concurrence interne est impl ment e soit par encapsulation de plusieurs objets actifs soit par un m canisme comparable au fork du syst me Unix qui permet d initier des flots de contr le concurrent pendant l ex cution d un service Un objet SINA peut encapsuler une ressource partag e en m me temps que ses m canismes de synchronisation dans le m me module Ceci prend en compte plusieurs de probl mes pos s par l utilisation de structures de moniteurs emboit s dans des syst mes qui g rent des ressou
268. per 1 MOD 4 Lors du d chargement l ordonnancement peut galement modifier la gamme de la palette et donc le produit fabriquer if oper 0 then gamme end end create g do gamme oper end Figure VIL7 La classe Palette La classe Palette exporte les types utilitaires Op rations un type num r et Gamme Une palette peut indiquer l op ration suivante qu elle doit subir par l interm diaire du service Op ration_suivante En VII 3 on a indiqu la configuration initiale de l atelier en donnant la quantit de palettes pr sentes dans le distributeur l initialisation du syst me Cette configuration intiale sera mod lis e par le marquage initial des OBCS des objets qui composent le syst me Les places de ces OBCS contiendront donc des r f rences d objet de la classe Palette et la m thode Create de la classe Palette indique comment initialiser de tels objets b La classe Atelier Il s agit de la classe composite correspondant l ensemble du syst me le syst me de production que l on veut mod liser sera d fini par un seul objet primitif de la classe Atelier On a choisi de ne pas identifier le distributeur en tant qu objet composite un atelier est donc constitu des objets l mentaires du distributeur 1 e quatre Transport et deux D rivations et de deux objets composites de classe Zot 197 VII 1 Mod lisation d un atelier flexible Dans
269. places du r seau et par les valeurs de ces jetons 44 IL 1 Les R seaux de Petri Objet On d finit la fonction de r partition m par m P N U p gt m p tel que i WVpeP Vje m p longueur j arit p et type j compat type p Le type de chaque jeton doit tre compatible avec celui de la place dans lequel il se trouve ii La fonction Val est d finie comme en D finition II 13 b Franchissabilit des transitions D finition IL 18 Substitution des variables d une transition Soit R un RPO t e T une transition de R Une substitution des variables de t est une fonction S S Vi Ad gt U telle que Vve Vi type v type S v D finition IL 19 Franchissabilit d une transition Soit R M un RPO muni d un marquage M m Val Soit t e T une transition de R et S une substitution des variables de t On dit que t est franchissable par S a partir de M ce qui est not Mit S si et seulement S1 i Vpe P S Pr p t lt m p ii si Pr vin vin est la pr condition de t alors la proposition Pr Val S vin Val S vin est vraie Le couple t S est alors appel une instance de la transition t pour le marquage M On dira que la transition t est franchissable partir d un marquage M ce que l on note M LR si et q p quag q seulement si 3 S tel que t S est une instance de t S lection des Objets pour un franchissement Les substitutions qui permettent de rendre
270. ple renomination des variables on obtient alors le r seau de la Figure V 21 tr s proche d une mod lisation par r seaux color s La place _ gauche repr sente alors un pr dicat tel que _gauche X est vrai si X est gauche de Y Pas de Pas de baguette baguette lt gauche gt gauche droite donne __ lt self droite donne _ baguette _ baguette _ droite gauche lt bd gauche gt lt bg droite gt lt bg self gt lt bd self Figure V 21 R seau simplifi de la table de philosophes 166 V 6 Prise en compte des classes composites Le syst me d crit ci dessus est un syst me enti rement statique ou le nombre d instances n volue pas Il nous appara t que c est pour de tels syst mes que la mod lisation par objets composites est la plus adapt e 7 CALCUL DES PROCESSUS SEQUENTIELS Plusieurs m thodes de conception de syst mes concurrents Ward 85 Harel 88 d butent le processus de mod lisation par l identification des processus s quentiels du syst me Cette identification peut se r v ler subjective ou difficile r aliser lors d une tape si pr coce Dans le WSCS les processus s quentiels du syst me peuvent tre identifi s en cherchant des invariants de place Colom 86 Ces processus s quentiels ne sont plus limit s par les fronti res entre objets puisqu un m me processus peut tre distribu sur plusieurs objets Nous avons identifi s de tels processus s quentiels
271. plexe et pour rendre rigoureux le processus de mod lisation e Le formalisme permet d adopter un point de vue plus ou moins abstrait sur le syst me en combinant les possibilit s offertes par l h ritage la distinction sp cification impl mentation et la relation de composition En temps que langage de programmation les Objets Coop ratifs ont les caract ristiques d ex cutabilit et de s mantique bien d finie qui sont indispensables pour une utilisation en tant qu outil d implantation e L ex cution par interpr tation ne pose pas de probl me et les outils qui permettraient une telle ex cution sont d j disponibles interpr tes de r seaux de haut niveau e L ex cution par compilation totale en g n rant partir d un mod le les structures de donn es et de contr le d un langage concurrent ou partielle en utilisant les techniques emprunt es l intelligence artificielle pose certainement des probl mes plus complexes et il faudrait sans doute dans ce cas se restreindre des r seaux born s Evolution et enrichissement du formalisme Le formalisme des Objets Coop ratifs se situe un haut niveau d abstraction et il est utilisable pour une classe tr s large de probl mes selon la fa on dont les concepts ou constructions qu il offre sont interpr t s Des tudes de cas on d ores et d j t r alis es dans le domaine des ateliers de production des Syst mes d Information des interfaces personne
272. port la classe Transport_double une palette doit rester sur la voie de droite si elle a subi toutes les op rations disponibles sur l il t le test est donc invers par rapport une section de transport double normale o la palette reste droite si l l ment suivant doit la traiter La clause b de la gestion du distributeur est garantie par le fonctionnement en flux tir de l ensemble de l atelier c La classe Cellule Cette classe d objet mod lise les cellules contenant les postes de travail robotis s et h rite de la classe Transport_double Toutefois son ObCS de sp cification montre qu une palette peut changer de voie lors de la travers e d une cellule Figure VIT 19 Class Specification Cellule inherit Transport _ double attribute suivant Transport _ double services SETsuivant lt s Transport _double gt ObCS Circule lt Palette gt Circule capa lt pal gt DROITE lt pal gt Figure VII 19 Sp cification de la classe Cellule La Figure VII 20 donne l impl mentation de la classe cellule Le service de consultation Traite est red fini par rapport a la classe Transport_double il teste si l op ration suivante que doit subir la palette peut tre assur e par le poste 208 VIL 1 Mod lisation d un atelier flexible Class Implementation Cellule Attributes Ops set of Operations Services Create lt Oper set of Operations gt is do Ops Oper end
273. ppeler Dans l exemple de la table de philosophes le seul service export par la classe composite est Garnir qui se traduit en une invocation du service Garnir_le_plat sur l instance composante Chef _de_table 162 V 6 Prise en compte des classes composites Chef_de_tabD ETgauche ph2 Chef_de_table S lt Chef_de_table s fL lt Chef_de_table self Place param tre du service Garnir le plat lt riz id Chef_de table 4 V id self gt Place r sultat du service Garnir_ le plat du service Garnir lt riz id selfp du service Garnir END_GARNIR Figure V 17 R seau de traduction pour l invocation d une instance composite La Figure V 17 montre le m canisme qui permet la redirection de l appel vers l instance composante en compl tant la structure du r seau de traduction entam e en Figure V 16 6 3 Construction d un syst me partir d une classe composite L exemple que nous avons trait tout au long du V 3 pour illustrer le proc d de construction du WSCS tait sans signification uniquement destin montrer l effet des diff rentes tapes du proc d sur la structure des ObCS Nous nous proposons d effectuer la construction du WSCS sur un syst me qui fasse sens afin de d montrer les enseignements que l on peut tirer de cette construction et nous allons traiter l exemple de la table de philosophes d crit au IV 3 2 Le syst me que nous allons trai
274. pr condition doit tre interpr t e comme un appel de m thode dans un langage objets s quentiel avec liaison tardive la variable a peut tre li e des objets dont la classe est descendante de la sienne propre Il faut donc rechercher dans le graphe d h ritage l impl mentation correcte de l op ration OP1 On peut donner une mani re intuitive de consid rer les data flows en exportant un data flow une classe publie le code algorithmique qui permet d acc der ses attributs et non pas les attributs eux m mes On r alise ainsi une forme d encapsulation qui n existe pas si l on publie directement les attributs Un data flow ne peut pas tre consid r exactement comme un attribut calcul puisque la valeur qu il renvoie peut d pendre d un param tre re u un attribut calcul peut tre consid r comme un cas simple de data flow sans param tre et donc unidirectionnel 183 V1 4 Objets passifs 4 OBJETS PASSIFS Le formalisme des Objets Coop ratifs tel qu on vient de le d finir est bien adapt pour d crire des entit s de haut niveau des agents actifs dans l volution du syst me qui ont leur comportement propre et qui peuvent tre l origine de flots de contr le et non pas seulement les subir Un Objet Coop ratif est le plus souvent identifiable un processus non s quentiel du syst me dans lequel il intervient Toutefois un syst me est le plus souvent d crit la fois par les processus
275. pr senter l impl mentation de classes d objets au sein du formalisme des Objets Coop ratifs en utilisant les m mes exemples qu au III 3 4 les classes Fichier et Fichier_prot g a Classe Fichier Impl mentation L impl mentation de la classe Fichier Figure HI 11 va faire de cette classe un serveur pur r alis e sans utiliser les services d aucune autre classe On d finit dans l impl mentation des op rations internes qui se r sument des appels aux syst me d exploitation sous jacent Ces appels sont exprim s en utilisant des primitives d finies par le standard ANSI du langage C et nous utilisons pour cela la syntaxe d finie par le langage Eiffel pour l appel de routines crites dans un autre langage Pour all ger l impl mentation de la classe on s est dispens de traiter les cas d erreur qui pourraient tre lev s par l appel aux primitives C Une impl mentation compl te devrait bien entendu d finir une politique de gestion des erreurs Pour cette classe L ObCS d impl mentation reste identique l ObCS de sp cification int grant simplement les appels aux op rations internes en tant qu actions des transitions Class Implementation Fichier Types PtFile Repr sentation ad quate pour le type C File Attributes chemin STRING tampon STRING stream PtFile Operations FPosition INTEGER is Indice du caract re courant dans le fichier external fpos language C do r
276. pt s l ordonnancement des invocations il suffit pour cela d affecter une fonction de tri la place param tre du service sur lequel on souhaite d finir une priorit Le m canisme de tri le plus souvent utilis sera celui de la File FIFO dans lequel les ex cutions de service ont lieu dans l ordre des invocations Toutefois toutes les primitives de tri d crites au II 2 7 sont applicables aux places param tres on pourra ainsi par exemple sp cifier que les requ tes pour un service doivent tre trait es dans l ordre induit par la valeur d un de ses param tres et permettre ainsi un serveur de d finir des priorit s entre ses diff rents clients par exemple Syntaxiquement l ordre de traitement des invocations d un service sera d clar lors de la sp cification de celui ci en utilisant les m mes mots cl s que pour sp cifier l ordonnancement d une place La figure VLS illustre quelques sp cifications possibles de priorit s sur les invocations en prenant l exemple du travail quotidien d une secr taire 176 VI 2 Ordonnancement des invocations Class Specification Secr taire Services R ponds_au_t l phone Hard FIFO Les appels t l phoniques sont mis en attente et trait s dans l ordre d arriv e Envoie _r glement lt f Fournisseur m Montant gt Soft Descending m Les r glements sont transmis aux fournisseurs en donnant la priorit aux montants les plus lev s
277. qu il contient et les donn es que ces processus manipulent Une donn e d un syst me est caract ris e par son caract re passif vis a vis des flots de contr le qui la manipulent elle n est l origine d aucun flot de contr le elle ne poss de aucun flot de contr le interne et elle n impose aucune contrainte fonctionnelle d activation sur les services qu elle offre A la lumi re de la discussion de la section pr c dente nous pouvons d finir comment une entit de ce type que nous nommerons objet passif est caract ris e dans le formalisme des Objets Coop ratifs D finition VI 2 Classe d Objets Passifs On appelle classe d objets passifs une classe d Objets Coop ratifs dont tous les services publi s sont des Data Flows Une instance d une telle classe sera appel e objet passif La fa on dont cette d finition caract rise les objets passifs est voisine de celle de la m thode HOOD 1 3 avec quelques diff rences toutefois e HOOD pr cise que les objets passifs n ont pas d ObCS dans notre cas ils serait plus correct de dire que l ObCS de sp cification des objets passifs est trivial non connexe car constitu exclusivement de transitions de services isol es et que leur ObCS d impl mentation consiste uniquement assurer l exclusion mutuelle entre les services L avantage de cette approche est que la s mantique d un objet passif utilis par plus d un objet actif est pr cis ment d finie ce qui n e
278. que dans la section suivante en montrant comment ordonner les jetons l int rieur des places d un r seau 2 7 Ordonnancement des jetons du marquage Lorsque le marquage des places est constitu d entit s qui ont une valeur et non pas de jetons indiff renci s il peut tre pertinent de se pr occuper de l ordre dans lequel les jetons vont quitter la place par occurrence d une transition Cet ordre peut tre d fini en fonction de la valeur des jetons on parlera alors de place tri e ou en fonction de leur ordre d arriv e dans la place place g r e comme une pile ou comme une file D finition IL 35 Crit re de tri d une place On app le crit re de tri d une place p une fonction Tri Trip Type p gt D o D est un domaine sur lequel est d finie une relation d ordre par exemple les entiers les cha nes de caract res La fonction Trip permet d ordonner les jetons pr sents dans la place suivant un crit re d pendant de leur valeur D finition 11 36 Place tri e Une place p sera dite non tri e si Tri est une fonction constante ou si aucun crit re de tri ne peut lui tre associ Dans le cas contraire p sera dite place tri e 61 II 2 Extension des RPO On ne peut associer un crit re de tri Trip une place p que si Vte T Pr p t e VU U c est dire que tout arcs sortant de p est tiquet par un seul tuple et non par un multiensemble de tuples Le tri d une place p s
279. ques de structuration qui s y appliquent L approche Objet fournit les concepts qui permettent de structurer un mod le l image du syst me qu il d crit encapsulation donn es traitements classification h ritage relation de type client serveur Les r seaux de Petri quant eux permettent l expression du comportement des objets et de la dynamique de leur coop ration Un Objet Coop ratif est muni comme dans un langage Orient Objet classique d une structure de donn e qui mod lise son tat et d un ensemble d op rateurs ou services destin s faire voluer cet tat Il est de plus pourvu d un comportement mod lis par un R seau de Petri Objets Ce comportement d finit les r gles d volution de l objet l accessibilit des services qu il offre en fonction de son tat et r ciproquement l influence de l ex cution des services sur son tat La communication entre objets s effectue par invocation de services suivant une architecture de type client serveur Le protocole de communication est lui m me d fini par un r seau de Petri Il est donc possible dans un syst me de mod liser le comportement des objets et les communications qu ils entretiennent de telle sorte que l on puisse exprimer la concurrence aussi bien entre les diff rents objets qu au sein du m me objet Une classe d Objets Coop ratifs peut tre d crite suivant deux points de vue Sa sp cification est destin e aux cli
280. qui est fait dans les langages objets fortement typ s tels que Eiffel Meyer 90b ou C Stroustrup 87 10 I 1 Les fondements de l approche Objet 1 2 Sp cification et impl mentation des composants logiciels La possibilit de distinguer la sp cification d un composant logiciel de son impl mentation est un facteur cl pour la ma trise de la complexit d un syst me et une des techniques de base pr conis e par le g nie logiciel C est aussi un des principaux apports de la th orie de Types Abstraits de Donn es l approche objet e La distinction entre sp cification et impl mentation favorise l abstraction de donn es et le masquage d information et permet donc l utilisateur du composant de rester ind pendant des changements qui pourraient intervenir dans l impl mentation de celui ci e Cette distinction permet d envisager plusieurs impl mentations possibles pour la m me sp cification et ainsi de tester plusieurs alternatives de conception sans pour autant remettre en cause l architecture du syst me e Elle permet de diff rer l impl mentation d un composant sans entraver le d veloppement d autres parties du syst me voire de confier cette impl mentation d autres quipes de concepteurs pour peu que la sp cification en soit clairement d finie La distinction entre sp cification et impl mentation traduit les deux vues diff rentes que l on souhaite avoir sur un composant du syst me
281. qui n est pas une variable d entr e d apr s la d finition 11 20 ceci correspond la cr ation d une nouvelle instance de la classe ANY dont le nom est d pos dans la place T te de File Pour que ce motif fonctionne effectivement comme une file il est n cessaire que les places T te de File et Queue de File poss dent le m me marquage initial un nom d objet quelconque de la classe ANY Pour illustrer davantage le fonctionnement de ce motif et se convaincre qu il fonctionne bien comme une file nous allons lister l volution des marquages lors de s quences de tirs de transition en v rifiant que seul les franchissements qui respectent l ordre FIFO sont l gaux Pour l exemple nous compl tons la d finition des places de la mani re suivante Exemple Type Any Personne Mathieu Marc Luc Jean Places T te de file Queue de file lt a ANY gt File lt p Personne avant ANY apr s ANY gt Le tableau ci dessous liste l volution des marquages dans le cas de l arriv e successive de Mathieu Marc Luc et Jean dans la place Par commodit on notera les noms d objets sous la forme Classe Num ro_d_instance ainsi ANY 4 d signe la quatri me instance de la classe ANY Marquage atteint Queue de file T te de file lt ANY 1 gt Enfiler lt ANY 1 gt lt Mathieu ANY 1 ANY 2 gt lt Mathieu gt lt ANY 1 gt lt Mathieu ANY 1 ANY 2 gt lt Marc ANY 2 ANY 3 gt lt ANY 1 gt ANY 1 gt
282. r ciser les modalit s de la communication entre l objet client et l objet serveur dans une requ te de service 4 6 Communication par rendez vous La Figure III 15 illustre une configuration typique de la communication entre un objet client et un objet serveur en montrant des extraits de leur ObCS respectifs Comme nous l avons pr cis au II 4 toute communication entre objets est d finie dans l ObCS du client par des TI transitions dont l action est une invocation et dans l ObCS du serveur par un couple de transitions transition d accord transition de retour mod lisant l ex cution de ce service 113 II 4 Impl mentation d une classe lt param x gt END Service retour Figure IIL15 Les deux c t s d une invocation La s mantique intuitive que nous donnons cette construction est proche du rendez vous du langage Ada toute communication est une synchronisation entre deux flots de contr le Le flot de contr le appelant est bloqu jusqu ce que l objet appel accepte la requ te et en termine l ex cution Les deux flots de contr le reprennent alors leur ex cution ind pendante Le RPO de la Figure III 16 explicite cette s mantique en pr cisant la fonction des places et transitions qui interviennent dans l accomplissement de la communication c t client la TI est clat e en une transition d appel et une transition de compl tion connect es par une place d attente C t serveur u
283. r f rencent d autres RdP qui est la base de notre formalisme La discussion ci dessus est donn e sans justification Tous ces points seront abondamment repris et d taill s au chapitre V qui traite de la s mantique formelle de notre formalisme 3 2 R seaux communicants Parmi les approches les plus caract ristiques des approches de composition des RdP nous d taillons ici celle de Y Souissi et G Memmi Souissi 89 Les objectifs de cette approche sont de trouver des techniques de composition et de d composition des RdP qui pr servent le comportement et notamment les bonnes propri t s afin de permettre la construction modulaire d un syst me et de d duire se propri t s par l analyse de ses composants l mentaires L originalit de l approche et de consid rer qu une communication entre RdP implique en fait trois r seaux et non pas deux savoir les deux r seaux qui communiquent et le m dium de communication lui m me repr sent comme un r seau On recherche ensuite comment les propri t s telles que la vivacit se conservent depuis les r seaux qui communiquent jusqu celui qui r sulte de leur communication en fixant des contraintes structurelles uniquement sur le m dium Quatre formes de m dium de communication sont tudi es par places communication unidirectionnelle par rendez vous par processus s quentiel ou par bloc bien form 75 II 3 Structuration des mod les de R
284. r sent en Figure V 20 ou l on s est simplement dispens de faire figurer les transitions repr sentant les services SETgauche SETdroite et garnir On remarque notamment les places voisin de droite et voisin de gauche qui sont la traduction des attributs gauche et droite de la classe 164 V 6 Prise en compte des classes composites Pas de baguette Pas de baguette lt id gauche gt lt id droite gt lt gauche self lt droite self gt lt id self lt id self gt lt gaucHe id self gt lt gauche id self gt lt gauche self lt bg self gt lt bg bd selfh lt bg self gt lt bd self gt lt bg bd Legende Arcs originaux Lo Macro donne baguette gauche gt UE Macro donne baguette droite Figure V 20 WSCS de la table de philosophes La structure du WSCS peut para tre relativement complexe par rapport aux r seaux qui sont produits pour le m me probl me par une approche classique fond e sur les r seaux color s Jensen 81 Il faut toutefois remarquer les avantages suivants de notre approche e Le travail du concepteur consiste uniquement d finir la classe Philosophe qui d crit le comportement d une seule instance et reste donc tr s simple Le travail de repliage qui est du ressort du concepteur dans une approche par r seaux color s est ici compl tement automatique 165 V 6 Prise en compte des classes comp
285. ransmet un message x contenant la valeur de l attribut La continuation la r ponse un message n est pas n cessairement retourn e l envoyeur mais un acteur tiers sp cifi dans le message lui m me La continuation d un message peut tre l metteur lui m me ce qui permet de consid rer une communication du type question r ponse comme un cas particulier d un m canisme plus g n ral La d l gation Sall 87 Dans ce m canisme introduit par le langage Act 1 Lieberman 81 tout acteur a connaissance d un autre objet appel son proxy d l gu ou mandataire Si au cours de l ex cution un objet re oit un message qu il ne sait pas traiter il fera suivre ce message son mandataire qui pourra son tour le faire suivre son propre proxy Les langages d acteurs n ayant pas de notion de classe de nombreux auteurs Lieberman 86 Briot 87 ont propos d impl menter un m canisme comparable au polymorphisme au moyen de la d l gation les appels se propageant le long de la cha ne des proxy de la m me mani re qu ils remontent le long de la hi rarchie d h ritage en recherchant l impl mentation de la m thode ex cuter La notion d acteur de remplacement a t propos e dans les langages ACTORS Agha 86 ou PLASMA II Lapalme 89 pour remplacer le m canisme de d l gation La notion d affectation ou de changement d tat est alors remplac e par un m canisme de plus haut niveau le changeme
286. rces structur es hi rarchiquement Notons que comme dans une approche classique par moniteurs il peut exister des processus globaux au syst me non encapsul s dans des objets c Eiffel Le langage Eiffel Meyer 90a ne contient pas de primitives permettant la concurrence du moins dans sa version 3 commercialis e au jour o nous crivons ces lignes Toutefois Meyer 90b d crit un mod le Orient Objet de programmation concurrente et sp cifie des extensions possibles du langage pour prendre en compte ce mod le En termes de concurrence ses propositions peuvent se r sumer ainsi e Les objets communiquent par invocation avec une syntaxe d appel identique celle de Eiffel L unique mode de communication est donc l appel de type question r ponse e Un objet n est actif que lorsqu il traite un message c est dire lorsqu il est le destinataire d une invocation Ces deux m canismes eux seuls interdisent deux flots de contr le d voluer concurremment au sein de deux objets diff rents puisque le flot de contr le appelant est toujours bloqu en attente de la r ponse Un m canisme suppl mentaire est donc n cessaire pour permettre plusieurs flots de contr le d voluer en parall le __Ils agit du m canisme de l attente par n cessit lazy wait dont le principe est le suivant Un flot de contr le qui ex cute un invocation de la forme a x service peut voluer concurremment l ex c
287. rchie d h ritage puisque chacune a besoin de la marque qui contient les param tres de l appel pr sente chaque occurrence de l appel dans la place param tre r sultant de l ensemble de fusion Ce conflit quand lui ne cr e aucun ind terminisme dans l volution du r seau en effet la marque param tre de l appel contient galement le nom de l objet destinataire et ce nom n est pr sent que dans l ObCS d extension d une seule classe celle laquelle il appartient Le conflit est donc r solu dynamiquement et de mani re d terministe par unification sur la variable self Ce m canisme d unification sur la variable self impl mente la technique de liaison tardive late binding que l on rencontre dans tous les langages objets qui autorisent le polymorphisme Etape 6 Edition de liens Nous sommes pr ts ce stade produire un r seau unique pour tout le syst me tel que chaque occurrence d une TI d pose son param tre dans une seule et m me place et r cup re son r sultat dans 155 V 3 Construction du r seau global une seule et m me place Le m canisme de fusion d crit l tape pr c dente est tendu pour lier le c t client et le c t serveur de chaque requ te de service de la mani re suivante 1 On fusionne la place param tre de chaque transition d appel avec la place param tre de la transition d accord du service correspondant cette derni re est elle m me le r sultat de la fusion
288. re la prise en compte d une invocation qu il a adress e un serveur Action consistant en l appel par un objet client d un service publi par la classe d un objet serveur Le client fournit les param tres d entr e du service L objet serveur d une invocation est d not dans l ObCS du client par une variable d entr e de la transition d invocation ou par une r f rence du client Invocation non confirm e ObCS ObCS d extension Mode d invocation dans lequel le flot de controle qui a d clench une invocation chez un client continue sans attendre ni l ex cution ni la prise en compte de l invocation par le serveur Object Control Structure ou structure de contr le d objet L ObCS d une classe d crit le comportement des objets instances de cette classe et pr cise son mode d emploi Pour une classe deux ObCS sont fournis l ObCS de sp cification et l ObCS d impl mentation Un ObCS est d crit par un R seau de Petri Objets et par la correspondance entre les services offerts par l objet et des transitions de ce r seau Etape interm diaire de la construction du WSCS l ObCS d extension d une classe est un RPO pouvant faire voluer un nombre quelconque d instances de cette classe ObCS d impl mentation D crit le fonctionnement interne d un objet en pr cisant notamment son activit spontan e et sa Coop ration avec d autres objets du syst me ObCS de sp cification Objet actif Objet passif Objet prim
289. rer il suffit que le nom et le nombre des services n volue pas que la signature de ces services reste constante et que les attributs publics de la sp cification soient conserv s dans l impl mentation Ces contraintes sont assur es par le formalisme en localisant ces informations dans la sp cification et en ne les dupliquant pas dans l impl mentation La coh rence de la dynamique entre les deux descriptions d une classe est plus difficile assurer Il faut que l impl mentation que l on donne reste conforme la sp cification et que l objet que l on impl mente se comporte comme souhait par le sp cificateur Dans le formalisme des objets coop ratifs le comportement est d crit aussi bien en sp cification qu en impl mentation par un R seau de Petri Nous pouvons d s lors caract riser de mani re formelle la coh rence entre sp cification et impl mentation en utilisant les techniques d analyse statiques d velopp es pour les RdP Le principe que nous avons retenu est l analyse et la comparaison des langages accept s par les ObCS d impl mentation et de sp cification Nous avons d fini un crit re formel sur ces langages qui permet d assurer que l on a correctement impl ment la sp cification Ce point est repris et d taill au chapitre IX o nous avons regroup l tude des possibilit s d analyse offertes par les Objets Coop ratifs 6 POUVOIR D EXPRESSION DU FORMALISME L utilisation du formalisme des
290. res suivants D finition IX 2 Crit re d honn tet Un serveur sera dit honn te s il peut toujours fournir un r sultat pour une requ te accept e sans avoir pour cela accepter d autres requ tes voe L N M Y s service de N 20 T Tac o a L N M et Sac 9 0 Sret Pour prendre une analogie un entrepreneur de travaux publics qui commencerait la construction de votre maison tout en sachant qu il n a pas les fonds n cessaires pour la terminer et qu il lui faudra donc recevoir d autres commandes pour pouvoir mener la v tre son terme serait un serveur malhonn te D finition IX 3 Crit re de courtoisie Un serveur sera dit courtois s il ne peut fournir un r sultat pour un service qu apr s avoir au pr alable accept une requ te pour ce service V oe LAN M Y s service de N sac gt Sret 228 IX 2 V rification de l ObCS d un serveur En quelque sorte le serveur doit r pondre seulement s il a t interrog L honn tet et la courtoisie peuvent tre v rifi es pour les RPO des ObCS sans la variable id identificateur d appel car cette valeur n est utilis e par le serveur que pour viter de m langer des jetons provenant de deux invocations diff rentes Pour ex cuter l tape 3 du proc d de construction du WSCS V 3 on a besoin d un chemin entre la place param tre d un service et sa place r sultat L existence d un tel chemin est assur e par le crit re
291. restant tr s proche de la structure physique des l ments de l atelier Dans cette d composition chaque objet correspond un l ment concret du syst me de production par exemple un module de transport ou une cellule robotis e Toutes les places correspondent a des emplacements concrets on a cependant op r quelques regroupements notamment pour les modules de transport ayant une capacit sup rieure a 1 En effet il n y a pas lieu dans un tel syst me de dissocier une fonction de l organe qui l assure et de plus cela favorise la r utilisation des composants La pr sentation de la solution se fera d une mani re top down en pr sentant d abord les classes les plus g n rales qui sont des classes composites pour en arriver aux plus primitives Bien entendu ce n est pas dans cette ordre que le processus de mod lisation a exhib les classes du syst me la conception Orient e Objet favorise en effet la r utilisation des composants et la plupart des classes les plus simples bandes transporteuses etc pourraient tre r utilis es dans le contexte d un atelier compl tement diff rent Les classes composites de plus haut niveau Atelier et Il t ont t produites par assemblage ou agr gation d l ments plus simples d ja d finis On donne en Figure VII 6 les relations d h ritage et de composition entre les diff rentes classes du syst me 195 VII 1 Mod lisation d un atelier flexible Racine D rivat
292. ritage IV 2 et de composition IV 3 1 SYSTEMES D OBJETS COOPERATIFS Dans le formalisme des Objets Coop ratifs la seule unit de conception est la classe d objets le formalisme n offre aucune construction d un niveau sup rieur telles par exemple que les m ta classes que l on rencontre dans la plupart des langages objet interpr t s Toutefois une classe est une construction statique une description en intention d entit s actives le m me ensemble de classes peut g n rer des ensembles diff rents d instances et il existe entre classe et instances une distinction comparable celle qui existe entre le texte d un programme informatique et les processus qui sont des occurences de l ex cution de ce programme Il faut donc donner au concepteur le moyen de d finir partir des classes dont il dispose un syst me ex cutable d Objets Coop ratifs Un des objectifs des mod les Orient s Objet est de favoriser la r utilisation d l ments de conception il est donc primordial de maintenir une s paration totale entre la d finition d une classe et celle d un syst me o cette classe est utilis e un des crit res de qualit pour la mod lisation d une classe tant son potentiel de r utilisation au sein de syst mes diff rents Un syst me d Objets Coop ratifs comme tout syst me informatique peut tre consid r sous deux point de vue le point de vue statique ou structurel d crit comment le syst me est constr
293. rrespond au fait qu une instance de CSP C doit remplir le contrat d une instance de C8 en plus de son propre contrat Ce crit re n est v rifier que pour les ObCS de sp cification s il est v rifi pour l ObCS de sp cification il l est aussi pour l ObCS d impl mentation d apr s le crit re d impl mentation fid le 5 USAGE DE L EQUIVALENCE SPECIFICATION IMPLEMENT ATION Dans la plupart des syst mes la relation d utilisation entre objets est une hi rarchie comprenant un grand nombre de niveaux Un petit nombre d objets sont des clients purs d autres sont des serveurs purs et les autres sont la fois clients et serveurs Un des atouts majeurs d un formalisme d di la conception structur e est de fournir la possibilit d examiner le syst me diff rents niveaux d abstraction Avec une approche descendante un objet la fois client et serveur est consid r uniquement comme un serveur et les objets de plus bas niveau sont cach s Avec une approche ascendante un tel objet est consid r comme tant seulement un client et les objets de plus haut niveau ne sont pas pris en compte 230 IX 2 V rification de l ObCS d un serveur Gr ce l quivalence entre les ObCS de sp cification et d impl mentation le formalisme des Objets Coop ratifs offre au concepteur la possibilit int ressante d obtenir des mod les ex cutables chaque niveau d abstraction Le proc d de construction du WSCS peut tre
294. rt 87 la vision pratique ferait de Ellipse une sous classe de Cercle puisqu une ellipse a les m me caract ristiques qu un cercle avec l adjonction d un centre suppl mentaire ceci est bien entendu en contradiction avec la vision conceptuelle o Cercle est une sous classe de Ellipse avec la contrainte que les deux centres soient confondus La notion d h ritage va rendre possible les constructions suivantes e La surcharge Une classe d riv e peut fournir une nouvelle impl mentation pour un service offert par un de ses anc tres Toutefois si on d sire conserver l h ritage sa s mantique de sous typage la signature des services ne peut voluer que dans le cadre de contraintes tr s strictes formalis es dans America 87 D finition I 2 Sous type A est un sous type de A si et seulement si pour tout service s p1 typea Pi typeAj Pn typeAn type _r sultata export par A poss de un service de m me nom s p1 tYPEA 1 Pi typeA i Pn typeA n type _r sultata tel que Vie 1 n typeaAi est un sous type de typea et type r sultata est un sous type de type r sultata D autre part la surcharge d une op ration peut changer son impl mentation mais doit conserver sa s mantique Dans Eiffel la s mantique d une op ration est exprim e par ses pr et post conditions la pr servation de la s mantique d une op ration au long de la hi rarchie d h ritage peut a
295. rt x x 3 Soient x1 E ye E X Xj0y support x support x1 U y 4 Soient x X2 N E x x x2 support x support x1 U support x2 5 Soient x1 N E ne N x n X support x support x c D finitions pr liminaires sur les Types de Donn es e On consid re deux sortes de types Les types simples INTEGER REAL Les types classe structur s par la relation d h ritage e Soit C un ensemble de types on note Cg l ensemble des types simples de C et Ce l ensemble des types classes de C On a Cg AN Ce et Cs U Ce C D finition IL 12 Domaine d un type On d finit le domaine d un type t not Dom t par 41 IL 1 Les R seaux de Petri Objet i sit est un type simple Dom t est le domaine des valeurs de t dont les l ments sont des constantes ii sit est un type classe Dom t est l ensemble des noms d instance de t Une entit de type classe sera appel e un objet ou une instance de sa classe Si C est On note U i C Dom t l union des domaines des valeur des types de C On d finit galement la fonction type Type Ue gt C u gt t tel que u Dom t D finition 11 13 Valeur d une entit A chaque l ment de U peut tre associ e une valeur i Pour les l ments de domaine d un type simple t Val Dom t Dom t est la fonction identit ii Pour les l ments du domaine d un type classe t les noms d objets l espace d
296. ruit Type pr d fini Type simple WSCS Dans l ObCS de sp cification transition associ e un service publi par la classe et qui mod lise ses conditions d activabilit Transition qui n est pas associ e l ex cution d un service et qui mod lise une volution interne de l tat d un objet Type dont le domaine de valeur est l ensemble des nom des objets de cette classe Les variables de type classe sont appel es r f rences Type simple construit partir d autres types par application d un constructeur de type yp p p ypes par app yp Un des types simples suivants INTEGER REAL CHARACTER BOOLEAN STRING Type pr d fini ou type construit dont les instances sont manipul es par valeur Whole System Control Structure C est un r seau de Petri Objets d crivant la structure de contr le d un syst me d Objets Coop ratifs construit partir des ObCS des classes qui composent ce syst me 240 Glossaire 241 Bibliographie Agha 86a Agha 86b Agha 90 Alla 87 America 87 Andre 82 Andr 81 Audureau 87 Audureau 88 Bako 90 Barron 82 Barthet 86 AGHA G Actors A Model of Concurrent Computation in Distributed Systems Series in Artificial Intelligence Cambridge Ma USA MIT Press AGHA G An Overview of Actor Languages SIGPLAN Notices Vol 21 n 10 October 1986 AGHA G Concurrent Object Oriented Programming Communications o
297. rveur peut tre d not soit par une variable d entr e de la TI soit par un attribut r f rence de la classe cliente Les param tres de sortie du service sont affect s a des variables de sortie de la transition L invocation est la mat rialisation d un flot de contr le entre l objet client et l objet serveur La figure I 9 montre une TI o l objet serveur et le param tre d entr e transmis sont d not s par des variables d entr e de la transition le service invoqu renvoie un couple de valeurs dont la figure illustre l affectation 4 des variables de sortie de la transition O 106 II 4 Impl mentation d une classe ObCS P1 lt x Serveurl gt P2 lt y Serveur2 gt P4 PS lt i INTEGER gt lt a b gt x service lt y attr gt Class Specification Serveur2 Attributes attr INTEGER Figure III 10 Transition d invocation et d acc s Le deuxi me moyen de communication entre objets est l acc s par un objet client un attribut publi par un objet serveur on rappelle qu un attribut public est accessible en lecture seulement La syntaxe en est elle aussi classique serveur attribut_public Une transition qui contient une telle expression sera appel e une Transition d Acc s TA Il faut remarquer qu une transition peut tre a la fois TI et TA comme le montre la Figure III 10 L acc s un attribut ne modifie pas l objet serveur un tel acc s mat rialise donc simplement un flot de donn
298. s E D Falkenberg and P Lindgreen Editors Elsevier Science Publishers B V North Holland 1989 HEWITT K Viewing control as patterns of message passing AI Magazine 3 8 1977 HEWITT C et al A Universal Modular Actor Formalism for Artificial Intelligence Proc of Int Jnt Conference on Artificial Intelligence 1973 246 Hewitt 77 Hoare 69 Hoare 74 Hoare 78 Hollinger 85 Hollinger 86 HOOD 89 Horn 87 Howard 76 Huber 89 Hur 87 IBM 89 ICSE 12 Jantzen 79 J rvinen 90 Bibliographie HEWITT C BAKER H Laws for Parallel Communicating Processes IFIP 77 Toronto 1977 HOARE C A R An axiomatic basis for computer programming Communication of the ACM 12 10 1969 HOARE C A R Monitors An Operating System Structuring Concepts Communications of the A C M Vol 17 N 10 pp 549 557 1974 HOARE C AR Communicating Sequential processes Communications of the A C M Vol 21 N 8 pp 666 6771978 HOLLINGER D Utilisation pratique des r seaux de Petri dans la conception des syst mes de production TSI 0752 4072 1985 HOLLINGER D R seaux de Petri et Flavors pour la sp cification et la simulation de syst mes productiques in BI GL 48 pp 206 215 European Space Agency HOOD Reference Manual issue 3 0 ESA ref WME 89 173 JB Sept 1989 HORN C Conformance Genericity Inheritance and Enhancement in ECOOP 87 pp 269 280 HOWARD J H
299. s Consultation Services Peut_traiter lt pal Palette gt lt r Boolean gt is do r FALSE end Peut_traiter Reste_a_droite lt pal Palette gt lt r Boolean gt is do r Peut_traiter lt pal gt end Concerne Entree GCircule GSortie lt Palette gt Entree DCircule DSortie lt Palette gt LA GCircule lt pal gt al i lt pal DCircule capa 2 Figure VII 16 Impl mentation de la classe Transport_double b La classe Entree_ilot La classe Entree_ilot se comporte la fois comme un module de transport simple et double ce qui n est pas surprenant car elle assure l interface entre le distributeur constitu de module de transports une voie et les ilots constitu s de modules de transport deux voies Nous sommes donc en pr sence d un cas d h ritage multiple cf IV 2 d et il nous faut traiter un conflit de nom car les classes Transport et Transport Double publient toutes deux un attribut Pr c dent Ceci est fait par un renommage dans la clause d h ritage 205 VIL 1 Mod lisation d un atelier flexible L ObCS de sp cification indique seulement que toute palette re ue deviendra disponible pour un des services Gauche droite ou Transmettre On peut v rifier que ce comportement est compatible au sens d fini en IX 4 avec le comportement des deux classes anc tres Class Specification Entr e _Ilot Inherit Transport rename Pr c dent as
300. s mantique formelle d un tel syst me en donnant la technique de construction du r seau global Le chapitre VI propose quelques extensions possibles au formalisme La troisi me partie expose deux tudes de cas trait es au moyen de notre formalisme Chapitre VII un atelier flexible de fabrication et une interface personne logiciel On expose au chapitre VIII les techniques permettant d ex cuter un mod le et le chapitre IX regroupe les diff rentes approches d analyse formelle des propri t s qui peuvent tre appliqu es aux classes et aux syst mes d Objets Coop ratifs Introduction Le monde r el n est ni plat ni s quentiel mais au contraire multidimensionnel et hautement parall le Grady Booch Le travail pr sent dans ce m moire se trouve au confluent de deux axes de recherche importants d une part les travaux portant sur l expression de la concurrence au sein de l approche Objet et d autre part les travaux relatifs aux R seaux de Petri de Haut Niveau et aux techniques de structuration qui s y appliquent Les concepts fondamentaux de l approche Orient e Objet sont aujourd hui largement adopt s dans le domaine du d veloppement de logiciel L un des int r ts majeurs de cette approche est que les abstractions du mod le restent proches des entit s du syst me mod lis Un mod le Orient Objet est alors plus simple comprendre valider faire voluer et r utiliser que des mod les produi
301. s au m me instant bien que chaque objet ne puisse effectuer qu une seule op ration la fois 5 INTERPRETATION INTUITIVE ET FORMELLE DES OBCS En s appuyant sur l exemple pr c dent nous allons donner ici une justification de la correspondance entre la s mantique intuitive d un ObCS d crite en III 4 5 et sa s mantique formelle Cette justification se fonde sur un invariant du WSCS que nous venons de construire Pour ie N on notera prj la projection d un n uplet sur son i composant On d finit alors e Fpl pri FReady FSReady Fp4 fonction identiquement nulle e Fp2 Fp3 FP5 pr2 Fpi pr2 pr pour les places d attente sur les requ tes de cr ation d objet Fpi pr3 pr2 pour les places d attente sur les requ tes de OP1 et OP2 Fpi pr2 pour les places param tres et r sultats places e FpGi Fpsi Fps2 pr3 W Fp peP Alors W C 0 et W est un invariant du WSCS En fait l identificateur d appel pr sent dans la place d attente d une Transition d Invocation est le m me que celui qui circule dans le chemin de places entre la transition d accord et la transition de retour et les places d attente sont implicites Berthelot 86 par rapport leur composant de type Identificateur Lorsque une s quence de transitions peut tre franchie dans un OpCS i e le serveur est en mesure d accomplir le service les transitions de requ te et de completion de la TI sont franchies dans le WSCS
302. s composites Classe dont les instances sont compos es d instances de classes atomiques ou composites par opposition classe atomique Objet auteur d une invocation Pour cette invocation il fournit le nom de l objet serveur et les param tres d entr e du service et en r cup re les valeurs de retour Par extension Classe cliente Classe dont l impl mentation contient des T1 Objet dont la classe ne publie pas de service Par extension Classe de clients purs racine du graphe de la relation d utilisation El ment de la description d une classe d objets qui sp cifie son activit et son volution Le comportement d un objet est d crit par l ObCS de sp cification ou d impl mentation de sa classe El ment de la description d une classe d objets qui sp cifie la nature des relations qu un objet entretient avec d autres objets du syst me La coop ration d un objet est d crite par l ObCS d impl mentation de sa classe Op ration d crivant comment les instances d une classe doivent tre cr es et initialis es Toute classe publie une op ration create qui d finit le marquage initial de l ObCS de ses instances 237 Estampille d appel Garde Invocation Glossaire El ment d information g n r lors de l invocation d un service permettant l acheminement correct des r sultats vers le client de l appel Valeur enti re sp cifiant le nombre d unit s de temps pendant lequel un client est dispos attend
303. s dans son impl mentation sans qu il soit n cessaire de les r p ter Les types export s avec la mention private doivent recevoir une d finition explicite dans l impl mentation 4 2 Op rations internes L impl mentation d une classe peut d finir un ensemble d op rations internes exprim es dans un langage algorithmique quelconque dans la suite on adoptera pour les op rations internes la syntaxe du langage Eiffel Les op rations internes sont utilis es pour faire des calculs exclusivement dans le contexte de l objet et non pas pour effectuer des communications Ces op rations peuvent tre proc durales ou fonctionnelles avec une liste de param tres d entr e et un param tre de sortie Les op rations internes peuvent faire usage dans leur code de leurs param tres de variables locales ou des attributs d finis dans la structure de donn e de la classe Le code d une op ration interne ne peut pas invoquer une variable de type classe ni acc der ses attributs publics Cette restriction est tr s contraignante et restreint beaucoup l tendue de ce que l on pourra exprimer dans les algorithmes des op rations internes elle est toutefois n cessaire pour que la s mantique du formalisme puisse tre enti rement d crite en restant strictement dans le cadre des r seaux de Petri il est n cessaire que toute communication entre objets soit explicite et non pas cach e au sein d algorithmes Toute communication en
304. s de nombreuses situations puisqu elles peuvent uniquement tester ou apparier des valeurs d j substitu es aux variables d entr e de la transition et non pas faire des choix portant sur la globalit du marquage d une place ou des choix non locaux une seule transition 51 II 2 Extension des RPO Substitutions X ES 134s 3 a SF IX gt 3 ye o gt 5 x gt 4 y gt 3 x gt 4 y gt 5 Figure II 3 Ind terminisme li aux valeurs des jetons La Figure II 3 illustre l ind terminisme li aux valeurs des jetons sans pr condition la transition T7 est franchissable avec les quatre substitutions cit es en l gende L ind terminisme est lev par la pr condition qui autorise le franchissement uniquement avec la substitution x 4 y 3 2 2 Registres Lorsque l on d crit un syst me il est fr quent de rencontrer des variables d tat dont la valeur est la fois souvent n cessaire et toujours disponible Si le syst me volue de mani re concurrente l acc s et la modification sur ces variables doivent tre effectu s en exclusion mutuelle Une telle variable est souvent d sign e comme une variable globale d un syst me Pour mod liser de telles variables on inclut dans la d finition d un RPO la donn e d un ensemble de registres D finition 11 27 Registres d un RPO Soit p P p est une place registre si et seulement si Vte T te p ete p Toutes les transitions en entr e de p fi
305. s la suite nous traitons uniquement de la conception du module Dialogue en r f rence au mod le Seeheim de l application bien entendu le module Abstraction peut lui aussi tre mod lis par Objets Coop ratifs si le domaine d application s y pr te par exemple si l on mod lisait l interface utilisateur d un proc d concurrent Une interface sera con ue comme un syst me d Objets Coop ratifs dont les objets primitifs publient des services d interface cf IV 1 2 Pour compl ter sa conception le mod lisateur doit d finir des liens entre les widgets l ments de la Pr sentation boutons menus etc et ces services d interface en sp cifiant par l interm diaire de quels l ments un service d interface est invoqu Trois types de relation existent entre widgets et services d interface e relation 1 1 un widget est associ un service d interface et un seul C est le cas par exemple ou un service est d clench par le clic de l utilisateur sur un bouton ou par la s lection d un l ment de menu e relation n 1 plusieurs widgets sont associ s au m me service Un tel cas signifie que plusieurs actions diff rentes de l utilisateur provoquent la m me volution du dialogue L exemple trait plus loin dans ce chapitre pr sente une relation de ce type e relation 1 0 un widget n est associ aucun service d interface L interaction de l utilisateur avec le widget n a donc aucune influence
306. s n uplets stock s dans une table d une Base de Donn es BD relationnelle L interface doit permettre l ajout de nouveaux n uplets la suppression de n uplets la s lection et la modification de ceux qui sont d j stock s dans la table Le but que l on se fixe est de fournir un dialogue totalement pilot par l utilisateur par opposition aux dialogues pilot s par menus que l on rencontre dans la plupart des Syst mes de Gestion de Base de Donn es SGBD relationnels Pour pr senter notre solution nous nous appuyons sur le mod le de Seeheim en d crivant successivement sa Pr sentation ou repr sentation externe son Abstraction et son Dialogue a Pr sentation L interface propos e est g n rique en ce sens que le dialogue qu elle d crit ne d pend pas de la structure des n uplets en cours d dition nombre et type de leurs champs et que la m me structure de dialogue doit pouvoir tre propos e pour toutes les tables de la BD On suppose simplement que toutes les tables ont un attribut qui leur sert de cl et dont la valeur sert donc identifier de mani re unique chacun des n uplets de la table 215 VIL2 Interfaces Personne logiciel Case de fermeture Editeur de n uplets TEs Zone d dition Identifiant Attribut H DI m2 63 Attribut y E ltem 02 K mea Zone de Item 03 G d filement ltem 04 Zone de Item 05 el command Item 06 H Figure VII 23 Repr sentation externe de l diteur de n uplets
307. s nul doute applicables la plupart des dialectes de RdP de haut niveau e Nous avons prouv au chapitre V en construisant un r seau pr dicat transition le WSCS qui mod lise le comportement d un syst me d Objets Coop ratifs que les RdP de haut niveau sont suffisamment puissants pour d crire tous les concepts de l approche objet y compris l instanciation l acc s cha n aux attributs la relation d utilisation dynamique l h ritage et le polymorphisme ce qui notre connaissance n avait jamais t montr Durant toute la conception de ce formalisme nous avons eu le souci d en pr server la simplicit et l utilisabilit Nous avons eu la chance de rencontrer des personnes suffisamment motiv es pour bien vouloir valuer l ad quation du formalisme diff rents domaines et ces exp rimentations se sont r v l es riches d enseignements Nous sommes bien entendu conscients qu une utilisation du formalisme plus grande chelle ne peut tre envisag e sans disposer d un environnement support qui faciliterait la saisie des mod les leur v rification syntaxique et s mantique et qui supporterait les activit s de test de simulation et de prototypage C est dans cette voie que nous souhaitons nous diriger 235 236 Conclusion Glossaire Accus d ex cution Activit spontan e Arc d activation Arc de compl tion Attribut Classe atomique Classe composite Client Client pur Comportem
308. s transitions au m me service savoir montrer un ind terminisme dans le choix du traitement associ une demande de service 150 V 3 Construction du r seau global Cet ind terminisme sera d ailleurs fr quemment lev par la structure m me des ObCS voir par exemple l ObCS d impl mentation de la classe Fichier_prot g mais le concepteur peut fort bien souhaiter conserver cet ind terminisme jusqu l impl mentation L ObCS de la classe ServeurG tel qu il r sulte de l tape 2 est illustr en Figure V 7 Etape 3 Gestion de l instanciation dynamique On pourrait croire d apr s le processus de construction tel qu il a t d crit jusqu ici que la cr ation dynamique de nouveaux objets dans le syst me va entra ner la g n ration de nouveaux r seaux repr sentant leurs ObCS et que le syst me est donc mod lis par un ensemble de r seaux dont la structure volue d une mani re comparable l extension dynamique des transitions d invocation d crite dans Huber 89 Nous ne voulons pas cependant g rer un ensemble de r seaux qui volue dans le temps parce que c est renoncer la plupart des possibilit s de validation formelle li es la th orie des RdP toutes celles qui reposent sur l analyse de la matrice d incidence Au contraire notre but est de fournir un ensemble de r seaux d termin statiquement qui produise le m me comportement r sultant L tape 3 permet d obtenir ce r sultat en c
309. sa sp cification un objet composite est consid r comme un objet simple offrant au monde ext rieur un ensemble de services et publiant une description de son comportement sous la forme d un ObCS e Un objet client peut donc utiliser des objets serveurs atomiques ou composites de la m me mani re en invoquant des services publi s par leur classe D autre part les trois types de relation entre classes h ritage utilisation et composition sont ind pendants le m canisme de composition que nous introduisons ici reste compatible avec les constructions que nous avons d j pr sent es notamment e Un objet composite peut tre cr dynamiquement de la m me mani re qu un objet atomique par appel de la primitive Create e Un objet quelconque peut poss der des r f rences vers un objet composite un objet composite doit donc avoir un nom qui lui est propre diff rent de celui de ses composants e Une classe composite peut h riter d une classe atomique et r ciproquement Le fait d utiliser la composition est donc simplement une mani re particuli re d impl menter une sp cification e La relation de composition est r cursive un objet peut tre compos d objets eux m mes composites Class Specification Composite Exemple attributes attl INTEGER Services Svl lt P1 Typel gt Sv2 lt P2 Type2 gt lt R Type3 gt create P4 Type4 is end ObCS Description
310. se l autre comporte en sortie un arc de compl tion tiquet par les param tres de sortie cette transition est appel e transition de retour du service et d finit quand et comment le client sera inform de l accomplissement du service et quel r sultat il obtiendra Une transition d accord contient le nom du service auquel elle est associ e et une transition de retour contient ce m me nom pr fix par le mot cl End_ La transition d accord et la transition de retour peuvent ventuellement tre confondues et dans ce cas la transition contiendra seulement le nom du service Il peut exister plusieurs transitions d accord pour un m me service sp cifiant ainsi qu un service peut avoir plusieurs conditions de d clenchement diff rentes Il existe toutefois une et une seule transition de retour par service Invocations d autres objets Le premier moyen de communication entre objets est l invocation cf I 1 Cette communication est sp cifi e dans l ObCS d impl mentation par des transitions dont l action est un appel de services et qui sont appel es des Transitions d Invocation T1 La syntaxe d une invocation est classiquement la notation point e lt tuple de variables gt Serveur service invoqu lt param tres de l appel gt lt x gt lt p gt ObCS P1 P3 lt x Serveur gt P2 P4 P5 lt i INTEGER gt lt x Ze lt b gt Figure IIL 9 Exemple de transition d invocation L objet se
311. seaux de Petri de Haut Niveau e Communication par places partag es Le m dium de communication est constitu uniquement de places et on suppose de plus que l un des r seaux communicant n a aucune place d entr e dans l ensemble des places partag es Dans ce cas il est montr que la vivacit est pr serv e savoir que les deux propositions suivantes sont quivalentes Les sous r seaux communicants sont vivants Le r seau r sultant de la communication est vivant De plus un algorithme est donn pour calculer toutes les fronti res s paration lines dans un RdP afin de le d composer en sous r seaux communiquant par places partag es Bien entendu dans un r seau complexe il existera plusieurs d compositions possibles et il est probable qu une seule de ces d compositions donnera des sous r seaux pr sentant une unit fonctionnelle e Communication par processus s quentiel les processus s quentiels sont ici d finis comme une extension de ceux de Reisig 82 Si le m dium est un processus s quentiel ou un rendez vous qui en est un cas particulier des r sultats de conservation de la vivacit et du caract re born des r seaux sont obtenus e Enfin dans le cas de la composition par blocs bien form s les r sultats de Valette 79 sont repris et tendus pour montrer la pr servation de la vivacit Nous avons repris dans le formalisme des Objets Coop ratifs l id e int ressante de d finir p
312. siaJ Ta f H ORA 777 DID O PAAA AA lt o gt lt o gt SE AN O arcs initiaux 7 gt Lid 2 gt arcs introduits par O lt al id gensyn id gensyn lt 3 id gt gt O lt o id gt lt o id gt pr X zoa 0 1d gt I QT WILLE E lt 0 lt r gt r gt Figure V 6 ObCS de Pclient tape 1 On peut voir le r sultat de l tape 1 en Figure V 6 pour l ObCS de la classe Pclient seulement puisque les ObCS des deux autres classes ne comportent aucune TI Pour rendre plus explicite les transformations de structure apport es aux ObCS par le processus de construction on a associ une repr sentation graphique particuli re aux places et aux arcs ajout s explicit e en l gende 149 V 3 Construction du r seau global L usage des estampilles d appel a d j t d crit dans Sibertin 87 pour g rer les calculs r cursifs au sein des RPO Etape 2 Gestion de l ex cution des services Cet tape a pour but de permettre chaque serveur de recevoir des requ tes de service avec leur param tres et de fournir les r sultats de ces requ tes L ObCS d une classe serveur fait usage des estampilles d appel afin de ne pas confondre les jetons qu il manipule On a indiqu au I11 4 3 que l ex cution d un service s tend entre une transition d accord et une transition de retour pour chaque classe qui joue le r le de serveur dans le syst me et pour chaque service d fini dans ces classes on doit effec
313. sis MIT Project MAC TR 120 F vrier 1974 REIZIG W Petri Nets in Software Engineering in Brauer 86 250 Richter 85 Robinson 79 Ross 77 Rumbaugh 91 Sall 87 Senteni 89 Senteni 90 Sernadas 89 Sibertin 85 Sibertin 86 Sibertin 87 Sibertin 91b Sibertin 91 Sifakis 79 Bibliographie RICHTER G Clocks and their use for time modelling Information Systems Theoretical and Formal Aspects A Sernadas J Bubenko A Oliv Eds Elsevier Science Publishers B V North Holland IFIP 1985 ROBINSON J A Logic Form and Function the mechanization of Deductive reasoning Edinburgh University Press 1979 ROSS D T Structured Analysis a language for communicating ideas IEEE TOSE vol SE 3 n 1 1977 RUMBAUGH J BLAHA M PREMERLANI W EDDY F LORENSEN W Object Oriented Modeling and Design ISBN 0 13 630054 5 Prentice Hall 1991 SALLE P Langages d Acteurs et Langages Objets Le Langage Plasma Interkibernetik 87 Taragone SENTENI A SALLE P LAPALME G Modelling Complex Behavior in Discrete Event Simulation with Actors Proceedings of SCSC 89 Summer Simulation Conference Austin Tx USA July 1989 SENTENI A GIROUX S From Rock Bottom to Metalevel Actors Contribution to an Actor Programming Methodology in TOOLS 90 pp 167 181 SERNADAS A FIADEIRO J SERNADAS C EHRICH H D Tha Basic Building Blocks of Information Systems
314. solus par l introduction d un petit r seau interm diaire qui se charge de l instanciation des composants et de l indirection des requ tes l instance compos e vers les instances composantes ce RPO est appel le r seau de traduction de la classe composite Ce r seau d finit notamment quelle est l instance composante qui re oit l appel et quel est le service correspondant appeler Le r seau de traduction est la seule composante qui soit propre l objet composite en dehors de ce r seau un objet composite n est qu une enveloppe qui associe des objets composants et n a pas d existence en dehors de ces composants Le r seau de traduction est g n r automatiquement partir de la d finition de la classe composite Le r seau de traduction est en quelque sorte l impl mentation au moyen des RPO de la technique de transmission de message message forwarding Blake 87 utilis e pour implanter la hi rarchie de composition dans le langage Smalltalk Cette technique est galement proche de la d l gation des langages d acteurs Agha 86b un objet composite d l gue l ex cution de ses services ses objets composants Les deux sections suivantes montrent comment le r seau de traduction traite le probl me de l instanciation d un objet composite et celui de son invocation 6 1 Instanciation d un objet composite La cr ation d une instance composite est plus complexe que celle d une instance atomique elle n ce
315. ssite la cr ation des instances composantes et l invocation sur ces instances de services d initialisation cf IIL 3 5 Cette cr ation qui est une s quence d actions simples doit cependant tre per ue comme une action unique par l objet qui l effectue 160 V 6 Prise en compte des classes composites Une des caract ristiques d un objet composite est que les instances qui le composent ont entre elles une relation d utilisation statique or cette relation d utilisation est d finie au niveau d une instance par des r f rences qui sont contenues dans le marquage de son ObCS II est donc n cessaire d avoir un moyen d initialiser ces r f rences en s assurant qu elles ne pourront plus changer de valeur au cours de la vie de l objet ma_table Table create lt ma_table gt lt ma_table gt ma_table garnir riz lt ma_table gt Figure V 15 Instanciation et invocation d une classe composite On pourrait envisager de fournir toutes les r f rences n cessaires en tant que param tres de l op ration create mais cette solution n est pas satisfaisante car elle interdit les relations d utilisation cycliques entre instances Pour rem dier ce probl me on utilise les services d initialisation d finis au paragraphe III 3 5 et qui offrent une mani re standardis e de fixer la valeur initiale d un attribut La Figure V 15 montre un client qui instancie la classe composite Table IV 3 2 et invoque ensui
316. st mes modernes la file d attente d v nements et la boucle qui les traite est totalement invisible au programmeur qui se contente d crire les gestionnaires d v nements et de les associer explicitement aux diff rents d clencheurs de l interface boutons menus On peut qualifier plus pr cis ment la diff rence entre application conventionnelle et application pilot e par v nement L application conventionnelle pr sente un contr le centralis et des entr es r parties le contr le est localis dans la pile des appels de fonctions et on peut en examinant cette pile d terminer l historique des appels qui ont conduit l tat courant Les entr es sorties sont r parties dans tout le code car chaque module r clame des entr es l utilisateur et produit des r sultats L application dirig e par v nements pr sente un contr le r parti et des entr es centralis es seule la boucle principale de traitement d v nements effectue des entr es et les diff rents 213 VIL2 Interfaces Personne logiciel gestionnaires d v nements se synchronisent en acc dant en lecture et en criture un ensemble de donn es globales qui d finissent l tat courant du dialogue On peut r sumer cette diff rence fondamentale en disant que dans une application conventionnelle le contr le est fond sur l historique alors que dans une application dirig e par v nement le contr le est fond sur l tat Cowa
317. st pas le cas dans HOOD e HOOD interdit un objet passif d utiliser un objet actif notre d finition est moins restrictive car elle permet un objet passif d utiliser les data flows publi s par une classe d objets actifs Il faut remarquer d apr s la d finition VI 1 Data Flows que toutes les op rations offertes par un objet passif sont ex cut es par le client un objet passif n a donc pas de processeur d di si on prend la m taphore d un processus informatique ni d nergie vitale avec une m taphore biologique Sibertin 91 Un objet passif n est donc pas autonome et il est n cessaire qu un client actif l invoque et ex cute lui m me les op rations qu il offre Cette d finition a pour avantage d viter la distinction nette entre donn es et processus impos e par d autres approches On peut alors qualifier l aspect actif vivant ou autonome d un objet suivant une chelle tr s fine en descendant cette chelle de l actif vers le passif on trouverait 184 V1 4 Objets passifs Des classes qui ne publient que des services pas d attributs ni de data flows et qui ont une activit spontan e d crite par leur ObCS Ce sont les processus pas forc ment s quentiels du syst me et ils sont tr s faiblement coupl s leur environnement Des classes qui ne publient que des services et qui n ont pas d activit spontan e On peut les comparer des moniteurs IL 2 1 qui encapsulent une donn
318. sur l avancement du dialogue C est la cas des 214 VIL2 Interfaces Personne logiciel l ments de dialogues passifs tels qu une zone de texte ditable par exemple le fait que l utilisateur tape du texte dans la zone ne fait pas voluer le dialogue le texte qu il a tap quant lui pourra tre utilis plus tard dans l interaction Avec cette association entre widgets et services d interface on mod lise de mani re tr s pr cise la distribution du contr le entre l application et l utilisateur e Dans la plupart des cas l avancement du dialogue est pilot par l utilisateur qui invoque des services par l interm diaire des widgets Cette invocation provoque le franchissement d une transition de l ObCS qui fait voluer l tat du dialogue autorisant ventuellement de nouveaux franchissements et en inhibant d autres e Le service invoqu peut pr senter une OpCS complexe avec des Transitions Priv es TP ces transitions sont d clench es automatiquement sous le contr le de l application et mod lisent donc des encha nements obligatoires d op rations Barthet 88 e Enfin les dialogues modaux o l utilisateur est entra n dans une entr e sortie bloquante sont mod lis s comme des op rations internes appel es dans les actions des transitions 2 4 Exemple La sp cification de l exemple que nous traitons est tr s simple il s agit de d finir une interface g n rique de manipulation pour de
319. t elle pas aujourd hui p rim e supplant e par des concepts nouveaux plus puissants et plus g n raux 19 1 2 Mod les d objets concurrents Il nous appara t en fait qu un partie importante des travaux visant int grer la concurrence dans l approche Objet se r f rent parfois de mani re implicite aux concepts des moniteurs certaines approches consistent uniquement en une reformulation des concepts de moniteurs en termes d objets en y int grant des id es plus nouvelles telles que l h ritage ou le polymorphisme Dans l approche initiale de Hoare le moniteur est une entit passive l intersection des flots de contr les initi s par les entit s actives que sont les processus du syst me La concurrence effective du syst me est li e au fait que les processus voluent en parall le sauf aux points de synchronisation repr sent s par les entr es des moniteurs On a donc une dichotomie tr s nette entre entit s actives les processus et entit s passives les donn es partag es encapsul es dans des moniteurs a Trellis Owl Cette dichotomie se retrouve exactement dans l approche propos e par J E B Moss et implant e dans le LOO Trellis Owl Moss 87 Le domaine d application du langage est celui des syst mes de parall lisme gros grain large grain parallelism par opposition au parall lisme grain fin implant au niveau des instructions m me du langage ou par des architectures de type data flow ou
320. t attribut est impossible jusqu ce que l attribut re oive une valeur L op ration create aura fr quemment pour r le de donner une valeur initiale aux attributs de l instance Il n est toutefois pas toujours significatif de fournir les valeurs de tous les attributs au moment de la cr ation C est m me parfois impossible notamment lorsqu on souhaite avoir une relation d utilisation cyclique entre instances un exemple significatif est trait au IV 3 2 L interface d une classe est constitu e de services et d attributs qui sont accessibles en lecture seulement L acc s en criture a des attributs publics d une autre classe se fera donc comme en Smalltalk Goldberg 83 en fournissant des services con us cet effet Pour all ger la structure de l ObCS et pour faciliter la t che du concepteur deux m thodes d acc s un attribut sont pr d finies par le formalisme qui pr cise leur syntaxe et leur s mantique Un service d initialisation a pour but de fixer la valeur initiale d un attribut Par convention un tel service aura pour nom SETattribut o attribut d signe le nom de l attribut initialiser Un service d initialisation a un seul param tre en entr e qui d signe la valeur d initialisation de l attribut et n a pas de param tre en sortie Il ne peut tre ex cut qu une fois Un service de mise jour a pour but de changer la valeur d un attribut Un tel service a pour nom CHANGEattribut a un seul p
321. t franchissable sont construites par un m canisme de semi unification Robinson 79 chaque substitution associant une valeur pr sente dans une des places d entr e toute variable d entr e de t Si une variable est pr sente sur plusieurs arcs d entr e l unification sur cette variable r duit les possibilit s de franchissement car la valeur substitu e doit tre pr sente dans chacune des places d entr e La pr condition permet ensuite d liminer parmi l ensemble des substitutions admissibles celles qui ne v rifient pas le pr dicat Il peut rester plusieurs substitutions qui v rifient la pr condition et le choix parmi ces derni res est ind terministe 45 IL 1 Les R seaux de Petri Objet Substitutions Substitution x gt 3 y gt 3 T1 T1 x gt 3 x We 3 y gt 5 lt 4 gt x gt 4 y gt 3 x gt 4 y gt 5 CA Figure II 1 Construction des substitutions par semi unification La Figure II 1 montre deux transitions ne diff rant que par les inscriptions des arcs d entr e Dans le premier cas l ensemble des substitutions qui rendent la transition franchissable est le produit cart sien des marquages des places d entr e car les ensembles de variables sur les arcs d entr e sont disjoints Dans le second cas l unification sur la variable x restreint les possibilit s de substitution Cr ation d objets par un franchissement D finition II 20 Entit s cr es par un franchisseme
322. t un invariant ssi W C 0 avec C Post t p Pr t p peP te T est la matrice d incidence du r seau Pour les RPO et pour les r seaux pr dicat transition galement il existe une classe de pond rations pour laquelle ce r sultat est toujours valable D finition IL 25 Fonction uniforme Soit E un ensemble et n un entier positif On consid re des fonctions de El vers E qui sont des projections des permutations ou des r p titions de composants des n uplets F EHME 3he N J ppr 1 h gt 1 n V lt e n gt EP F lt e n gt lt eppr 1 amp ppr h gt 48 IL 1 Les R seaux de Petri Objet Une fonction F En gt Z E est uniforme si elle est une combinaison lin aire de telles fonctions Proposition Soit W Fp pe P une pond ration pour laquelle les Fp sont uniformes W est un invariant alg brique de ce r seau si et seulement si W C 0 Nous n avons pas connaissance d un algorithme qui calcule tous les invariants alg briques d un r seau Toutefois si des fonctions uniformes Fp sont fournies les techniques de calcul des invariants des RdP peuvent tre utilis es pour calculer les vecteurs d entiers ip pep tels que W C 0 avec Ces invariants sont moins puissants que les S invariants de Genrich 86 mais sont plus faciles calculer 49 2 EXTENSION DES RPO Nous allons dans ce chapitre introduire un certain nombre d extensions la d finiti
323. table de philosophes Nous allons illustrer la syntaxe de d finition d une classe d objets composites en traitant le probl me des philosophes Dijkstra 71 Cet nonc bien connu est un point de passage oblig pour tout mod le visant d crire des syst mes concurrents et l l gance de la solution que l on en donne permet de juger le degr d ad quation d un formalisme ce genre de probl me Pi N ORO Figure IV 6 Configuration d une table de philosophes Nous rappelons bri vement l nonc de ce probl me un certain nombre de philosophes japonais sont rassembl s pour le repas autour d une table ronde Entre chaque couple de philosophes se trouve une baguette Pour pouvoir se mettre manger un philosophe doit arriver se saisir des deux baguettes qui l entourent Figure IV 6 S il y parvient il conserve ses baguettes pendant un certain laps de temps avant d accepter ventuellement de les c der ses voisins On voit qu il s agit l d un probl me de partage de ressources les baguettes sont en nombre insuffisant pour permettre tous les philosophes de manger en m me temps Il est notamment impossible deux philosophes voisins de manger en m me temps La solution de ce probl me doit assurer qu une situation de blocage o par exemple chaque philosophe conserverait ind finiment une seule baguette ne pourra pas se produire Nous allons produire la solution ce probl me en deux temps to
324. te l instance composite cr e La Figure V 16 montre la structure du WSCS qui sera g n r par l instanciation de la classe composite en se limitant l ObCS du client et au r seau de traduction de la classe composite L ObCS d extension de la classe Philosophe sera construit et d taill ci apr s On voit que la classe composite m morise le nom de ses instances composantes dans des places attributs On utilisera ensuite le nom de ces composantes pour rediriger les invocations re ues par l instance composante 161 V 6 Prise en compte des classes composites lt P1 P2 P3 CREATE lt self P1 P2 P3 gt lt self P1 P2 P3 gt Chef_de_table Philosophe Create P1 ph2 Philosophe Create P2 ph3 Philosophe Create P3 de_tabl self lt Ph2 self gt ETgauche ph2 Figure V 16 R seau de traduction pour l instanciation d une classe composite 6 2 Invocation d une instance composite Le nom d un objet composite renvoy par l op ration Create est diff rent du nom de ses objets composants L invocation d un service une instance composite n cessite donc un m canisme de d codage simple d crit par le r seau de traduction de la classe composite et qui permet l instance composite de d l guer les invocations qu elle re oit vers ses composants Ce r seau d finit quelle est l instance composante qui re oit l appel et quel est le service correspondant a
325. te au r seau Il faut noter qu avec cette approche les valeurs des jetons re us de l environnement peuvent tre d finies par le r seau lui m me par unification sur les arcs d entr e des transitions de service ou par pr conditions et dans le cas contraire ne peuvent tre prises en compte Les m thodes classiques d analyse des RdP peuvent s appliquer au RdP sous jacent II 1 3 la cl ture d un ObCS de sp cification 102 U1 3 Sp cification d une classe Il peut se r v ler particuli rement int ressant d interpr ter les bonnes propri t s Valette 88 d un r seau born vivant r initialisable en termes d Objet La propri t la plus importante tudier sur un ObCS de sp cification est la vivacit des transitions de service si une transition de service est vivante alors il existe toujours une solution permettant de r pondre une invocation concernant ce service et l appel aura toujours le moyen de ne pas laisser l appelant bloqu en attente de la r ponse Il n est toutefois pas n cessaire que toutes les transitions de service soient vivantes on trouvera fr quemment des transitions qui ne peuvent tre franchies qu une fois et qui correspondent par exemple des initialisations obligatoires pour que l objet puisse fonctionner cf les services d initialisation IIL 3 5 Il est toutefois n cessaire que toute transition de service soit quasi vivante sans quoi elle est inutile dans le r s
326. te de r ponse La r ception du signal initie un flot de contr le chez le receveur qui peut voluer parall lement au flot de contr le qui a mis le signal Le m canisme de l attente par n cessit ou la r ponse fournie par un appel de service n est effectivement r clam e qu en cas de besoin ce qui permet au flot de contr le appelant d voluer m me sans avoir encore re u la r ponse de son appel 2 2 Objets en tant que processus Meyer 90a souligne les tr s fortes analogies que l on ne peut manquer d observer entre processus et objets e __ L existence de donn es locales les attributs d un objet les variables d un processus e L existence de donn es persistantes gardant leur valeur entre les activations successives e L existence d un comportement encapsul un cycle pour un processus un ensemble de m thodes pour un objet En effet un certain nombre de langages objets cherchent unifier la vision d clarative d un objet comme instance d un Type Abstrait de Donn e et sa vision proc durale en tant que processus s quentiel Agha 90 Parmi les langages qui se r clament explicitement de cette approche on peut citer ABCL Yonezawa 86 POOL America 87 Concurrent Smalltalk Yokote 87 a Ada Nous ne souhaitons pas d battre ici du degr d appartenance de Ada Leverrand 82 Burns 85 a la famille des langages Orient s Objet Des discussions int ressantes sur ce sujet apparaissent dans Str
327. te vision et l tendent au comportement des objets d crit par l ObCS tous les objets d une classe ont le m me comportement ils partagent le m me ObCS mais poss dent un marquage diff rent du RPO de cet ObCS Nous verrons en V 3 Etape 3 comment les attributs d un objet sont en fait g r s de la m me fa on que le marquage de son ObCS Le fait de m moriser une information relative un objet par un attribut ou par un l ment de son marquage est un choix de mod lisation qui est sans incidence sur la structure profonde de cet objet tout instant l tat d un objet est compl tement caract ris par le marquage de son ObCS L op ration Create doit d finir l tat initial de l objet c est dire la valeur initiale de ses attributs et le marquage initial de son ObCS L initialisation des attributs est d crite en utilisant la syntaxe classique de l affectation Les marquages initiaux sont sp cifi s en utilisant une syntaxe sp ciale d affectation que nous d crivons par une BNF lt Marquage d une place gt lt nom de place gt lt multiensemble de jetons gt lt multiensemble de jetons gt lt multiplicit gt lt jeton gt lt multiensemble de jetons gt lt multiplicit gt lt jeton gt lt multiensemble de jetons gt lt multiplicit gt lt INTEGER gt lt jeton gt lt gt lt jeton gt lt lt liste de valeurs gt gt liste de valeurs gt
328. tement coh rente et faiblement coupl e 180 VI 3 Flots de donn es 3 1 D finition Nous proposons donc de g n raliser cette notion de flots de donn es entre objets en caract risant une nouvelle classe de services appel s services data flows D finition VLI Services Data Flow Un Data Flow est un service Associ une transition non connexe au reste de l ObCS de sp cification et donc d fini comme tant toujours disponible e Pour lequel l action de la transition associ e dans l ObCS d impl mentation contient soit un appel d op ration interne algorithmique soit une invocation concernant un autre data flow Class specification Cserveur Data flows OP1 lt p INTEGER gt lt r BOOL Services OP2 OP3 lt r INTEGER gt ObCS PI Pr ee EGER gt Figure VI 9 Classe Cserveur publiant un data flow Les data flows sont d crits dans une section sp ciale de la sp cification d une classe avec la syntaxe habituelle des services figure II 47 On peut se dispenser de faire figurer la transition associ e non connexe dans l ObCS de sp cification De m me dans l ObCS d impl mentation on ne montrera pas la transition associ e par convention il suffit de fournir une op ration interne de m me nom que le service c est cette op ration qui doit tre ex cut e en cas d invocation La figure VI 9 illustre une sp cification d objet pr sentant
329. temporis e par un registre temporel Cette extension tr s simple combin e avec la puissance d expression des pr conditions et des actions et avec la possibilit d assembler dynamiquement des tuples par occurrence de transitions nous donne une grande flexibilit dans la manipulation du temps dans un r seau e La Figure II 23 montre comment muler une transition temporis e la Ramchandani par introduction d une place interm diaire repr sentant le fait que la transition originale est en cours de franchissement e De m me les r seaux arcs temporels peuvent tre simplement mul s comme le montre la Figure 11 24 en enrichissant le type de la place d un l ment de type Date et en ajoutant des pr conditions aux transitions de sortie Cette figure illustre un cas d utilisation classique des arcs temporels la d finition d un chien de garde watch dog c est dire d une action de sauvegarde ici la transition Alarme qui doit tre d clench e si un traitement nominal n a pu tre effectu avant un certain laps de temps 71 II 2 Extension des RPO Traitement lt a b gt lt a Alarme lt a b Traitement Figure IL 24 mulation des r seaux arcs temporels par registre temporel Dans les exemples des Figures 11 23 et II 24 on peut galement illustrer un apport int ressant de la technique du registre temporel par rapport aux d finitions de base de Bako ou Ramchandani il est tr s ais de
330. ter est constitu d une seule instance de la classe Table La d finition du syst me est illustr e en Figure V 18 Une d finition quivalente qui ne fait pas appel la classe composite mais acc de directement aux classes composantes est donn e en Figure V 19 On voit que cette d finition uniquement textuelle met beaucoup moins bien en valeur la structure des relations entre instances et produit donc un mod le plus difficile lire et comprendre 163 V 6 Prise en compte des classes composites System Table_de_philosophes Primitive objects Un seul objet primitif dont le nom est Table 1 Table 1 Table is create Yosai Mydzen Ddgen end Table l Classes Table Implementation Philosophe Implementation Figure V 18 D finition du syst me version 1 System Table _ de philosophes2 D finition sans objets composites Primitive objects Trois objets primitifs de classe Philosophe Ph 1 Ph 2 Ph 3 Philosophe Ph 1 is create YOsai gauche Ph 2 droite Ph 3 end Ph 1 Ph 2 is create My zen gauche Ph 3 droite Ph l end Ph 2 Ph 3 is create D gen gauche Ph l droite Ph 2 end Ph 3 Classes Table Implementation Philosophe i Figure V 19 D finition du syst me version 2 En suivant le proc d d crit au V 3 on peut construire le WSCS de ce syst me rep
331. tion d utilisation entre instances Toutefois cette notation graphique n est qu une facilit syntaxique et son quivalent textuel est strictement quivalent La Figure IV 4 illustre la syntaxe textuelle de l impl mentation d une classe composite caract ris e par le mot cl compound dans son en t te e On d finit d abord les objets composants qui sont des attributs r f rences de la classe e Les services offerts sont d finis dans la sp cification de la classe composite et l impl mentation donne uniquement la fonction de traduction Enfin on d crit comment l instance composite est instanci e On instancie tout d abord chacun des composants On d finit ensuite la relation d utilisation entre ces composants on utilise pour cela les services d initialisation qui offrent une mani re standardis e de fixer la valeur initiale des attributs publics On suppose ici que la classe Classel d clare un attribut public refl de classe Classe2 et que la classe Classel d clare un attribut public ref2 de classe Classe2 133 IV 3 Hi rarchie de composition Class Implementation Composite exemple P4 Type4 C1 Classel C2 Classe2 C3 Classe2 Figure IV 5 D finition graphique de l impl mentation de la classe Composite_Exemple La Figure IV 5 illustre la syntaxe graphique de l impl mentation d une classe composite avec les conventions suivantes inspir es de HOOD e La classe composite est repr se
332. tion de la classe Fichier_ prot g Figure III 12 va nous permettre d illustrer la relation d utilisation entre classes d objets Une instance de Fichier_prot g va utiliser une instance de Fichier pour r aliser les services qui lui sont demand s L instance de Fichier manipul e est repr sent e par un l ment du marquage de l ObCS de Fichier_prot g On remarque tout d abord que le passage de la sp cification l impl mentation a essentiellement consist clater les Transitions de Service TS de l ObCS de sp cification en un sous r seau plus complexe Les zones gris es sur la figure mat rialisent ces macro transitions 109 II 4 Impl mentation d une classe Le type des places lui aussi volu ainsi la place Pas_ d crivain qui tait du type jeton simple lt gt dans la sp cification est du type lt Fichier gt dans l impl mentation en effet une instance de Fichier prot g a besoin d un serveur de classe Fichier pour ex cuter ses services l utilisation du Fichier est sp cifi e dans les Transitions d Invocation par des requ tes telles que f ouvrir f fermer f position Class Implementation Fichier prot g attributes c_l INTEGER Combien de Lecteurs sont actuellement connect s Create lt nom STRING gt is c_l 0 Pas_d crivain Fichier Create nom end Create ObCS Pas _d crivain lt f Fichier gt Ecrivain lt conn Connexion pos GE Fich
333. toujours manipul e par un objet et un seul au moyen d une crit re structurel tr s simple sur les ObCS il s agit du crit re de non duplication Sibertin 85 D finition IV 4 Crit re de non duplication Un RPO est dit sans duplication si et seulement si La m me variable ne figure pas sur plusieurs arcs d entr e ni sur plusieurs arcs de sortie d une m me transition e Toutes les variables figurant sur un arc sont distinctes et ont un coefficient gal 1 e Un marquage est sans duplication si tout objet qui figure dans une place une multiplicit gale 1 et ne figure que dans cette place On peut montrer que si le marquage initial d un RPO sans duplication est lui m me sans duplication alors tout marquage accessible l est galement Dans notre exemple on est ainsi assur qu une baguette est tout instant manipul e par un philosophe et un seul On constate ici un double b n fice de notre approche e Le mod le produit est plus simple et plus compr hensible puisqu il se dispense de l introduction et de la gestion d une classe de type ressource exclusive e Il reste cependant compl tement verifiable grace au caract re formel et aux possibilit s d analyse des RPO Cette mani re de mod liser des ressources exclusives sera reprise au VII 1 o l on mod lise de la sorte les palettes qui circulent dans un atelier flexible de production 138 IV 3 Hi rarchie de composition b La
334. transition Valette 79 ou une place Elle peut aussi consister en un sous r seau et l quivalence est plus difficile caract riser Pomello 86 Les techniques de r duction de Berthelot Berthelot 86 qui visent simplifier les r seaux rel vent galement de cette approche Les limitations de la d composition hi rarchique sont bien connues dans le domaine du logiciel et les RdP n y chappent pas un syst me est toujours mod lis comme un seul r seau et au niveau le plus d taill il peut tre tr s complexe Ce r seau est un tout rigide o le m me sous r seau peut se retrouver diff rents endroits le concepteur du mal s int resser une partie du syst me ind pendamment des autres e La seconde approche n imbrique pas des r seaux les uns dans les autres mais au contraire consid re des r seaux qui communiquent entre eux chacun de ces r seaux mod lise alors une partie du syst me et le syst me est le r sultat de leur composition La composition peut se faire par places partag es Souissi 89 ou par transitions partag es De Cindio 81 L activit inverse de la composition qui consiste d composer un r seau en sous r seaux communiquants a t galement tudi e Hack 72 Colom 86 Souissi 89 Cette approche pr sente elle aussi des probl mes chaque r seau composant doit tre tre d fini de telle sorte qu il pr sente une unit fonctionnelle fortement coh rente et fa
335. tre VI Extension du formalisme Nous avons pr sent au chapitre III les Objets Coop ratifs en nous limitant volontairement au noyau dur du formalisme c est dire aux concepts qui sont la base de notre approche et qui nous paraissent suffisants pour aborder la mod lisation d une classe assez large de syst mes concurrents L objet de ce chapitre est de pr senter un certain nombre d extensions possibles ce noyau de base afin de faciliter la mod lisation dans des domaines plus cibl s ou d muler facilement des constructions ou des primitives rencontr es dans d autres approches e Nous proposons tout d abord deux autres modes d invocations des services qui permettent d avoir des protocoles de communication entre objets diff rents du rendez vous qui est un appel de type question r ponse e Nous proposons ensuite d utiliser le m canisme des places tri es IL 2 7 pour d finir des priorit s entre invocations d un service e Nous introduisons enfin la notion de flot de donn e entre objets c est dire une communication qui n induit pas de flot de contr le Cette notion est ensuite tendue pour d finir les objets passifs objets dont tous les services sont des flots de donn es 1 MODES D INVOCATION DES SERVICES Le rendez vous d fini au III 4 6 est le mode de communication l mentaire entre objets Un client qui invoque un service dans une de ses TI doit s attendre subir un certain d lai pour
336. tre objets c est dire toute invocation ou tout acc s un attribut public sera donc sp cifi e en tant qu action d une transition de l ObCS d impl mentation 9 Ces attributs peuvent toutefois lui tre communiqu s en tant que param tres de l appel 104 II 4 Impl mentation d une classe Nous pr sentons toutefois au chapitre VI une extension au formalisme des Objets Coop ratifs qui permet de d crire ais ment des objets dont la complexit est essentiellement algorithmique en s affranchissant de la contrainte cit e ci dessus il s agit des objets passifs qui sont comparables aux objets ayant un comportement s quentiel que l on peut d crire par des langages tels que C Eiffel etc 4 3 Structure de contr le ObCS d impl mentation La structure de contr le d une classe est d crite par un ObCS d impl mentation d fini comme l ObCS de sp cification par un R seau de Petri Objets et la fonction de disponibilit Ce r seau a pour but de d crire trois aspect de la structure de contr le qui sont distincts mais fortement interd pendants e La structure de contr le d crit le comportement d un objet de la classe c est dire la mani re dont il volue soit de mani re spontan e soit en r ponse des invocations de service l ex cution d un service par l objet se traduit par des franchissements de transitions dans son ObCS et donc par une volution de son tat e Elle sp cifie ensuite les commun
337. ts de processus et de classe d Objets pour construire le concept de Classe d Objets Concurrents Figure I 5 Classe Processus d Objets Concurrents Module Type Classe d Objets Figure I 5 Unification des concepts de processus et de classe Dans cette approche l activit d un objet processus consiste apr s sa cr ation ex cuter son op ration Live qui d crit le script ou le corps du processus Un objet processus peut donc tre actif m me sans tre en train de r pondre une invocation La communication entre objets processus prend la forme syntaxique d un appel de m thode conventionnel l approche est d crite en utilisant la syntaxe du langage Eiffel La s mantique d ex cution d un tel service toutefois est relativement complexe L ex cution par un objet o d une invocation de la forme p m thode param tres d clenche les op rations suivantes Lev e d une exception sp cifique Request dans le contexte de p Interruption dep e Synchronisation entre l appel et l appelant Un objet de classe REQUEST est transmis de o P e peto reprennent leur ex cution en parall le 25 26 L objet de classe REQUEST transmis durant l appel sp cifie la m thode appliquer et les param tres r els de l appel Le script de l objet p va d crire quel moment cet objet d cidera de servir cet appel L article ne sp cifie pas comment l existence de variables dont le type est une m t
338. ts par des approches plus classiques La citation de G Booch mise en exergue de cette introduction pose clairement le probl me que rencontre un concepteur qui doit mod liser un syst me r el les entit s qu il peut identifier sont souvent des entit s actives i e qui peuvent provoquer un changement de leur propre tat et dont le comportement n est pas s quentiel Si ce concepteur adopte une d marche Orient e Objet il doit chercher transcrire dans son mod le l aspect intrins quement concurrent des objets du r el et selon Sernadas 90 concevoir son syst me comme une soci t d objets voluant concurremment qui coop rent la r alisation d une t che Les fondements m mes de l approche Objet notamment l encapsulation et la communication par messages semblent bien adapt s l expression d une concurrence et d une r partition du contr le entre les entit s actives d un syst me La difficult majeure de cette approche r side dans la conception et la validation de la structure de contr le qui r sulte de cette coop ration entre entit s concurrentes Le but du travail pr sent dans ce m moire est de d crire un formalisme qui rende r aliste une telle approche en int grant aux concepts de l approche objet un m canisme permettant d exprimer un haut niveau d abstraction les constructions fondamentales li es la concurrence synchronisation parall lisme concurrence des acc s l information et offr
339. ttant de faire conna tre un philosophe ses voisins On donne directement l impl mentation de la classe Philosophe sa sp cification serait en l occurence identique son impl mentation avec simplement l omission des invocations droite donne_baguette_gauche dans l ObCS c est dire qu elle ne d crirait pas comment un philosophe se procure les baguettes dont il a besoin 136 IV 3 Hi rarchie de composition Class Implementation Philosophe Attributes Deux r f rences les voisins de droite et de gauche gauche droite Philosophe Une propri t le nom propre du philosophe nom STRING Operations Aucune op ration interne Initialization Services SETgauche lt pgauche Philosophe gt is Le voisin de gauche devient pgauche gauche pgauche end change_gauche SETdroite lt pdroite Philosophe gt is Le voisin de droite devient pdroite droite pdroite end change droite Services donne _ baguette _ gauche lt bg Baguette gt donne_ baguette _ droite lt bd Baguette gt garnit_le plat lt riz Nourriture gt create pnom STRING is D finition des propri t s nom pnom d finition du marquage initial pas_de baguette _a droite lt gt baguette _a gauche Baguette create end baguette_a_gauche baguette_a_doite lt b Baguette gt Je_mange lt bg Baguette bd Baguette gt Pas_de_baguette_a_gauche Pas_d
340. tuer les op rations suivantes 1 Une place param tre est ajout e cette place est reli e en entr e chaque transition d accord associ e au service et les arcs qui les connectent sont tiquet s avec les param tres formels d entr e du service De m me une place r sultat est ajout e reli e en sortie chaque transition de retour associ e au service et les arcs qui les connectent sont tiquet s avec les param tres formels de sortie du service Le type de ces places est d fini de la m me mani re qu l tape 1 on concat ne galement le type 1dentifieur aux types des places param tre et r sultat et on ajoute conform ment la variable id aux arcs adjacents 2 On verra au IX que dans tout ObCS bien form il doit exister pour chaque couple de transition accord retour un S invariant qui les inclut Pour toute place contenue dans cet invariant on concat ne son type le type Identifieur On ajoute galement la variable id tous les arcs qui connectent les places de cet invariant lt p id gt lt p c id gt lt p c id gt END_OP1 Cr CEP lt c id gt Figure V 7 ObCS de ServeurG tape 2 Cette modification de structure produit un conflit entre transitions au sein de l ObCS d une classe toutes les transitions d accord d un m me service sont maintenant en conflit structurel cf II 2 1 Ceci correspond bien la s mantique que l on souhaite donner l association de plusieur
341. ture de l op ration create telle qu elle est d finie dans la classe concat n e avec le type Identifieur L arc qui la connecte avec la transition d instanciation est tiquet par les param tres formels de l op ration create concat n s avec id Le type de la place r sultat est la classe elle m me galement concat n avec le type Identifieur et l arc de sortie est tiquet par lt self id gt La transition d instanciation a un arc de sortie vers chacune des places pour lesquelles la classe d finit un marquage initial non vide Ces arcs sont tiquet s par les variables d entr e de la transition d instanciation ou par des constantes de mani re ce que l occurrence de cette transition produise le marquage initial d fini dans la classe concat n pour chaque n uplet avec la valeur de self La variable self sera li e un nom d objet g n r par une op ration interne quivalente gensym avec pour seule diff rence que c est le nom de la classe qui est concat n avec un compteur incr ment chaque invocation Ce compteur mat rialis par un jeton stock dans une nouvelle place connect e en entr e et sortie la transition d instanciation est en quelque sorte une variable de classe contenant le nombre d instances d j g n r es pour cette classe Un nom d instance sera donc de la forme lt Nom de classe num ro d instance gt Le r seau qui r sulte de l tape 3 est appel ObCS d extension d
342. u moins explicite la base de la plupart des UIMS User Interface Management Systems ou syst mes de gestion d interfaces utilisateur modernes Interface Abstraction Noyau applicatif non interactif Informations Informations Informations s mantiques syntaxiques lexicales Figure VII 20 Le mod le Seeheim Le mod le Seeheim propose une vision linguistique de l interaction personne logiciel en structurant cette communication en niveaux s mantiques syntaxiques et lexicaux Cette structuration induit une structure logicielle trois composants L Abstraction le Dialogue et la Pr sentation e L Abstraction repr sente la s mantique de l application ind pendante de toute interface de manipulation Dans un cadre Orient Objet l Abstraction consiste en un ensemble de classes et 210 VIL2 Interfaces Personne logiciel sa conception doit tre entreprise par des techniques de Conception Orient e Objet Rumbaugh 91 Booch 87 e La Pr sentation est responsable des aspects lexicaux du dialogue en entr e aussi bien qu en sortie Ce composant prend en charge les diff rentes interactions physiques et doit transformer les actions de l utilisateur en unit s de dialogue plus abstraites par exemple transformer l information lexicale l utilisateur a cliqu en coordonn es x y en l information syntaxique L utilisateur a press sur le bouton Quitter Le composant Pr sentation est aujourd hui tr s bien tr
343. u sous le nom de liaison tardive ou dynamique late or dynamic binding Meyer 90b La liaison tardive est souvent stigmatis e par les d tracteurs de l approche Orient e Objet comme tant synonyme d inefficacit Il faut mod rer cette affirmation en constatant par exemple que dans Eiffel l invocation quoique l g rement plus co teuse en temps qu un appel de fonction se fait en temps constant quel que soit la complexit du graphe d h ritage b H ritage multiple On parle d h ritage multiple lorsque une classe peut avoir plusieurs ant c dents imm diats le graphe d h ritage n est alors plus un arbre mais un treillis Dans ce cadre les deux aspects de l h ritage vision d une classe comme un module ou comme un type sont pr sents e La puissance de repr sentation des connaissances est augment e car on peut d s lors regrouper au sein d une m me classe des caract ristiques de provenance diverse Le danger potentiel de cette approche est de surcharger une classe de mani re ce qu elle repr sente en d finitive plus d un type d objet Halbert 87 e La r utilisation est facilit e ainsi en Eiffel l h ritage multiple est souvent utilis pour muler le m canisme d inclusion include des langages modulaires tels que C on peut ainsi d finir une classe comme une biblioth que de fonctions utilitaires par exemple des routines math matiques Si une classe a besoin d une de ces fonction il lui suffit d aj
344. uille de la hi rarchie d h ritage 175 2 ORDONNANCEMENT DES INVOCATIONS Au cours de l activit d un syst me il peut fort bien arriver qu un objet re oive plusieurs invocations concernant le m me service avant d tre en mesure d en servir une Un objet peut avoir plusieurs invocations en attente pour un des services qu il offre ce qui se mat rialise par plusieurs jetons dans la place param tres de ce service En l absence de toute pr cision l ordre dans lequel ces invocations seront servies c est dire l ordre dans lequel les jetons de la place param tres seront consomm s par occurrence de la transition d accord n est pas d termin Ceci est contraster avec la s mantique du rendez vous dans le langage Ada o les appels en attente sur une entr e de t che sont servis dans l ordre FIFO Le mod lisateur peut souhaiter pr ciser l ordre de traitement des invocations r duisant de la sorte l ind terminisme du comportement de l objet qu il d crit La sp cification d un ordre de traitement des requ tes peut parfois se r v ler n cessaire afin d viter des ph nom nes de privation o la requ te d pos e par un client n est jamais servie bien que l objet serveur traite effectivement la requ te pour d autres clients et que la sienne soit recevable c est dire qu elle satisfasse la pr condition de la transition d accord Les m canismes d ordonnancement des marquages d crits au I1 2 7 sont exactement ada
345. uit partir de ses constituants l mentaires et le point de vue dynamique ou fonctionnel d crit les interactions que le syst me entretient avec son environnement Ces deux points de vue sont d taill s dans les paragraphes suivants 1 1 D finition d un Syst me d Objets Cooperatifs Le m canisme de base qui r git l volution d un Syst me d Objets Coop ratifs SOC est le suivant un objet cr e un autre objet par invocation de la primitive Create et obtient en r sultat de cette action le nom de l objet nouvellement cr qu il m morise comme composant de la marque d une place de son OBCS ou dans une de ses r f rences L objet cr ateur peut ensuite demander par l occurence d une Transition d Invocation TI des services l objet nouvellement cr ou communiquer l identit de ce dernier d autres objets du syst me Pour que ce m canisme puisse s amorcer il faut qu un ou plusieurs objet s pr existe nt la mise en ex cution du syst me Ce sont ces objets primitifs qui vont par leur activit g n rer les autres objets du syst me La mani re dont sont cr s ces objets primitifs n est pas d finie par le formalisme qui d crit le syst me lui m me et le mod le ne devient une image fid le du syst me r l qu il repr sente qu une fois ces objets primitifs cr s et actifs 121 IV 1 Syst mes d Objets Coop ratifs On suppose connu un ensemble de classes d Objets Coop ratifs Un syst me
346. un data flow On peut se dispenser de faire figurer dans l ObCS la transition associ e OP Il faut pr ciser comment les data flows sont pris en compte dans le proc d de construction du WSCS La figure VI 10 montre comment I ObCS d extension sera g n r en suivant le proc d du V 3 On 181 VI 3 Flots de donn es voit que l ex cution du data flow n a pas d influence sur le contr le du serveur La transition associ e au service OP1 ex cute l op ration interne OP qui renvoie un r sultat fonction du param tre re u et de la valeur de deux attributs lt id self gt lt attx self gt lt at x self gt lt p id self OP1 r Opl p attx att lt atty self lt x id sel delf gt lt x id sel Figure VI 10 ObCS d extension de Cserveur 3 2 Integration dans le reseau global Il nous faut cependant modifier le proc d de construction du WSCS de mani re a ce que l ex cution du data flow puisse tre galement consid r e comme le franchissement d une transition unique chez le client Ceci est r alis par un proc d similaire au traitement des TA transitions d acc s la TI qui fait appel au data flow est connect e en entr e et en sortie aux places attributs de l objet serveur qui interviennent dans l op ration interne associ e et l appel l op ration est int gr la transition d invocation figure VI 11 L op ration interne correspondante Op1 doit acc
347. un syst me d objets est structur e suivant une organisation de type client serveur Un objet du syst me qui communique avec les autres objets par envoi de messages r clame I 1 Les fondements de l approche Objet l ex cution d un service un autre objet et en r cup re le r sultat ventuel Nous utiliserons le terme d invocation pour d signer l action d un objet client qui r clame l ex cution d un service un objet serveur Nous n irons pas plus loin en ce qui concerne la pr sentation des concepts g n raux de l approche objet mais ces diff rents points seront bien entendu repris en d tail lorsqu il s agira de pr ciser comment ils s int grent dans notre formalisme Avant de poursuivre prenons le risque de proposer une d finition du concept d objet Cette d finition ne pr tend pas l universalit mais sert seulement caract riser les concepts sur lesquels notre approche se fonde D finition I 1 Objet et Classe d Objets Un objet est une entit qui poss de un tat et qui offre son environnement un ensemble d op rateurs destin s faire voluer cet tat Une Classe d Objets d finit en intention l espace d tats des objets qui sont ses instances en d crivant pour ces objets une structure de donn es un ensemble d op rateurs de changement d tat et une structure de contr le 1 1 Les Types Abstraits de Donn es Les Types Abstraits de Donn es TAD Guttag 77 Liskov 77 sont un
348. une classe plus sp cialis e 198 VIL 1 Mod lisation d un atelier flexible A l initialisation d une bande transporteuse on doit indiquer sa capacit cap en nombre de palettes et le temps l mentaire de transit pour un emplacement temps le temps minimal de transit d une palette dans un l ment de transport sera donc cap temps Class Specification Transport attributes pr c dent Transport Data Flows Peut_traiter lt pal Palette gt lt r BOOL Services Transmettre lt pal Palette gt SETpr c dent lt p Transport gt Create lt cap temps INTEGER gt ObCS Circule lt Palette gt Hard FIFO TRANSMETTRE Figure VIL9 Sp cification de la classe Transport La classe Transport exporte un service de consultation Peut_traiter qui d finit si la section est en mesure d effectuer une op ration sur la palette pass e en param tre Cette op ration n est pas utile pour une section de transport simple mais est introduite afin d tre surcharg e par les classes d riv es de Palette notamment la classe Il t C est une notion comparable aux op rations diff r es Meyer 90b qui permettent de factoriser des comportements communs en les faisant remonter dans la hi rarchie d h ritage L impl mentation de la classe Transport montre comment une de ses instances recueille une palette en invoquant le service Transmettre son objet Pr c dent et s en d charge en r pondant
349. univers de la classe tC e Tyg Cest l ensemble des types export s par la classe e Cog U est l ensemble des constantes export es par la classe e T TS U TP et TS A TP partition des transitions de l ObCS en transitions de service TS et transitions priv es TP Sy est l ensemble des services de la classe e Sig Sv VxC x V xC est la fonction signature Elle associe chaque service une liste de couples variable type d finissant sa signature d entr e et une liste de m me structure d finissant sa signature de sortie e Disp Sv gt PT est la fonction de disponibilit telle que Vse Sv Disp s 4 101 IIT 3 Sp cification d une classe Vs s e Sv Disp s Disp s sis s Ts Disp s est l ensemble des transitions de service s Sv TP T TS est l ensemble des transitions priv es La fonction Disp mat rialise l association des services offerts par la classe des transitions du RPO R Le couple R Disp sera appel l ObCS de la classe e Mo P N U_ est le marquage initial de chaque instance de la classe Ce marquage est d fini de mani re textuelle par le code de l op ration Create D finition HI 2 R gle d volution d un ObCS Un objet change d tat en ex cutant des services ou en franchissant des transitions priv es A partir d un marquage M de son ObCS un objet peut ex cuter un service s Sv si et seulement S1 Il existe une
350. ure I 4 Contre exemple Dans le contre exemple de la Figure I 4 une file passive non separate est cr e puis pass e en param tre un objet actif separate lui aussi nouvellement cr La r f rence vers la file est donc partag e entre deux objets actifs Selon Meyer la pr condition relative l appel f d filer doit tre interpr t e en mode s quentiel et donc provoquer une terminaison du programme si elle est test e sans tre satisfaite En r alit la pr condition devrait tre interpr t e comme une condition d attente car l objet de classe Enfileur d not par x va se charger d entrer un nombre dans la file d bloquant ainsi l objet qui l a cr Le probl me pos par ce contre exemple pourrait tre vit par une r gle syntaxique for ant tous les param tres pass s un client r f renc par une variable separate tre eux m mes r f renc s par des variables separate ou en effectuant alors un passage de param tres par copie la copie devrait alors tre une copie profonde c est dire prendre en comptes tous les objets li s au param tre par la relation d utilisation Cette derni re solution est adopt e dans l approche d crite par Caromel 90 expos e ci apr s Dans le formalisme qui fait l objet de cette th se ces probl mes sont pris en compte de la mani re suivante toutes les entit s sont conceptuellement separate et un probl me tel que celui du contre exemple peut tr
351. urtoisie s rrnititnimmennrne he dire Min te 245 D finition IX 4 Crit re d transparence sisi nine eee nn Rte 245 D finition IX 5 Crit re d impl mentation fid le 246 D finition IX 6 Crit re d h ritage du comportement 247 D finition IX 7 Compatibilit entre client et serveur 248 256 Table des figures Chapitre I Mod lisation par objets des syst mes concurrents Figure 1 Une File d ntiers en Eiffel iis 28 is ann de met el dt ni init Figure 1 2 Les deux aspects d un contrat Figure 1 3 Histoire de la concurrence selon Lamport cceeecesseeceseeeeeseeeeeeceeeeeaeeneeaeees Figure 1 4 Contre exemplen an rit en a ih tn edie defen Figure I 5 Unification des concepts de processus et de classe Figure 1 6 Dynamique des objets actifs HOOD ss Figure I 7 Syntaxe graphique des objets HOOD Chapitre Il Les reseaux de Petri de Haut Niveau Figure II 1 Construction des substitutions par semi unification Figure II 2 COnflitide transitlOns nsc Rene nent sin etre dese Figure II 3 Ind terminisme li aux valeurs des jetons Figure II 4 Place registre et notation abr g e Figure II 5 R gle d mission et notation abr g e oo eee ecesesceseceeeeceeeeecceseeereeeeeceaeeateaeens Figure II 6 Place capacit et notation abr g e Figure II 7 Priorit s par transitions et priorit s par arcs Figure II 8
352. us ne puisse ex cuter une proc dure du moniteur e La derni re difficult enfin est d ordre m thodologique Howard 76 Le code d une proc dure d un moniteur sera en g n ral de la forme suivante Si Q Q expression bool enne des variables d tat du moniteur K alors c attendre fsi assertion Ici Q est vrai lt mise jour des variables d tat gt Toutefois la forme syntaxique du moniteur n impose pas que l assertion soit effectivement vraie puisque le r veil du processus par c signaler est compl tement dissoci de l valuation de la condition Q Cette construction a donc pour inconv nient de faire appara tre la condition Q en deux points du programme et de ne pas traiter simplement le cas o plusieurs processus attendent la m me condition x Kessels a propos une primitive permettant de r pondre ces probl mes dans Kessels 77 la primitive attendre est de la forme attendre Q Q expression bool enne des variables d tat du moniteur Lo qui met le processus qui l ex cute en attente jusqu ce que Q devienne vraie dans cette approche la proc dure signaler n existe donc plus On verra par la suite que cette primitive a exactement la m me s mantique que les pr conditions d attente de Meyer 90a La discussion pr c dente sur les moniteurs un peu longue peut surprendre dans un rapport consacr l approche Objet l approche par moniteurs d j ancienne n es
353. ut on contraint donc de mani re tr s importante la structure de donn es et donc l impl mentation de la structure physique de stockage de toute classe d riv e alors que l h ritage lorsqu on lui donne la s mantique du sous typage devrait contraindre uniquement la sp cification d une classe et donc ses services ceci rejoint la discussion du I 1 4 sur la s mantique de l h ritage dans les LOO Malgr ces inconv nients nous avons choisi de conserver la possibilit de donner acc s des attributs dans la sp cification d une classe car elle nous para t utile et justifi e dans certains cas dont certains sont comment s en d tail dans ce m moire cf VII 1 VI 4 V 3 et dont d autres font l objet de recherches parall les aux n tres Sibertin 91 Au contraire une d marche m thodologique ax e sur d autres domaines d application tel que la programmation r partie pourrait proscrire totalement l usage des attributs publics Class Specification Exemple set of INTEGER Typel est un type construit export Type2 is private Typ xport en mode priv Constants Ctl Ct2 Type2 Deux constantes symboliques de type Type2 Services Svl lt pl INTEGER p2 STRING gt lt vl STRING v2 Type2 gt le service Svl a deux param tres d entr pi de typ ntier et p2 de type chaine Il a deux param tres de sortie vl de type cha ne et v2 de type
354. ut autre acc s au fichier Cet identificateur de connexion est d not dans la sp cification par une valeur de type Connexion un type classe que l on suppose d fini par ailleurs Les autres services offerts par la classe sont identiques ceux offerts par la classe Fichier l exception du param tre suppl mentaire conn de type Connexion qui d note la connexion laquelle l invocation du service fait r f rence Pour chaque connexion la classe doit maintenir une position courante diff rente et c est partir de cette position que s effectuera la prochaine op ration de lecture ou d criture pour la connexion concern e La politique de lecture criture est la suivante on autorise plusieurs connexions en lecture simultan es Une connexion en criture interdit toute autre connexion en lecture ou en criture et r serve le fichier l usage exclusif du r dacteur jusqu ce que celui ci ferme sa connexion en invoquant le service Fermer La sp cification de Fichier_ prot g figure 11 7 fait appara tre des services associ s plusieurs transitions de l ObCS On voit notamment que les op rations Fermer et Aller_en sont chacune associ es deux transitions L ind terminisme introduit par cette construction sera lev dynamiquement chaque invocation par unification sur la valeur du param tre conn L ObCS traduit fid lement la politique d crite plus haut on remarque no ent que la transition Ouvrir_en_ cr
355. ut d abord nous d crivons la classe d objets atomiques Philosophe qui d crit le comportement de chacun des philosophes qui seront convi s au banquet Nous d crivons ensuite la classe Table qui est une classe d objets composites d crivant l assembl e des philosophes pour le repas a La classe Philosophe Un philosophe a un nom et connait son voisin de droite et son voisin de gauche qui sont tous deux des philosophes Les services que peut rendre un philosophe sont simplement de donner sa baguette gauche ou sa baguette droite s il les poss de Manger n est pas un service que peut rendre le philosophe mais bel et bien une op ration interne Quant Penser on a consid r ici qu il s agit de la t che de fond du philosophe et qu il est capable de penser m me en mangeant on n a donc pas explicitement fait figurer cette activit dans son comportement La classe Philosophe Figure IV 7 d crit un tel comportement avec quelques ajouts visant illustrer des points syntaxiques de la d finition d objets composites yntax q J P 135 IV 3 Hi rarchie de composition e ony a inclus un service garnir_le_plat qui permet un philosophe de r approvisionner un plat de riz partag par tous et non mod lis Nos philosophes tant droitiers ils ne peuvent r approvisonner le plat que s ils ne tiennent pas de baguette dans leur main droite e on y a inclus galement les services d initialisation SETgauche et SETdroite perme
356. ute ces transitions une place en entr e et sortie cette place poss dant un marquage initial d un jeton simple 3 Le type de la classe est ajout la d finition du type de chaque place de l ObCS y compris les places qui ont t ajout e aux tapes pr c dentes l exception des places param tre et r sultat des TI et de places r sultat des transitions de retour On ajoute conform ment la variable self aux arcs adjacents 151 V 3 Construction du r seau global 4 Le type de l objet serveur est ajout la place param tre de chaque TI L entit qui d note l objet destinataire de la requ te ce peut tre une variable d entr e de la TI ou une r f rence de la classe cliente est ajout e l tiquette de l arc Il est important de noter que 3 et 4 donnent exactement le m me type la place param tre en sortie d une transition d appel et la place param tre en entr e de la transition d accord correspondante Les places param tres contiendront pour chaque occurrence d une requ te de service des jetons typ s contenant les informations suivantes les param tres r ls de cette invocation l estampille d appel g n r e par l occurrence de la transition d appel le nom de l objet destinataire de l appel 5 On ajoute l ObCS de la classe une transition d instanciation avec sa place param tre en entr e et sa place r sultat en sortie Le type de la place param tre est la signa
357. ution de service et ce jusqu ce que la valeur de a soit effectivement n cessaire La valeur li e la variable a est effectivement n cessaire si a intervient dans une op ration arithm tique telle que l addition dans une op ration d entr e sortie ou est elle m me destinataire d une invocation 21 1 2 Mod les d objets concurrents Un des grand int r ts de cette approche est de ne pas n cessiter de construction syntaxique sp ciale pour d noter une synchronisation et de laisser le syst me lui m me synchroniser les flots de contr le en quelque sorte au moment le plus opportun Le point essentiel de la discussion de Meyer 90a n est pas toutefois la description de ces primitives de communication mais bien l analyse des rapports entre la programmation concurrente et le mod le de la programmation par contrat qui est un des fondements du langage Eiffel et que nous avons pr sent en 1 1 3 Une constatation fondamentale est que Le mod le s quentiel du contrat ne tient plus tel quel pour la programmation concurrente l exemple de la file d taill au II 2 7 suffit s en convaincre En mode s quentiel un client du service d filer peut s assurer qu il remplit sa part du contrat qui est de ne jamais r clamer ce service sur une file vide par une construction de la forme if not ma_ file vide then x ma_file d filer else end En mode concurrent cette construction n a plus de sens si l ob
358. valle ou num ration comme dans le langage Pascal soit des types cr s par application d un constructeur de type des types d j connus Deux constructeurs de type sont d finis en utilisant la syntaxe du langage Pascal set of qui construit un type simple d notant un ensemble de valeurs de type quelconque Les op rations ensemblistes usuelles sont d finies pour les valeurs des types ensemblistes 86 IIT 2 Le syst me de types e array of qui construit un type simple d notant un tableau de valeurs de type quelconque Les indices d un tableau prennent leur valeur dans un type d fini par intervalle ou par num ration et chaque l ment du tableau est accessible par son indice 2 2 Types classe Les types classe permettent aux identificateurs du langage de d noter non plus une constante mais un objet du syst me Une variable dont le type est une classe aura pour valeur le nom d un objet de cette classe Une variable de type classe est une r f rence vers l objet qu elle d note Quatre op rations sont d finies pour un identificateur de type classe L affectation qui permet d associer un nouveau nom d objet l identificateur L op rateur correspondant est comme pour l affectation entre variables de type simple e Le test d identit qui permet de tester si deux r f rences d objets sont gales Cet op rateur est not comme pour le test d galit entre variables de type simple e L invo
359. veau des RdP simples et les valeurs ajj et bij sont donc des constantes Dans le cadre des RPO le d veloppement logique de cette extension est de faire des bornes de l intervalle des fonctions de la valeur du jeton manipul Chacune de ces extensions peut tre ais ment incorpor e dans la d finition des RPO afin d autoriser une prise en compte du temps Toutefois pour int grer l aspect temporel dans le formalisme des Objets Coop ratifs nous pr sentons une technique diff rente qui permet d muler les mod les de temporisation pr c demment d crits a Registre temporel La bonne prise en compte des donn es valu es au sein des RPO rend tr s ais e la gestion de la variable temps dans les mod les L id e de base est de disposer dans le r seau d un registre cf II 2 2 servant d horloge et dont la valeur contient la date courante Pour disposer des op rations usuelles sur les dates et les dur es nous introduisons tout d abord les domaines de valeur suivants Date est un domaine qui nous permet de d signer un instant ponctuel dont l chelle et l origine d pendent du syst me consid r Duration est en domaine permettant de d signer des dur es et des intervalles de temps avec la m me chelle que Date On dispose des op rateurs suivants Duration X Duration Duration permettant de faire la somme de deux dur es Duration X Duration Duration permettant de faire la diff rence

Introduction

Contents

Download Pdf Manuals

Related Search

Related Contents