Vous êtes sur la page 1sur 118

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministre de lEnseignement Suprieur et de la Recherche


Scientifique
Universit El Hadj Lakhdar BATNA

Facult des Sciences et des

Dpartement

Sciences de lingnieur

dinformatique

N dordre :
Srie
:

Mmoire
Prsent en vue de lobtention du diplme

Magister en Informatique
Option: Informatique Industrielle

SUJET DU MMOIRE :

Une approche de modlisation des logiciels base de


composants par les rseaux de Petri

Prsent le : 14 / 06 / 2009

Par : ZERNADJI Tarek


Composition du jury:
Mr. BELATTAR Brahim

Prsident

(Matre de Confrence lUniversit de Batna)

Mr. CHAOUI Allaoua

Rapporteur (Matre de Confrence lUniversit de Constantine)

Mr. BILAMI Azzeddine

Examinateur (Matre de Confrence lUniversit de Batna).

Mr. KAZAR Okba

Examinateur (Matre de Confrence lUniversit de Biskra).

Remerciements
Jaimerais dabord remercier mon encadreur qui ma soutenu tout au long de la
rdaction de ce mmoire, pour son coute et ses conseils pertinents.

Je remercie galement lensemble des membres du jury pour avoir consacrer leur
temps examiner ce travail malgr leurs nombreuses responsabilits, je leur suis
reconnaissant pour lattention quils ont porte mon travail.

Je tiens aussi remercier ma famille et mes amis pour leur soutient inconditionnel
et leur prsence continue.

Enfin je remercie tous ceux qui mont aid de prs ou de loin pour la ralisation de
ce travail.

SOMMAIRE
INTRODUCTION GENERALE........................................................................................................1
CHAPITRE I : DEVELOPPEMENT LOGICIEL A BASE DE COMPOSANTS ......................5
1.

INTRODUCTION.......................................................................................................................5

2.

PROCESSUS LOGICIEL..........................................................................................................5

3.

2.1

ACTIVITES GENERIQUES DU CYCLE DE VIE DUN LOGICIEL ...............................6

2.2

MODELES DE CYCLE DE VIE DUN LOGICIEL ...........................................................6

2.2.1

Modles squentiels ...................................................................................................... 7

2.2.2

Modles volutionnistes................................................................................................ 7

2.2.3

Processus unifi............................................................................................................. 8

APPROCHE DE REUTILISATION ........................................................................................9


3.1

DEVELOPPEMENT BASE COMPOSANT CBD...............................................................9

3.2

RACINES DU CBD ............................................................................................................10

3.3

PROCESSUS DE DEVELOPPEMENT DAPPLICATIONS BASES COMPOSANTS ..11

3.3.1

Notion de rutilisation................................................................................................. 12

3.3.2

Processus de rutilisation ............................................................................................ 14

3.3.3

Cycle de vie pour le CBD ........................................................................................... 17

3.4

4.

INGENIERIE LOGICIELLE BASEE COMPOSANT (CBSE) .........................................22

3.4.1

Concepts de base ......................................................................................................... 22

3.4.2

Relation entre concepts ............................................................................................... 27

3.4.3

Notion de composant................................................................................................... 28

CONCLUSION .........................................................................................................................33

CHAPITRE II : ECATNETS ET LOGIQUE DE REECRITURE .............................................34


1.

INTRODUCTION.....................................................................................................................34

2.

RESEAUX DE PETRI..............................................................................................................35
2.1

DEFINITIONS DE BASE...................................................................................................35

2.2

REGLE DE FRANCHISSEMENT .....................................................................................35

2.3

REPRESENTATION GRAPHIQUE DUN RESEAU DE PETRI ....................................36

2.4
3.

4.

5.

6.

PROPRIETES COMPORTEMENTALES DUN RDP......................................................36

RESEAUX DE PETRI DE HAUT NIVEAU..........................................................................37


3.1

DEFINITION DUN HLPN ................................................................................................37

3.2

RESEAUX DE PETRI ALGEBRIQUES DE HAUT NIVEAU.........................................38

LOGIQUE DE REECRITURE ET MAUDE.........................................................................39


4.1

DEFINITIONS DE BASE...................................................................................................39

4.2

SYSTEMES DE REECRITURE.........................................................................................40

4.3

LOGIQUE DE REECRITURE ...........................................................................................41

4.3.1

Rseau de Petri dans la logique de rcriture.............................................................. 43

4.3.2

Maude.......................................................................................................................... 45

ECATNETS ...............................................................................................................................50
5.1

DEFINITION FORMELLE DUN ECATNETS ................................................................51

5.2

SYNTAXE DES ECATNETS.............................................................................................52

5.3

SEMANTIQUE DES ECATNETS .....................................................................................53

5.4

EXEMPLES DE MODELISATION AVEC LES ECATNETS..........................................57

5.4.1

Prsentation de lexemple1 ......................................................................................... 57

5.4.2

Prsentation de lexemple2 ......................................................................................... 60

CONCLUSION .........................................................................................................................61

CHAPITRE III : MODELISATION DES LOGICIELS A BASE DE COMPOSANTS


AVEC LES ECATNETS .................................................................................................................63
1.

INTRODUCTION.....................................................................................................................63

2.

TRAVAUX VOISINS ...............................................................................................................63

3.

PRESENTATION DE LAPPROCHE DE MODELISATION ...........................................65


3.1

SPECIFICATION DU SYSTEME......................................................................................66

3.1.1

Service requis (Rceptacle)......................................................................................... 68

3.1.2

Service offert (facette)................................................................................................. 69

3.1.3

Evnement offert (source)........................................................................................... 70

3.1.4

Evnement requis (puit) .............................................................................................. 70

3.1.5

Spcification des connexions ...................................................................................... 71

3.2

GENERATION DES REGLES DE REECRITURE...........................................................73

3.3

VERIFICATION DU SYSTEME .......................................................................................73

4.

ETUDE DE CAS .......................................................................................................................74


4.1

4.1.1

GetButton .................................................................................................................... 76

4.1.2

PutButton..................................................................................................................... 78

4.1.3

MyBuffer..................................................................................................................... 78

4.1.4

PutTextField ................................................................................................................ 81

4.1.5

GetTextField................................................................................................................ 82

4.1.6

PutAdapter et GetAdapter ........................................................................................... 83

4.2

5.

PRSENTATION DE LEXEMPLE1................................................................................75

PRESENTATION DE LEXEMPLE 2...............................................................................87

4.2.1

Spcification du systme............................................................................................. 88

4.2.2

Gnration des rgles de rcriture ............................................................................. 94

4.2.3

Vrification du systme............................................................................................... 95

CONCLUSION .......................................................................................................................102

CONCLUSION GENERALE ET PERSPECTIVES..................................................................103


REFERENCES...............................................................................................................................105

LISTE DES FIGURES


FIGURE 1

LE MODELE SEQUENTIEL.......................................................................................7

FIGURE 2

LES QUATRE PHASES DE LUP ET CES ACTIVITES ..........................................8

FIGURE 3 INGENIERIE POUR LA REUTILISATION ET INGENIERIE PAR


REUTILISATION ..............................................................................................................................17
FIGURE 4 MODELE EN V ADOPTE POUR LE DEVELOPPEMENT BASE
COMPOSANT ...................................................................................................................................19
FIGURE 5 MODELE EN Y POUR LE DEVELOPPEMENT LOGICIEL BASE
COMPOSANT ...................................................................................................................................20
FIGURE 6

EXEMPLE DE DEFINITION DINTERFACE EN IDL ...........................................24

FIGURE 7

LA STRUCTURE DU PATTERN OBSERVER .......................................................26

FIGURE 8 RELATION ENTRE LES CONCEPTS POUR UNE APPLICATION


BASEE COMPOSANTS....................................................................................................................27
FIGURE 9 REPRESENTATION GRAPHIQUE DUN RDP MODELISANT UNE
REACTION CHIMIQUE ..................................................................................................................36
FIGURE 10 RDP DUNE MACHINE VENDEUSE DE TARTES ET DE POMMES .................44
FIGURE 11 REPRESENTATION GENERIQUE DUN ECATNET............................................52
FIGURE 12 CELLULE DE PRODUCTION..................................................................................57
FIGURE 13 MODELE ECATNET DE LA CELLULE DE PRODUCTION ................................59
FIGURE 14 MODELE ECATNET DU MODULE DEBUT DE TRANSMISSION
DUNE STATION EMETTRICE ETHERNET.................................................................................60
FIGURE 15 ETAPES DE LAPPROCHE DE MODELISATION DES LOGICIELS A
BASE DE COMPOSANTS................................................................................................................66
FIGURE 16 SPECIFICATION DUN COMPOSANT LOGICIEL ...............................................67
FIGURE 17 SPECIFICATION DUN SERVICE REQUIS (RECEPTACLE) ..............................68
FIGURE 18 SPECIFICATION DUN SERVICE OFFERT (FACETTE) .....................................69
FIGURE 19 MODELE GENERALE DUN SERVICE OFFERT (FACETTE) ...........................70
FIGURE 20 SPECIFICATION DUN EVENEMENT SOURCE..................................................70

FIGURE 21 SPECIFICATION DUN EVENEMENT PUIT.........................................................70


FIGURE 22 SPECIFICATION DUNE CONNEXION : EVENEMENT SOURCE
/PUIT ..................................................................................................................................................71
FIGURE 23 SPECIFICATION DUNE CONNEXION : SERVICES OFFERTS /
REQUIS..............................................................................................................................................72
FIGURE 24 INTERFACE UTILISATEUR DE LEXEMPLE ......................................................75
FIGURE 25 SYNTAXE IDL3 POUR UN SOURCE .....................................................................76
FIGURE 26 SYNTAXE IDL3 POUR UN PUIT ............................................................................76
FIGURE 27 SPECIFICATION DU COMPOSANT GETBUTTON EN IDL3..............................76
FIGURE 28 MODELE ECATNET DU COMPOSANT GETBUTTON .......................................77
FIGURE 29 SPECIFICATION FORMELLE DU COMPORTEMENT DU
COMPOSANT GETBUTTON ..........................................................................................................77
FIGURE 30 SPECIFICATION DU COMPOSANT PUTBUTTON EN IDL3..............................78
FIGURE 31 SYNTAXE IDL3 POUR UNE FACETTE.................................................................79
FIGURE 32 SPECIFICATION DU COMPOSANT MYBUFFER EN IDL3 ................................79
FIGURE 33 MODELE ECATNET DU COMPOSANT MYBUFFER..........................................80
FIGURE 34 SPECIFICATION FORMELLE DU COMPORTEMENT DU
COMPOSANT MYBUFFER .............................................................................................................80
FIGURE 35 SPECIFICATION DU COMPOSANT PUTTEXTFIELD EN IDL3 ........................81
FIGURE 36 MODELE ECATNET DU COMPOSANT PUTTEXTFIELD ..................................81
FIGURE 37 SPECIFICATION FORMELLE DU COMPORTEMENT DU
COMPOSANT PUTTEXTFIELD .....................................................................................................82
FIGURE 38 SPECIFICATION DU COMPOSANT GETTEXTFIELD EN IDL3 ........................82
FIGURE 39 MODELE ECATNET DU COMPOSANT GETTEXTFIELD ..................................82
FIGURE 40 SPECIFICATION FORMELLE DU COMPORTEMENT DU
COMPOSANT PUTTEXTFIELD .....................................................................................................83
FIGURE 41 SYNTAXE IDL3 POUR UNE FACETTE.................................................................83
FIGURE 42 SPECIFICATION DU COMPOSANT GETADAPTER EN IDL3 ...........................83

FIGURE 43 SPECIFICATION DU COMPOSANT PUTADAPTER EN IDL3............................83


FIGURE 44 MODELE ECATNET : (A) GETADAPTER, (B) PUTADAPTER...........................84
FIGURE 45 SPECIFICATION FORMELLE DU COMPORTEMENT DU
COMPOSANT ...................................................................................................................................84
FIGURE 46 ASSEMBLAGE FORMEL DES COMPOSANTS ....................................................85
FIGURE 47 SPECIFICATION COMPORTEMENTALE FORMELLE DE
LASSEMBLAGE DE COMPOSANTS ...........................................................................................86
FIGURE 48 DIAGRAMME DACTIVITE UML DU PROCESSUS DE
RESERVATION ................................................................................................................................87
FIGURE 49 MODELE ECATNET DU COMPOSANT AGNECEVOYAGE ..............................88
FIGURE 50 MODELE ECATNET DU COMPOSANT RESERVHOTEL...................................89
FIGURE 51 MODELE ECATNET DU COMPOSANT RESERVVOL........................................90
FIGURE 52 ASSEMBLAGE FORMEL DES COMPOSANTS ....................................................91
FIGURE 53 SPECIFICATION COMPORTEMENTALE FORMELLE DE
LASSEMBLAGE DE COMPOSANTS ...........................................................................................92
FIGURE 54 SPECIFICATION EN MAUDE DU MODULE FONCTIONNEL DUN
COMPOSANT ECATNETS ..............................................................................................................95
FIGURE 55 SPECIFICATION EN MAUDE DU MODULE SYSTEME DE
LAPPLICATION ..............................................................................................................................96
FIGURE 56 CHARGEMENT DE LA SPECIFICATION PAR LA COMMANDE
LOAD ..............................................................................................................................................98
FIGURE 57 RESULTAT DEXECUTION DE LA SPECIFICATION.........................................98
FIGURE 58 RESULTAT DEXECUTION DE LA COMMANDE SEARCH .........................100
FIGURE 59 RESULTAT DEXECUTION DE LA COMMANDE SHOW PATH..................101

Introduction gnrale

Introduction gnrale

Nous sommes tmoin dune norme expansion dans lutilisation du logiciel dans les
entreprises, lindustrie, ladministration, la recherche et mme dans la vie quotidienne. Le
logiciel nest plus utilis marginalement dans les systmes techniques ; au lieu de cela il est
devenu un facteur central dans beaucoup de domaines. Les systmes bass sur des
fonctionnalits logicielles deviennent le facteur le plus important dans un march
comptitif. Cette tendance, a augment les exigences sur les produits logiciels tels quune
rentabilit meilleure, la robustesse, la fiabilit, la flexibilit, ladaptabilit, et une
installation et un dploiement plus simple de ces derniers. Au moment ou ces demandes
augmente fortement, la complexit des processus que le logiciel doit contrler augmente
avec la demande pour lintgration des processus de diffrents secteurs. Par consquent, les
programmes logiciels deviennent de plus en plus grands et complexe. Le dfi principal
pour les dveloppeurs de logiciels aujourdhui est de faire face la complexit et de
sadapter rapidement au changement.
Les approches classiques de dveloppement de logiciel ont adress les dfis de la
complexit croissantes et de la dpendance des logiciels externes en se focalisant sur un
systme la fois, et sur la satisfaction des contraintes temporelles et financires de
livraison du produit sans considrer les besoins volutionnistes du systme [1]. Se
concentrer sur un systme la fois et ngliger les changements qui peuvent se produire a
men un certain nombre de problmes: lchec de la majorit des projets a satisfaire la
contrainte de date limite (deadline), de budget, de qualit aussi bien que laugmentation
continue des cots associe la maintenance du logiciel.
Une solution cl ces problmes est le Dveloppement Bas Composant DBC1. Cette
approche mergente du domaine de lingnierie logicielle est base sur la rutilisation,
o les systmes logiciels sont construits en assemblant des composants dj dvelopps et
prpars pour lintgration. Ainsi, elle possde lavantage de fournir des systmes logiciels
de qualit meilleure en un temps plus court. Construire une application est donc
considre, non pas comme un dveloppement intgral et complet ( partir de zro), mais
comme un assemblage de pices rutilisables. Dans ce domaine, les technologies qui
supporte la construction et lassemblage de composants ont atteint un premier niveau de
maturit, en particulier avec lapparition des technologies de composants standards telles
1

Nous utiliserons dans le reste de ce mmoire lacronyme anglais CBD (Component-Based Development)
la place de lquivalent franais DBC.

Introduction gnrale
que EJB (Enterprise JavaBeans), CCM (CORBA Component Model), ou (D) COM (
(Distributed) Component Object Model).
Le cur du CBD est le composant. Un composant logiciel est considr comme une
boite noire et est dcrit par ces interfaces travers lesquelles il peut interagir avec les
autres composants dans le systme. Il offre des services et requiert dautres pour accomplir
ces fonctionnalits. Le but ultime du dveloppement logiciel bas composant est
lassemblage effectu par les tierces parties. Pour ce faire, il est ncessaire dtre en
mesure de spcifier les composants de faon ce que nous pouvons raisonner sur leurs
constructions et leurs compositions [46].
Les spcifications de composants utiliss dans la pratique du dveloppement logiciels,
sont aujourdhui essentiellement limites ce que nous appelions les spcifications
syntaxiques. Cette forme de spcification comprend les spcifications utilises dans des
technologies comme COM, CORBA, et JavaBeans [1]. Les deux premires utilisent les
IDLs (Interface Description Langage), alors que le troisime utilise le langage de
programmation Java. Or, les spcifications syntaxiques noffre pas suffisamment
dinformations sur la smantique des oprations qui dfinissent les interfaces dun
composant, ce qui peut aider mieux les inspects, les valus, et comprendre leurs
comportements.
Les mthodes de spcification formelles sont de bons candidats pour la spcification
des composants logiciels. On entend par mthodes formelles, les langages, techniques, et
les outils bass sur la logique mathmatique [47]. En effet la base des mthodes formelles
est de nous permettre de construire des modles mathmatiques avec une smantique bien
dfinie du systme analyser. Les rseaux de Petri sont considrs comme des
formalismes de spcification dots dune dfinition formelle permettant de construire des
modles exempts dambigut. Ils possdent un grand pouvoir dexpression facilitant la
description des systmes complexes, concurrent et distribus.
Les ECATNets [48] (Extended Concurrent Algebraic Term Nets) constituent une
catgorie des rseaux de ptri algbriques de hauts niveaux. Ils ont t proposs comme
tant une manire pour la spcification, la modlisation, et la validation des applications du
domaine des rseaux de communication, la conception des ordinateurs, et dautres
systmes complexes. Ils sont construits autour dune combinaison de trois formalismes.
Les deux premiers formalismes constituent un modle rseau/donnes, et sont utiliss pour
la dfinition de la syntaxe du systme, en dautres termes pour capturer sa structure. Le
modle du rseau, qui est un type de rseaux de Petri avanc, est utilis pour dcrire
larchitecture du processus du systme, le modle de donnes, qui est un formalisme
algbrique est utilis pour spcifier les structures de donnes du systme. Le troisime
formalisme, qui est une logique de rcriture est utilis pour dfinir la smantique du
systme, en dautres termes, pour dcrire son comportement.

Introduction gnrale
Lobjectif de lingnierie logicielle base composant (CBSE) est daccrotre la
productivit, la qualit, et le temps de mise sur le march dans le dveloppement logiciels.
Les techniques dingnierie logicielles base composant dans les phases, de modlisation,
de vrification, ou de validation des systmes logiciels base de composants restent
insuffisantes et demande plus defforts de recherche.
Notre travail sinscrit dans le vaste domaine du gnie logiciel base de composants.
Son objectif, est de proposer une approche formelle pour la modlisation des logiciels
base de composant en utilisant les ECATNets. Notre choix sur les ECATNets est motiv
dune part, par la puissance dexpression de ces derniers dus leurs notations syntaxiques
trs riches bases sur un formalisme algbrique, permettant de fournir des modles
hautement compacts. Dautre part, ils possdent une smantique saine dfinit en terme de
la logique de rcriture permettant dexprimer remarquablement et intuitivement le
comportement dynamique et le paralllisme qui caractrise les systmes distribus. Elle
donne aussi la possibilit dappliquer la vrification formelle par le biais de spcification
excutable exprime en langage Maude, le langage de la logique de rcriture.
Dans notre approche nous distinguons trois tapes ; la premire consiste en la
spcification des interfaces de chaque composant dans le systme base de composants
ainsi que, les connexions entre eux en utilisant les notations proposes. Le rsultat de cette
tape est un modle ECATNet reprsentant la spcification dun assemblage de
composants. Dans la deuxime tape, le comportement dynamique du systme est exprim
par des rgles de rcriture gnres partir du modle spcifi dans ltape prcdente.
La dernire tape reprsente la vrification du systme via une spcification excutable en
langage Maude qui intgre les rgles de rcriture engendres dans ltape prcdente. A
travers ce travail nous esprons atteindre les objectifs suivants :
9 Premirement, offrir une notation convenable pour dcrire le comportement
interne des composants logiciels concurrents et distribus.
9 Deuximement, offrir une smantique formelle non ambigu pour les
caractristiques des composants logiciels.
9 Troisimement, offrir un raisonnement formel sur lassemblage des composants
logiciels.
9 Quatrimement, permettre la vrification formelle du systme modlis.
Ce mmoire est structur suivant trois chapitres :
-

Dans le premier chapitre nous allons introduire les approches classiques du


dveloppement logiciel, ensuite nous prsenterons lapproche de dveloppement
logiciel base de composants et les notions qui lui sont relies tel la notion de
rutilisation, composant logiciel,etc. Nous parlerons ventuellement des racines de
cette approche et de quelques modles de cycles de vie qui ont t proposs dans son
contexte.

Introduction gnrale
-

Le deuxime est destin la prsentation des ECATNets et la logique de rcriture.


Nous commenons par un bref survol sur les RdPs, puis nous introduisons la logique
de rcriture et son langage Maude comme tant un Framework qui intgre les
ECATNets. Ensuite nous dtaillons ces derniers et nous montrerons comment peuventils tre utiliss pour la spcification des systmes.
Le dernier chapitre est consacr la prsentation de notre approche pour la
modlisation des logiciels base de composants.
Le prsent mmoire est achev par une conclusion gnrale et des perspectives.

CHAPITRE I

Dveloppement logiciel base de composants

CHAPITRE I :

Dveloppement logiciel base de


composants

1. Introduction
Les systmes logiciels modernes sont de plus en plus grands, complexes et mal
contrls, ce qui a entran des cots de dveloppement levs, une faible productivit, et
une qualit incontrlable des produits logiciels [8]. Par consquent, il y a une demande
croissante pour la recherche dun nouveau paradigme du dveloppement logiciel, efficace
et rentable.
Une solution cl ces problmes est le Dveloppement Bas Composant CBD. Cette
approche mergente du domaine de lingnierie logicielle est base sur la rutilisation,
o les systmes logiciels sont construits en assemblant des composants dj dvelopps et
prpars pour lintgration. Cette approche va tre le sujet de ce chapitre dans lequel nous
allons prsent plus de dtails, mais avant cela ; il est intressant de ce positionner dans
lchelle de la chronologie des choses, et jeter un coup dil sur les approches classiques
de dveloppement logiciel par un historique non dtaill sur ces derniers qui montre leur
volution dans le temps.

2. Processus logiciel
Tout logiciel, particulirement les grands logiciels produits par beaucoup de gens,
devrait tre produit en utilisant un certain type de mthodologie. Une mthodologie est une
manire systmatique de faire les choses. Cest un processus rptitif que nous pouvons
suivre partir des premiers pas du dveloppement logiciel jusqu la maintenance dun
systme oprationnel [2]. Un systme logiciel peut tre considr dun point de vue cycle
de vie. Ceci signifie quon observe le systme depuis la premire notion de son existence
jusqu son fonctionnement et sa gestion [1]. Plusieurs diffrentes approches ont t
proposes pour le dveloppement du cycle de vie dun logiciel, ces dernires sont toutes
bases sur les mmes activits et se diffrent seulement par la manire dont elles sont
ralises.
5

CHAPITRE I

Dveloppement logiciel base de composants

2.1 Activits gnriques du cycle de vie dun logiciel


Cest sans doute Royce (1970) qui, tait le premier, a propos un modle du cycle de
vie. Depuis, de nombreuses amliorations et modifications y ont t apportes [49]. Il y a
un certain nombre de phases communes chaque dveloppement, indpendamment de la
mthodologie, en commenant par la capture des besoins et finir avec la maintenance.
Nous allons essayer dans ce qui suit de prsenter une brve description des diffrentes
phases constituant le cycle de vie dun systme logiciel daprs [1].
a. Analyse de besoins et spcification du systme
Dans cette phase les services, les contraintes, et les objectifs du systme sont tablis.
Ils sont dfinis en dtail et servent de spcification au systme.
b. Conception du systme et du logiciel
La conception du logiciel implique didentifier et de dcrire les abstractions
fondamentales du systme logiciel et les relations entre elles. Une architecture globale pour
le systme est dfinie suivie dune conception dtaille.
c. Implmentation et tests unitaires
La formalisation de la conception sous une forme excutable. Elle peut tre compose
de petites units. Les units sont vrifies vis--vis de leurs spcifications.
d. Intgration, vrification du systme et validation
Les units du systme sont intgres; le systme complet est vrifi, valid, et dlivr
au client.
e. Opration de support et maintenance
Le systme est oprationnel. Il requiert un support continu et des oprations de
maintenance.
f. Suppression du systme
Cette activit est souvent oublie dans le cycle de vie dun systme. Elle concerne la
suppression propre du systme et ventuellement son remplacement par un autre.
2.2 Modles de cycle de vie dun logiciel
Il faut un temps considrable pour dvelopper un grand systme logiciel qui,
dailleurs, sera utilis pendant trs longtemps. On identifie donc un certain nombre
dtapes distinctes dans cette priode de dveloppement et dutilisation ; ces tapes
constituent le cycle de vie du logiciel. Plusieurs diffrentes approches pour le cycle de vie
de dveloppement dun logiciel sont considres ci-dessous ainsi quune brve description
de leurs caractristiques de base. Dans la littrature en trouve plusieurs classification de ces
approches les sparant en deux classes : modles linaire et modles non linaire, ou bien
modles squentiel et modles volutionnistes. Nous avons adopt la deuxime appellation
qui est la plus utilise.
6

CHAPITRE I

Dveloppement logiciel base de composants

2.2.1 Modles squentiels


Le modle squentiel (par exemple, le modle en cascade de Royce 1970) suit une
approche squentielle systmatique qui commence au niveau du systme et progresse
successivement de lanalyse jusqu la ralisation. Chaque activit doit tre considre
comme approuve avant que la prochaine activit commence. La sortie dune activit est
lentre de la prochaine. Cette approche pour le dveloppement de logiciel (figure 1) est la
plus vieille et la plus rpandue.

Analyse
Conception
Implmentation
Intgration
Test
Fig. 1 Le modle squentiel [1]
Beaucoup de problmes majeurs dans lingnierie logicielle rsultent du fait quil est
difficile lutilisateur dexprimer explicitement tous les besoins. Le modle squentiel
exige la spcification complte des besoins ce qui peut causer des difficults dadaptation
face lincertitude naturelle qui existe au dbut de beaucoup de projets. Il est galement
difficile dajouter ou changer des besoins durant le dveloppement car, une fois ralises,
les activits sont considres comme accomplies. Un autre problme parfois rencontr
quand un modle squentiel est appliqu est la rponse en retard au client. Cette approche
rigide souffrira toujours du fait dtre concentr rsoudre un problme particulier, ce qui
rend la tache de produire du code rutilisable plus difficile et par consquent mal adapte
au monde composant [3].
2.2.2 Modles volutionnistes
Les modles volutionniste permettent de dvelopper un systme graduellement par
itrations successives. A chaque tape, le rsultat du systme est montr ses
commanditaires et leurs remarques sont prises en compte pour faire voluer le systme [3].
Lintrt de ce type de modle est de rduire fortement le risque de dcouvrir un problme
crucial tard dans le cycle de dveloppement. Il permet galement une meilleure gestion des
changements de besoins apparaissant durant le processus de dveloppement. Le problme
de ce type de processus est quil peut engendrer un nombre coteux ditrations. Il peut,
par exemple, tre difficile de dterminer le nombre exact ditrations lavance, et de
nouvelles itrations peuvent tre ajoutes si les besoins changent ou voluent. Il existe
plusieurs types de modles volutionnistes. Lapproche itrative, le modle incrmental, le
modle par prototypage, et enfin, le modle spirale dfini par Boehm [4].

CHAPITRE I

Dveloppement logiciel base de composants

2.2.3 Processus unifi


Le processus de dveloppement logiciel unifi (UP2) dfinit par Jacobson et al [5] est
un processus de dveloppement de systme optimis pour les applications objets et les
systmes base de composants. Il sagit dun dveloppement incrmental itratif compos
de quatre phases :
1. Analyse des besoins, cest la phase o le systme est dcrit dune manire
formalise, fournissant ainsi une base pour le dveloppement ultrieur;
2. Elaboration, lors de cette phase larchitecture du systme est dfinie et cre;
3. Construction, le dveloppement des produits compltement nouveaux, avec des
possibilits de rutilisation;
4. Transition, concerne la livraison du systme au client. Cette phase inclut
linstallation du systme et la formation de ses utilisateurs.
Pour chacune de ces tapes, il y a plusieurs itrations des activits classiques. Ces
activits se produisent dans chacune des quatre phases, Analyse des besoins, laboration,
construction, et transition. Cest la partie itrative de lUP. La partie incrmental est base
sur le fait que les itrations russies auront comme consquence le dgagement dun
systme. Ce modle est mieux adapt au monde composant. De plus il est souvent utilis
avec UML, dont la version 2.0 prend en compte la conception des applications base de
composant.
Phases
Analyse des
besoins

Elaboration

Construction

Expression des
besoins

Transition

Une itration
dans la phase

Analyse
Conception

Implmentation
Test

Itrations

Fig. 2 Les quatre phases de lUP et ces activits [1]

Unified Process

CHAPITRE I

Dveloppement logiciel base de composants

3. Approche de rutilisation
Les systmes logiciels modernes deviennent de plus en plus grands, complexe et
difficile contrler, rsultant en un cot de dveloppement lev, une productivit faible,
une qualit incontrlable du logiciel et le gros risque pour se dplacer vers une nouvelle
technologie [8]. Par consquence, il y a une demande croissante sur la recherche dun
nouveau paradigme efficace, et rentable pour le dveloppement de logiciel.
Une des solutions les plus prometteuses est aujourdhui lapproche de dveloppement
de logiciel bas composant (CBD). Cette approche est base sur lide que les systmes
logiciels sont construits en assemblant des composants dj dvelopps et prpars pour
lintgration avec une architecture logiciel bien dfinit [1]. Cette nouvelle approche de
dveloppement de logiciel est diffrente des approches traditionnelles dans lesquelles les
systmes logiciels sont construits partir de zro.
3.1 Dveloppement bas composant CBD
Les praticiens dfinissent le dveloppement bas composant (CBD) comme approche
dans laquelle tout Artefact (code excutable, spcification dinterface, architectures,
modles, et partant du plus haut niveau des applications et des systmes complets jusquau
niveau des composants individuels) peut tre construit en assemblant, adaptant, et en liant
les composants existant ensemble dans une varit de configurations [12].
Cette dfinition met en relief un aspect important du dveloppement bas composant
(CBD), savoir la capacit de construire des systmes par assemblages de composants
prexistants. Dautre part, afin de pouvoir assembler des composants, ces composants
doivent dabord exister. Plusieurs organismes prtendent quils construisent des logiciels
en utilisant une approche base composant, et que lindustrie entire est apparemment dans
une frnsie dadoption du CBD. Une autre dfinition qui a t donne au CBD est la
suivante :
Le dveloppement bas composant est une approche de dveloppement logiciel o
tous les aspects et phases du cycle de vie y compris lanalyse de besoins, la conception, la
ralisation, test, dploiement, les infrastructures techniques supports, et galement la
gestion de projet, sont bass sur les composants [12]. Cette dfinition montre explicitement
que le dveloppement bas composant consiste en la construction de logiciel en utilisant un
raisonnement bas composant dans la mesure o tout le dveloppement logiciel sera centr
sur les composants. CBD est extrmement bnficial non seulement quand les composants
sont disponibles pour lassemblage, mais aussi si ces composants doivent tre construits en
tant des lments du projet. En effet, penser un systme dinformation en termes de
composants, mme si ces composants nexistent pas, est la meilleure manire de matriser
les complexits de dveloppement de grand systme distribu aujourdhui.

CHAPITRE I

Dveloppement logiciel base de composants

3.2 Racines du CBD


Construire des systmes complexes partir de composants plus simples nest pas une
invention de lindustrie logicielle. Il y a plus de deux sicles, Eli Whitney a propos la
fabrication de fusils avec des pices remplaables spcifis clairement selon des modles,
au lieu de construire chaque fusil individuellement. Largement considr comme le
commencement de fabrication en srie, cette stratgie des composants remplaables a
men une augmentation impressionnante de la capacit de production, en outre elle a
fournit des avantages additionnels tel que, des oprations fiables et une maintenance facile
dans divers secteurs industriels, et elle est devenu une approche standard dans par exemple
la construction de divers dispositifs lectroniques et dans lingnierie des systmes avancs
[10].
Dans le domaine de lingnierie des systmes dinformation, le CBD est galement
considr comme une approche volutionniste plutt que rvolutionnaire. Il a exist dans
une forme ou une autre pendant un certain nombre dannes. Lide de construire un
systme logiciel modulaire a t longtemps reconnue comme avantageuse au sein de la
communaut software. Ceci remonte aux jours de la programmation structure en utilisant
des sous-programmes et des bibliothques servant de composants. Les programmes ont
t construits en crant un programme principal pour contrler (ou appeler) un certain
nombre de sous-programmes. Pour rduire les efforts de programmation, les programmeurs
dans une quipe de projet rutilisaient des sous-programmes durant la ralisation du projet
[11]. Durant la confrence de lOTAN de lingnierie logicielle, en 1968, M. D. Mcilory a
prsent le concept de composants logiciels. Ces derniers ont t vus comme solution pour
la crise logicielle [10].
Depuis la fin des annes 70 jusquaux annes 80, les ingnieurs utilisaient une
mthodologie de dveloppement logiciel structure pour diviser un systme en un certain
nombre de modules en se basant sur ses besoins fonctionnelles. Aprs que les modules
aient t dvelopps, ils les intgrent pour former un systme. Durant cette priode de
temps, beaucoup de bibliothques de fonction ont t dveloppes en langage de
programmation Fortran comme tant des packages rutilisables pour supporter le
dveloppement dapplications scientifiques. Ces packages peuvent tre considrs comme
la premire gnration de composants logiciels [11].
Durant les annes 90 les techniques orientes objet ont t considres comme un
moyen puissant pour rsoudre le problme de la crise logicielle grce au niveau lev de
rutilisation et de maintenance atteint par ces derniers. Quelques auteurs ont cit que le
CBD est une extension et volution naturelle du paradigme orient objet, et quil contient
beaucoup de caractristiques et de concepts semblables. Dautres insistent sur lchec de la
technologie objet pour rsoudre les problmes de rutilisation des logiciels et sur la
ncessit dintroduire un nouveau paradigme de dveloppement de composant [10]. Le
travail ralis par Nierstrasz (1995) qui est en relation avec la composition logicielle pour
les systmes ouverts distribus, peut tre considr comme une importante contribution
10

CHAPITRE I

Dveloppement logiciel base de composants

aux futurs concepts et ides du CBD. Au cours des dernires annes la recherche lie aux
composants a galement t mene sur divers sujets tels que les langages dinterconnexion
de module (MILs3), spcification et analyse des interfaces de module, gnrateurs de
logiciel, les Frameworks orients objets et les patterns, langages de description
darchitecture (ADLs4).
Les composants ont t initialement introduits au niveau implmentation pour la
construction rapide dinterface utilisateur graphique en utilisant VBX (Visual Basic
eXtensions) ou Java. Aprs, Microsoft ActiveX/DCOM/COM, objets et services de
CORBA, et JavaBeans, suivis de Microsoft COM+/.NET, les composants CORBA et
Entreprise JavaBeans (EJB) ont t proposs comme des technologies de composants
standards.
Lobjectif commun de toutes ces initiatives est de basculer depuis le dveloppement de
petits systmes monolithiques centraliss vers le dveloppement de systmes complexes
composs dunits fonctionnelles dployes sur les noeuds du Web. Les deux concepts
principaux qui ont merg sont [10]:
1. Les composants en tant que entits dun systme de granularit forte.
2. Les architectures et les Frameworks comme modles de systme dcrivant ses
principaux modules et la manire de les composer en un tout cohrent.
3.3 Processus de dveloppement dapplications bass composants
Un des objectifs du CBD est de gnraliser la rutilisation de modules logiciels.
Lintrt majeur de la rutilisation est de rduire leffort de dveloppement en rutilisant
des parties de logiciels dj dveloppes. Plus un composant est rutilis, plus les
ventuels bogues quil pouvait contenir peuvent avoir t dtects et corrigs.
Le processus de dveloppement des applications bases composants repose
globalement sur les mmes activits que le dveloppement dune application classique.
Cependant, il diffre des dveloppements traditionnels notamment travers sa focalisation
sur lidentification dentits rutilisables et les relations entre-elles et ce, notamment
partir de lanalyse des besoins. La rutilisation de composants implique un processus
didentification et de slection du composant rutiliser, voir un processus de spcification
de celui-ci en vue de son dveloppement dans le cas o il nexisterait pas. Laspect
modularit implique un effort important de la conception de larchitecture de lapplication,
ce qui ntait pas forcment le cas dans les dveloppements classiques. Les modles de
dveloppement classiques se prtent plus ou moins supporter le dveloppement base de
composants.

3
4

Module Interconnection Languages


Architecture Description Languages

11

CHAPITRE I

Dveloppement logiciel base de composants

Comme on la cit plus haut dans ce chapitre, le modle squentiel correspond une
tude squentielle du systme, de la phase de recueillement des besoins jusqu la fin du
cycle de vie. Chaque activit est termine avant de passer la suivante. Cette approche
rigide est mal adapte au monde composant. En effet, le dveloppement base de
composants est typiquement un dveloppement o des phases peuvent tre menes en
parallle. Par exemple, si la phase danalyse dtermine le besoin spcifique dun
composant particulier, le modle squentiel implique de terminer la phase danalyse avant
de spcifier le composant dvelopper. Or, il aurait peut tre tait plus prudent de
commander le dveloppement de ce composant, un ventuel fournisseur, le plus tt
possible, de manire tenir compte de son temps de dveloppement.
Outre le modle squentiel, les modles volutionnistes aussi sont mal adapts au
monde composant car elles nont pas taient conues autour de la problmatique de la
rutilisation. Le processus unifi est mieux adapter au monde composant car il est souvent
utilis avec UML (Unified Modelling Language) dont la version 2.0 prend en compte la
conception des applications base de composant comme dj mentionn plus haut.
Cependant [3], il ne traite rellement les aspects rutilisation que lors de la phase
dimplmentation, ce qui est trop tard la plus part du temps, pour une rutilisation efficace.
Les modles de lingnierie logicielle classique pouvaient tre utiliss comme base pour le
dveloppement dapplication base de composants. Ils sont toutefois mal adapts et
notamment sur deux aspects [13]. Premirement, la rutilisation de composants est
gnralement envisage trop tard dans le cycle de vie du logiciel, notamment aprs que la
conception dtaille ait t finalise, alors quune rutilisation optimale des composants
requiert galement la rutilisation des architectures logicielles. Deuximement, aucune
mthode existante ne donne de consigne prcise sur la manire dont un composant doit tre
dvelopp pour tre rutilisable. Les mthodes classiques devront donc tre adaptes pour
prendre en compte les particularits de ce type de dveloppement, notamment en insistant
sur les aspects dveloppement de composants rutilisables, mais aussi sur les aspects
dveloppement de systmes partir de composants [14].
Nous allons essayer dans les prochaines sections dexpliquer le processus de
dveloppement des applications base de composants et de prsenter quelques modles de
cycle de vie pour le dveloppement bas composant, ces derniers reprsentent les efforts
des chercheurs durant ces dernires annes dans lingnierie logicielle base composant
CBSE5. Mais avant cela nous nous penchons sur quelques aspects important qui
caractrisent le processus de dveloppement des applications base de composants.
3.3.1 Notion de rutilisation
Le dveloppement bas composant CBD, provient de la rutilisation. Lapproche de
rutilisation nest pas nouvelle. La rutilisation est la philosophie de trouver des ressources
appropries, telle des modles, des diagrammes, des fragments de code, ou de composants,
5

Nous utiliserons dans le reste de ce mmoire lacronyme anglais CBSE (Component-Based Software
Engineering) la place de lquivalent franais ILBC.

12

CHAPITRE I

Dveloppement logiciel base de composants

qui peuvent fournir une solution de dpart. La rutilisation est une philosophie de
dveloppement de systmes qui peut tre adopte dans une organisation si elle veut
atteindre son potentiel en termes dune rduction du temps de dveloppement du projet et
dune minimisation des cots [16].
La rutilisation fut voque en 1968 par M. McIlroy dans une confrence de lOTAN
sur lingnierie du logiciel, suite a un chec patent de la part de dveloppeurs pour livrer
des logiciels de qualit a temps et a prix comptitifs. Elle vise donc trois objectifs :
diminuer les cots de dveloppement et de maintenance, rduire le temps de mise sur le
march (time-to-market), et amliorer la qualit du logiciel. La rutilisation se dfinit
comme une nouvelle approche de dveloppement de systmes, qui propose notamment de
construire un systme nouveau partir de composants logiciels sur tagre (COTS,
Commercial Off The Shelf) qui se dfinissent comme tant un type particulier de
composant. Elle soppose ainsi aux approches traditionnelles de dveloppement, dans
lesquelles la construction dun nouveau systme part de rien (from scratch) et ncessite de
rinventer de grandes parties dapplications a chaque fois.
Depuis, cette ide sest impose et la rutilisation constitue un enjeu majeur de
recherche en ingnierie des systmes base de composants. Les recherches sur la
rutilisation ont progressivement volu ces dernires annes, passant de la rutilisation de
code la rutilisation de connaissances et de dmarches de raisonnement de diffrents
niveaux. Cette pratique pressente un enjeu supplmentaire pour garantir une meilleure
qualit des dveloppements [15].
En parlant de composants logiciels dont nous nous somme intress dans ce mmoire
et qui constituent lun des types de composants parmi ceux classifis dans la littrature (
nous avons pris le choix dattarder leurs prsentation dans ce chapitre pour des raisons
purement pdagogiques), il est utile de distinguer entre la rutilisation bote blanche dans
laquelle limplmentation des composants rutiliss est expose un certain degr, et la
rutilisation bote noire, dans laquelle les composants ne peuvent tre rutiliss que selon
une interface de rutilisation spcialement fournit, ou contrat6 [13].
Une rutilisation de type bote noire consiste rutiliser le composant tel quel
sans aucune vision de la manire dont il est implment et sans aucune
modification de code de la part du dveloppeur de lapplication.
La rutilisation par approche bote blanche, par opposition lapproche
prcdente, consiste rutiliser un composant en ayant accs son
implmentation et en permettant sa modification (adaptation). Ce type fait
lesprit des technologies open source : il est possible de rutiliser des
technologies pour les adapter ses propres besoins.
Des auteurs dans ce domaine ont montr une prfrence pour la rutilisation boite
noire tel est le cas pour Nierstrasz [13]. La facilit dutilisation est obtenue en fournissant
6

La notion de contrat sera explique plus loin dans ce chapitre

13

CHAPITRE I

Dveloppement logiciel base de composants

des interfaces boite noire aux composants qui, dune part limite la faon dont les
composants peuvent tre utiliss, et dautre part, limite le besoin de comprendre les dtails
dimplmentation des composants. La vision historique de la rutilisation logiciels est la
cration de systmes logiciels partir dlments logiciels prexistant au lieu de les cres
partir de zro. Le processus de la rutilisation logiciels se divise en deux parties
correspondantes: lingnierie pour la rutilisation, et lingnierie avec la rutilisation [17].
La section suivante traite ces types de rutilisation.
3.3.2 Processus de rutilisation
Deux processus complmentaires sont considrs dans le dveloppement bas
composant : lingnierie de composants rutilisables (design for reuse) et lingnierie de
systmes par rutilisation de composants (design by reuse). Nous allons discuter ces
processus sparment. Dans des situations relles, ils seront combins, et peuvent ne pas
tre distingus, comme tant des activits spares. Toutefois, la sparation de ces
processus est une caractristique particulire de lapproche base composant [1].
a. Ingnierie de systmes par rutilisation (Design by Reuse)
Le dveloppement de systmes par assemblage de composants est similaire celui des
applications qui ne sont pas bases sur les composants. Il y a toutefois, une diffrence
cruciale dans le processus de dveloppement de systmes base de composant. Lintrt
nest pas focalis sur limplmentation du systme conu, mais sur la rutilisation de
composants prexistants. [18] dfinit le dveloppement de systmes logiciels par
rutilisation comme le dveloppement de systmes en utilisant des composants
rutilisables. Lingnierie de systmes par rutilisation couvre les taches de recherche, de
slection ou de cration de composants propritaire comme alternative, dadaptation pour
intgration, de composition et dploiement des composants, et remplacement de
composants.
1) Recherche de composants
La recherche de composants consiste rechercher un composant parmi une collection,
permettant de rpondre un problme particulier. Elle tient donc compte du besoin du
dveloppeur. Pour accomplir avec succs cette procdure, un grand nombre dventuels
candidats de composants doivent tre disponibles ainsi que les outils pour les trouver.
2) Slection
Slectionnez les composants qui rpondent aux exigences du systme. Souvent, les
exigences ne peuvent pas tre satisfaites compltement et un effort supplmentaire
danalyse est ncessaire pour adapter larchitecture du systme et de reformuler les besoins
pour permettre lutilisation des composants existants.

14

CHAPITRE I

Dveloppement logiciel base de composants

3) Cration de composants
Alternativement, la cration de composants propritaires qui vont tre utiliss dans le
systme peu se produire au lieu dune slection dun entrept de composants. Dans une
approche CBD, cette procdure est moins attrayante car elle exige plus defforts et de
temps. Toutefois, les composantes de base incluant les fonctionnalits du produit sont
susceptibles dtre dveloppes en interne du fait quils peuvent fournir un aspect
comptitif du produit.
4) Adaptation
Une fois slectionn, le composant doit tre adapt au contexte du systme en cours de
dveloppement. Il doit correspondre au modle de composant existant ou la spcification
des besoins. Certains composants peuvent tre directement intgrs au systme, dautre
doivent tre modifis par un processus de paramtrisation, certains auraient besoin de code
glu pour ladaptation. Le code glu est le code ajout aux composants afin de les rendre
compatibles avec un environnement dans lequel ils nont pas t conus pour fonctionner
[3].
5) Composition et dploiement (intgration)
Dite aussi phase dintgration. La phase dintgration du systme est la phase durant
laquelle les composants slectionns et dvelopps sont composs (cest--dire assembls
entre eux) pour crer le systme et cela en utilisant un Framework pour les composants.
Typiquement, les modles de composants fournissent ces fonctionnalits.
6) Remplacement
Le remplacement des versions de composants anciennes par les nouvelles. Cela
correspond la phase de maintenance du systme. Les bugs sont limins et de nouvelles
fonctionnalits peuvent tre ajoutes au systme.
b. Ingnierie de composants rutilisables (Design for Reuse)
Elle vise dvelopper des mthodes et des outils pour supporter le processus de
production de composants mis en uvre par le concepteur de systmes de rutilisation
[19]. Lingnierie de composants rutilisables recouvre les taches didentification, de
spcification, de qualification, dorganisation et dimplmentation de composants.
Lensemble de ces taches est essentiel, puisquil a pour objectif de produire les ressources
ncessaires la mise en uvre dune approche dingnierie par rutilisation.
1) Identification
Lidentification des ressources candidates la rutilisation, soit par ltude de
systmes existants, soit par lanalyse de domaine. Les connaissances susceptibles de
15

CHAPITRE I

Dveloppement logiciel base de composants

contenir des lments rutilisables et approuvs peuvent tre des produits de


dveloppement existants (programmes, modles conceptuels, etc.), ou des expressions de
connaissances (documents techniques, etc.).
2) Spcification
La spcification doit favoriser la rutilisation des composants tout en fournissant
lensemble des informations utiles et ncessaires leurs bonnes utilisations (telles que les
indications et les contraintes dutilisation, les forces de la solution propose,). Elle doit
permettre de dcider, par exemple, de la pertinence dutiliser un composant ou un autre au
moment de la recherche de ceux-ci. La rutilisation des composants est plus efficace sils
sont associes a une spcification pertinente. Deux techniques sont utilises dans tout
modle de spcification pour la spcification des composants : labstraction et la
gnricit. La premire consiste distinguer deux types de connaissances dans la
spcification dun composant : les connaissances effectivement rutilisables (un modle
sil sagit dun composant conceptuel par exemple, ou un fragment de programme sil
sagit dun composant logiciel) et celles requises pour une utilisation correcte de celui-ci
[15]. La deuxime introduit une forme de variabilit dans la spcification des composants.
En effet, le plus souvent, la solution propose par un composant noffre quune ralisation
possible de celui-ci. Pour augmenter sa rutilisation, un composant doit offrir plusieurs
ralisations possibles : sa solution doit ainsi tre flexible afin de pouvoir ladapter aux
spcificits du systme en cours de dveloppement.
3) Qualification
La qualification des composants sapparente une forme de validation de ceux-ci. Elle
consiste vrifier la qualit de composants identifis du point de vue de leur rutilisation.
4) Organisation
Lorganisation des composants traite diffrents types de liens entre ceux-ci, afin de
pouvoir utiliser conjointement plusieurs composants pour obtenir des architectures plus
importantes. Elle a donc une influence directe sur la manire dexploiter les composants
dans le processus dingnierie de systmes base de composant. Elle facilite la slection
de composants et amliore leur rutilisation.
5) Implmentation
Limplmentation des composants consiste a outiller la rutilisation (gestion
automatique de leurs collections, recherche, slection, composition, adaptation, ) de
ceux-ci.
Ces diffrentes techniques contribuent la mise en place de bases de composants pour
capitaliser des savoirs et des savoir-faire rutilisables dans le cadre dune ingnierie par
rutilisation.
16

CHAPITRE I

Dveloppement logiciel base de composants

Fig. 3 Ingnierie pour la rutilisation et ingnierie par rutilisation [19]


Lobjectif du dveloppement pour la rutilisation est de construire des composants
rutilisables qui rpondent un ensemble de contraintes de qualit et de rutilisation. Le
dveloppement de composants rutilisables se focalise sur les critres de qualit au
dtriment des cots de production du composant [18]. Les activits de dveloppement par
rutilisation se focalisent sur lensemble du processus de dveloppement, de
lidentification, et la recherche de composants rutilisables dans la base de composants
rutilisables, jusqu la construction de nouveaux composants (pas ncessairement ceux
rutilisables) par ladaptation ou la composition de composants rutilisables.
3.3.3 Cycle de vie pour le CBD
Lingnierie logicielle base composant CBSE aborde des dfis et des problmes
similaires ceux rencontrs en ingnierie logicielle. Beaucoup de mthodes, doutils et
principes en ingnierie logicielle utiliss dans dautres types de systme sont utiliss dune
manire identique ou similaire dans la CBSE. Il y a toutefois, une diffrence: la CBSE se
concentre sur les questions relatives aux composants et, dans ce sens, elle distingue le
processus de dveloppement des composants de celui du dveloppement de systme avec
des composants [14].
Il est important de remarquer que les diffrentes activits constituant les deux
processus peuvent tre ralises indpendamment les unes des autres. En ralit [1], les
deux processus sont rellement spars parce que de nombreux composants sont
dvelopps par des tierces parties, indpendamment du dveloppement du systme.
Cependant, dans des situations relles ils sont combins et peuvent ne pas tre distingus
comme activits spares.
17

CHAPITRE I

Dveloppement logiciel base de composants

Comme les logiciels sont de plus en plus complexes, il en va de mme pour leffort
ncessaire pour leur production, et dans ce sens de nombreux modles de cycle de vie de
logiciel ont t proposs. Leur principale utilit est didentifier et dorganiser les phases et
les tapes impliques dans le dveloppement et lvolution des logiciels [20]. Il y a une
diffrence significative entre lapproche de dveloppement logiciel bas composant et les
approches de dveloppement logiciel traditionnelles. Une standardisation technique est
ncessaire, et une mthode adapte au CDB doit tre suivi [21]. Les processus de cycle de
vie incluent toutes les activits dun produit ou un systme durant toute sa vie, en
commenant depuis lide de lentreprise pour son dveloppement, jusqu son utilisation
et sa mise hors service. Diffrents modles ont t proposs et exploits dans lingnierie
logicielle. Nous avons mentionn dans la section 2.2 que deux principaux groupes de
modles peuvent tre distingus: squentiel et volutionniste. Les modles squentiels
dfinissent une squence dactivits dans laquelle le passage vers une autre activit ne se
fait quaprs achvement de celle en cours. Les modles volutionnistes permettent
lexcution de plusieurs activits en parallle sans lexigence de complter une activit
pour pouvoir commencer une autre. Ces modles peuvent tre appliqus dans le
dveloppement bas composant, mais doivent tre adapts aux principes de lapproche
base composant [22]. Dans ce cadre, divers modles de cycle de vie pour le
dveloppement bas composant ont t proposs. Nous allons prsenter brivement dans la
section suivante la philosophie gnrale de quelques un. Indpendamment du type de
modle, nous pouvons identifier les activits de base prsentes dans tout modle de cycle
de vie quon a prsent dans la section 2.1.
a. Modle en V
Dans le modle en V (figure 4) adopt pour lapproche de dveloppement base
composant propos par [22], durant le cycle de vie dun produit logiciel (franchissant les
phases de dveloppement et de maintenance), un entrept de composants est mis
disposition depuis lequel les composants peuvent tre slectionns dans les phases initiales,
et dans lequel les composants peuvent tre ajouts dans les phases ultrieures (les
composants nouvellement dvelopps pour une application) [21].
Dans ce modle le processus commence dune manire habituelle par lingnierie des
besoins et la spcification des besoins, o les analystes essayent de trouver, partir dun
entrept de composants (chercher puis slectionner) ceux pouvant satisfaire les besoins
spcifis. Dans une approche classique le processus continuerait avec la conception,
limplmentation et les tests. Si de tels composants ne sont pas disponibles, alors les
besoins sont probablement ngocis et modifis afin de pouvoir utiliser les composants
logiciels disponibles.

18

CHAPITRE I

Dveloppement logiciel base de composants

Fig. 4 Modle en V adopt pour le dveloppement bas composant [22]


b. Modle en Y
Le modle en Y (figure 5) a t propos comme alternative viable pour adresser la
rutilisation de logiciels durant la production de systmes logiciels bas composant [20].
La cration de logiciels se caractrise par le changement et linstabilit, par consquent la
reprsentation schmatique du modle en Y permet le recouvrement de phases et des
itrations quand cest ncessaire. Bien que les phases principales peuvent se recouvrir et
litration est permise, les phases prvues sont: ingnierie de domaine, tablissement de
Framework, assemblage, archivage, analyse du systme, conception, implmentation, test,
dploiement et maintenance.
La caractristique principale de ce modle de cycle de vie dun logiciel est sa
focalisation sur la rutilisation pendant la cration et lvolution du logiciel et la
production de composants potentiellement rutilisables qui peuvent tre utiles dans de
futurs projets logiciels. La rutilisation dans ce cycle de vie est plus efficace que dans les
modles traditionnels parce quil intgre dans son noyau lintrt pour la rutilisation et les
mcanismes pour la raliser [20].

19

CHAPITRE I

Dveloppement logiciel base de composants

Fig. 5 Modle en Y pour le dveloppement logiciel bas composant [20]


c. Lapproche EPIC (Evolutionary Process for Integrating COTS)
Cest une forme modifie du processus rationnel unifi (RUP7). Pour sadapter aux
changements continus induits par le march des COTS (Commercial Off The Shelf), EPIC
utilise le modle en spirale bas sur la gestion des risques. Les utilisateurs de lapproche
EPIC grent la collecte dinformations du march et raffinent ces informations par
lanalyse et la ngociation dans une solution cohrente qui est incorpore dans une srie de
reprsentations excutables durant la vie du projet [21]. Les quatre phases sont, comme
dans RUP, Analyse des besoins, laboration, construction, et transition.
1) Le but de la phase danalyse des besoins est datteindre la concurrence entre les
utilisateurs affects sur les objectifs de cycle de vie pour le projet. La phase
danalyse des besoins tablit la faisabilit travers le cas daffaires qui montre
quune ou plusieurs solutions candidates existent.
2) Le but de la phase dlaboration est datteindre une stabilit suffisante au niveau
de larchitecture et des besoins; pour slectionner et acqurir des composants; et
pour minimiser les risques de sorte quune solution simple de haute fiabilit puisse
tre identifie avec le cot prvu.
3) Le but de la phase de construction est de dgager un produit de qualit prt pour la
communaut dutilisateur concern. La solution choisie est prpare pour sa mise
sur terrain.
4) Le but de la phase de transition est la livraison de la solution ses utilisateurs.
La solution choisie est mise sur terrain la communaut dutilisateur.
7

Rational Unified Process

20

CHAPITRE I

Dveloppement logiciel base de composants

Beaucoup de gens dans lindustrie logiciel commencent voir le CBD comme


nouvelle approche passionnante au dveloppement dapplication qui offre la promesse de
rduire la dure du cycle de dveloppement de logiciel, et amliore la qualit des
applications fournies [9]. Le CBD a beaucoup davantages. Ceux-ci incluent une gestion
plus efficace de la complexit, rduire le temps de mise sur le march, une meilleure
productivit, une qualit amliore, et un large spectre dutilisation. Cependant, il y a
plusieurs inconvnients et risques dans lutilisation du CBD qui peut compromettre son
succs [14] :

Le temps et leffort ncessaire pour le dveloppement des composants. Parmi les


facteurs qui peuvent dcourager le dveloppement des composants rutilisables est
le temps et leffort croissant exig, la construction dune unit rutilisable a
ncessite de trois cinq fois leffort exig pour dvelopper une unit pour un usage
spcifique.
Les besoins peu clairs et ambigus. En gnral, la gestion des besoins est une partie
importante du processus de dveloppement, son objectif principal est de dfinir les
besoins complets et consistent des composants. Par dfinition, les composants
rutilisables doivent tre utiliss dans diffrentes applications, dont certains
peuvent encore ne pas tre connues et dont leurs besoins ne peuvent pas tre
prvus. Ceci sapplique aux besoins fonctionnels et non fonctionnels.
Conflit entre la rutilisation et la rutilisabilit. Pour tre largement rutilisable, un
composant doit tre suffisamment gnral, extensible et adaptable et donc plus
complexe utiliser, et demande plus de ressources informatiques, donc il est plus
chre utiliser. Le besoin de la rutilisabilit, qui consiste dgager, pour le
composant, un potentiel tre aisment rutilisable [3], peut mener une autre
approche de dveloppement, par exemple tablir un nouveau niveau, plus abstrait
qui donne moins de flexibilit, mais atteint une meilleure simplicit.
Les cots de maintenance des composants. Tandis que les cots de maintenance
dapplication peuvent diminuer, celles des composants peuvent tre trs leves
puisque le composant doit rpondre diffrents besoins de diffrentes applications
fonctionnant dans des environnements divers, avec des exigences en termes de
fiabilit diffrentes.
Fiabilit et sensibilit aux changements. Comme les composants et les applications
ont des cycles de vie spars et diffrents types de besoins, il y a un certain risque
quun composant ne rpondra pas compltement aux exigences dune application
ou quil peut inclure des caractristiques caches non connues pour les
dveloppeurs dapplications. On introduisons des changements au niveau
dapplication tel que la mise jour du systme dexploitation, la mise jour
dautres composants, etc., il y a un risque que le changement effectu causera
lchec du systme.

Cependant, lapparition de nouvelles technologies a augment de faon remarquable


les possibilits de construire des systmes et des applications partir de composants
rutilisables. Les clients et les fournisseurs sattendaient beaucoup du CBD, mais leurs
21

CHAPITRE I

Dveloppement logiciel base de composants

espoirs nont pas t toujours satisfaits. Lexprience a montr que le dveloppement bas
composant exige une approche systmatique pour se focaliser sur les aspects de
composants dans un dveloppement logiciel [14].
Les disciplines traditionnelles de lingnierie logicielle doivent tre ajustes sur la
nouvelle approche, et de nouvelles procdures doivent tre dveloppes. Lingnierie
logicielle base composant CBSE est devenue une nouvelle sous discipline de lingnierie
logicielle.
3.4 Ingnierie logicielle base composant (CBSE)
Il est vident que le CBD et le CBSE sont dans les premires phases de leur
expansion. CBD est connue comme tant une nouvelle approche puissante qui na amlior
de manire significative si ce nest pas rvolutionner le dveloppement et lutilisation des
logiciels en gnral.
Les concepts de CBD et de CBSE sont parfois utiliss comme des synonymes.
Pourtant leurs signification nest pas la mme. Le CBD traduit lide de cration dune
application par utilisation/rutilisation de composants. La CBSE dsigne les mthodes,
techniques et outils permettant la conception et la mise en uvre dapplications bases
composants. Elle a ainsi permis au CBD de passer dune approche artisanale une
approche industrielle [3].
Les principales missions de la CBSE sont les suivantes [1] :

fournir un support pour le dveloppement des composants ;


supporter le dveloppement des composants en tant quentits rutilisables, cest-dire anticiper la rutilisation et concevoir la rutilisabilit ;
faciliter la maintenance et lvolution des systmes en permettant la modification
et le remplacement de leurs composants.

Les dfinitions des concepts inhrents la CBSE sont encore mal formalises et
portent parfois confusion. Le flou qui entoure certaines dfinitions vient de la manire
dont la CBSE a t cre et a volu, aux confins de plusieurs domaines. Nous citons les
deux principaux : lapproche oriente objet et les travaux portant sur les architectures
logicielles. Lexprience tire de lapproche objet a t fondatrice pour la prise en
considration de laspect rutilisation dans la CBSE.
3.4.1 Concepts de base
La CBSE est base sur le concept de composant. Dautres termes, tels que linterface,
le contrat, le Framework, et le patron, sont de ce fait troitement lies au dveloppement
logiciel bas composant.

22

CHAPITRE I

Dveloppement logiciel base de composants

Un composant est une unit rutilisable de dploiement et de composition. Une vue


commune est quun composant est troitement li un objet et que le CBD est donc une
extension du dveloppement orient objet. Cependant, beaucoup de facteurs, tels que la
granularit, les concepts de composition et de dploiement, et mme les processus de
dveloppement, distinguent clairement les composants des objets [1]. Nous allons essayer
de prsenter une vue densemble sur ces termes, et leurs dfinitions.
3.4.1.1

Interface

Un composant doit tre clairement diffrenci des autres composants et de leur


contexte dexcution. Le mcanisme permettant cela est linterface. Les interfaces sont un
mcanisme de contrle des dpendances existantes entre les diffrents modules dun
programme ou dun systme [3]. Une interface dun composant peut tre dfinie comme
une spcification de ses points daccs [23]. Cest--dire quelle offre la liste des services
fournis ou requis par le composant. Les clients accdent aux services fournis par le
composant en utilisant ces points. Il est important de noter quune interface noffre aucune
implmentation daucune de ses oprations. Au lieu de cela, elle se prsente sous la forme
dune collection de noms doprations. Elle fournit une description pour chaque opration.
Cette sparation entre limplmentation du composant et son interface permet de:
remplacer la partie implmentation sans changer linterface, et de cette faon amliorer les
performances du systme sans reconstruire le systme; et, dajouter de nouvelles interfaces
(et des implmentations) sans changer limplmentation existante, et de cette faon
amliorer ladaptabilit du composant.
Les interfaces dfinies dans les technologies de composants standard (par exemple, le
langage de dfinition dinterface IDL8 de CORBA ou COM) peuvent seulement exprimer
les proprits fonctionnelles, et cela on se focalisant seulement, partiellement sur la partie
syntaxique [23]. En gnral, les proprits fonctionnelles incluent une partie de signature
dans laquelle les oprations fournies par un composant sont dcrites, et une partie de
comportement, dans laquelle le comportement du composant est spcifi. Nous pouvons
distinguer deux types dinterfaces. Les composants peuvent exporter et importer des
interfaces depuis et vers lenvironnement qui peut inclure dautres composants.
Une interface exporte dcrit les services fournis par un composant lenvironnement,
alors quune interface importe spcifie les services requis par un composant de
lenvironnement [1]. La mise en uvre de la notion dinterface est maintenant aise car de
nombreux langages de programmation rcents la supportent, comme par exemple Java.
Dans le cas contraire, des langages de spcification dinterfaces ont t galement
dvelopps, indpendamment de tout type de langage, comme le langage IDL dfinit par le
DCE (Distributed Computing Environment). Un exemple de spcification dinterface en
IDL est donn dans la figure 6. Elle reprsente une interface de service fournie
(ProvIneterPAM) dun composant simple (un pilote automatique de bateau). Cette
interface dcrit deux oprations : setCap et setTarget.
8

Interface Definition language

23

CHAPITRE I
1
2
3
4

Dveloppement logiciel base de composants

interface ProvIneterPAM {
void setCap (out int iCap) ;
void setTarget (in float iLattitude , in float iLongitude) ;
};
Fig. 6 Exemple de dfinition dinterface en IDL [3]

3.4.1.2

Contrat

La plupart des techniques pour dcrire les interfaces telles que IDL sont seulement
concernes par la partie de signature, dans laquelle les oprations fournies par un
composant sont dcrites. Ils ne dcrivent pas le comportement global du composant mais
juste la liste de ces services [1]. La notion de contrat permet notamment de pallier cette
lacune. Il est admis que les contrats permettent de spcifier de manire plus rigoureuse le
comportement des composants.
Un contrat liste les contraintes globales que le composant doit maintenir (invariants)
[30]. Pour chaque opration dun composant, un contrat liste galement les contraintes qui
doivent tre assures par le client (pr-conditions) et celles que le composant promet
dtablir en retour (post-conditions). Les pr-, post-conditions et invariants constituent une
spcification du comportement dun composant [23]. Au del des spcifications du
comportement dun composant simple, les contrats peuvent galement tre utiliss pour
spcifier les interactions dans une collection de composants. Un contrat spcifie les
interactions entre composants, en termes de [1]:

Lensemble de composants participant;


Le rle de chaque composant travers ses engagements contractuels, tels que les
engagements de type, qui exigent du composant de supporter certaines variables et
une interface, et les engagements causals, qui exigent du composant de raliser une
squence ordonne dactions, y compris lenvoi de messages aux autres
composants.
Linvariant maintenir par les composants;
La spcification des mthodes qui font linstanciation du contrat.

Lutilisation des contrats pour spcifier les interactions entre les composants ncessite
lutilisation de langage. Eiffel est un exemple de langage qui permet la description des
interfaces par contrats. Les contrats permettent aux dveloppeurs de logiciel disoler et de
spcifier explicitement, un haut niveau dabstraction, les rles de diffrents composants
dans un contexte particulier. En second lieu, les diffrents contrats permettent la
modification et lextension des rles de chaque participant indpendamment. Finalement
les nouveaux contrats peuvent tre dfinis en associant diffrents participants avec
diffrents rles.

24

CHAPITRE I
3.4.1.3

Dveloppement logiciel base de composants

Composition

La composition de composants permet de crer soit une application base composants,


soit de construire un composant de granularit plus importante. Il existe de nombreuses
dfinitions de la notion de composition. Parmi celles-ci, la dfinition suivante : la
composition logiciel est la construction dapplications logicielles partir de composants
qui implmentent des abstractions concernant un problme de domaine particulier9 [3]. La
composition logicielle y est dcrite comme un mcanisme, sans prciser lequel, permettant
la construction dune application partir de composants. Selon [3], il existe deux niveaux
de composition :
La composition haut niveau, ou composition conceptuelle, concerne la phase danalyse
et la conception globale du systme. On traite lactivit didentification et de description
des abstractions fondamentales du systme logiciel (composants) et les relations entre elles
(compositions). Il sagit de considrer la composition au niveau modle et donc de prparer
et guider lassemblage au niveau programmation. Les langages de modlisation et de
spcification permettent la ralisation de cette phase.
La composition bas niveau, ou composition logicielle, concerne :
La description de larchitecture globale du systme et la spcification de la conception
dtaille. Cette phase peut tre ralise conjointement avec des ADL (Architecture
Description Language) et des langages de modlisation et de spcification.
Limplmentation et le dploiement des compositions. Cette phase peut tre ralise
laide des modles de composants, des langages de script ou de glu, ou encore de
simples langages de programmation.
3.4.1.4

Patron

Un architecte nomm Christopher Alexander a introduit pour la premire fois le


nouveau concept de patron dans la fin des annes 70. Dans ce contexte, un patron dfinit
une solution rcurrente pour un problme rcurrent. Les patrons de conception forment
une mthode de rutilisation des informations de conception. Ils ont t introduits dans le
monde OO (Orient Objet). Gamma et al [24] ont raffin aprs cette dfinition en
spcifiant les caractristiques dun patron et ses objectifs.
On peut tablir quatre catgories de patrons. Chaque catgorie est base sur le niveau
dabstraction partir duquel ils sont utiliss [23] :
1) Les patrons darchitecture travaillent sur les proprits globales et architecturales
du systme. Ils dcrivent la structure globale du systme, et fournissent des moyens
de dcrire lensemble des sous-systmes, de spcifier leur rle et de dcrire les
relations existant entre eux ;
9

En anglais Software composition is the construction of software applications from components that
implement abstractions pertaining to a particular problem domain

25

CHAPITRE I

Dveloppement logiciel base de composants

2) Les patrons de conception raffinent la structure et les comportements des soussystmes et des composants. Par leur aspect gnrique, les patrons sont considrs
comme des microarchitectures visant rduire la complexit, promouvoir la
rutilisation et fournir un vocabulaire commun aux concepteurs. Ils dcrivent la
structure et le comportement du systme et des composants et les communications
entre eux ;
3) Les patrons de programmation sont dpendants des paradigmes et des langages de
programmation utiliss.
La figure 7 montre un exemple dun type de parton de conception de Gamma nomm
le pattern Observer.
Subject

Observer

Observers

Attach (Observer)
Detach(Observer)
Notify( )

Update()

for all o in observers


{ Obsupdate();
}

ConcreteObserver
Subject

ConcreteSubject
SubjectState
GetState ( )
SetState ( )

Return SubjectState

ObserverState
observerState=
subjectGetState()

Fig. 7 La structure du Pattern Observer [24]


Les patrons ont t appliqus dans la conception de beaucoup de systmes orients
objet, et sont considrs comme des microarchitectures rutilisables qui contribuent dans
larchitecture globale dun systme. Cependant, lutilisation des patrons de conception
nest pas sans problmes. Le premier problme est que la connaissance code dans le
patron de conception est une connaissance non structure porteuse de nombreuses
ambiguts en raison de la description informelle des solutions. La relation existante entre
patrons de conception et composants peut tre vue comme suit : les patrons de conception,
dans le processus de conception des applications bases composants, aident dterminer
les units rutilisables et, le cas chant, les identifier sous la forme de composants
existants, ou les dvelopper sous la forme dunits rutilisables. Enfin, les patrons de
conception peuvent tre utiliss pour dcrire les compositions de composants [1]. Il est
envisageable de dcrire dans des patrons, diffrents cas de composition type que lon
pourrait utiliser.
3.4.1.5

Framework

Tout comme la dfinition de composant, la notion de Framework, est un autre moyen


aidant raliser une application base composants. CBSE signifie que nous construisons
des logiciels assemblant plusieurs pices ensemble. Dans un tel environnement il est
essentiel quun contexte existe dans lequel les pices peuvent tre utilises. Les
Framework constituent un moyen pour fournir de tels contextes. Un Framework peut tre
26

CHAPITRE I

Dveloppement logiciel base de composants

vu comme une conception rutilisable dune partie dun systme, fournissant un ensemble
de classes abstraites ainsi que les moyens de les faire interagir. Il peut tre utilis pour
dcrire quelque chose qui est utilisable, non seulement tel quel dans une situation
particulire, mais galement, aprs modification, dans une situation similaire la situation
conue initialement. Cette modification peut avoir lieu durant la phase de conception ou
dexcution, et est appele instanciation du Framework [1]. La contribution majeure des
Frameworks est quils forcent les composants effectuer leurs tches laide de
mcanismes contrls par le canevas lui-mme, ce qui renforce le respect des principes
architecturaux [3]. Un exemple de canevas dapplications le JAF (pour JavaBeansTM
Activation Framework).
Les Frameworks dcrivent une situation rutilisable typique au niveau modle, tandis
que les Frameworks de composants constituent une carte circuit avec des slots vides en
attente pour tre rempli de composants. Quand ceci est fait le Framework est instanci
[23]. On distingue trois types ou niveaux de Frameworks [23] :
1) Les Frameworks techniques qui sont semblables ce qui se nomme autrefois des
Frameworks dapplication;
2) Les Frameworks industriels ;
3) Les Frameworks dapplication.
3.4.2 Relation entre concepts
Dans la communaut du CBSE, il y a souvent des confusions sur les concepts de base
quon a prsents. Par exemple, le concept des modles de composants est souvent sujet
de confusion avec le concept des Frameworks de composants. La figure 8 dfinit le modle
de composant comme un ensemble de types de composant, leurs interfaces, et, en plus, la
spcification de leurs partenaires dinteraction parmi les types de composants. Un
Framework de composant fournit une varit de services de dploiement et dexcution
pour supporter le modle de composant. La figure 8 tire de [25] schmatise la relation
entre les concepts abords plus haut.

Fig. 8 Relation entre les concepts pour une application


base composants [25]
27

CHAPITRE I

Dveloppement logiciel base de composants

Un composant (1) est une implmentation logicielle mettant en uvre un ensemble de


services dcrits par une ou plusieurs interfaces (2). Les composants respectent certaines
obligations qui sont dcrites par des contrats (3). Ceux-ci assurent que des composants
dvelopps indpendamment obissent des rgles dinteraction, et peuvent tre dploys
dans un environnement de compilation et dexcution standard (4). Une application base
composants est construite partir dinstances de composants. Chaque composant est bas
sur un type de composants (5). Un modle de composants (6) est un ensemble de types de
composants, de leurs interfaces, et ventuellement de patrons de conception dcrivant les
interactions entre les diffrents types de composants. Un canevas dapplications (7) fournit
un ensemble de critres de dploiement et dexcution (8) comme support au modle de
composants.
3.4.3 Notion de composant
Les composants reprsentent le cur de la CBSE, et on a besoin dune dfinition
prcise de ce que cest un composant afin de comprendre les bases du CBSE. Plusieurs
dfinitions du concept de composant peuvent tre trouves dans la littrature. Ces
dfinitions diffrent naturellement en fonction du domaine dapplication et en fonction de
la comprhension qui peut tre attache aux composants [27].
3.4.3.1

Dfinition dun composant

Dans le domaine de la rutilisation du logiciel par exemple, un composant est vu


comme nimporte quelle entit qui peut tre rutilise. Les concepteurs voient les
composants comme des lments de conception. Les dployeurs les considrent comme
des units de dploiement. Dans dautres considrations, un composant peut tre galement
vu comme un lment dun projet, comme une configuration ou mme comme une
documentation. A lheure actuelle, il nexiste pas de normalisation de la notion de
composant. Gnralement un composant rutilisable est dfini comme Une unit de
conception (de nimporte quel niveau dabstraction) identifie par un nom, avec une
structure dfinie et des directives de conception sous la forme de documentation pour
supporter sa rutilisation [28]. La documentation dun composant illustre le contexte
dans lequel il peut tre utilis en spcifiant les contraintes et les autres composants dont il a
besoin pour offrir sa solution.
Cette dfinition du concept de composant est gnrale car elle admet la possibilit
dutiliser le concept de composant dans des niveaux dabstraction autres que le niveau
dimplantation. Dune manire gnrale, un composant est vu comme une solution teste et
accepte pour rsoudre un problme frquemment rencontre lors du dveloppement de
systmes [15].
3.4.3.2

Type de composant

Pour intgrer la rutilisation dans tout le processus de dveloppement des systmes


base de composant, une grande varit de composants rutilisables a t propose. Il existe
28

CHAPITRE I

Dveloppement logiciel base de composants

trois types de composant quon peut trouver dans la littrature: les composants
conceptuels, les composants logiciels et les composants mtier.
a. Composant conceptuel
Un composant conceptuel est une solution un problme conceptuel sous la forme
dun modle (ou une partie dun modle) destine tre rutilise . Suivant lapproche de
modlisation utilise, la solution peut tre spcifie avec le langage UML (Unified
Modeling Language) ou tout autre langage de modlisation. Les composants conceptuels
peuvent tre de deux types :

Les composants produit : un composant produit est une partie cohrente


dun modle qui peut tre rutilise avec dautres composants produit pour
assembler un modle complet. Un produit correspond au but atteindre
lorsquon utilise la solution offerte par le composant produit. Par exemple,
le patron composite de Gamma [24] peut tre considr comme un
composant conceptuel produit.
Les composants processus : un composant processus est une partie
cohrente dun processus qui peut tre rutilise avec dautres composants
processus pour assembler un processus complet. Un processus correspond
au chemin parcourir pour atteindre la solution offerte par le composant
processus. Par exemple, le patron revue technique dAmbler est un
composant conceptuel processus [29].

b. Composant mtier
A lheure actuelle, il nexiste pas de normalisation de la notion de composant mtier.
Le concept de composant mtier rsulte de celui dobjet mtier. Ainsi, lOMG (Object
Management Group) dfinit la notion dobjet mtier comme suit: Business Objects are
representations of the nature and behaviour of real world things or concepts in terms that
are meaningful to the enterprise. Customers, products, orders, employees, trades, financial
instruments, shipping containers and vehicles are all examples of real-world concepts or
things that could be represented by Business Objects [33].
Dautres spcialistes dfinissent un composant mtier comme une unit de rutilisation
de connaissances de domaines, dun point de vue conceptuel uniquement, par exemple,
Casanave dans la dfinition suivante [26]:
Un composant mtier est vu comme une reprsentation de la nature et du
comportement dentits du monde rel dans des termes issus du vocabulaire dune
entreprise [34].

29

CHAPITRE I

Dveloppement logiciel base de composants

c. Composant logiciel
Les composants logiciels sont dfinis de diverses manires et ils nont pas de
dfinition universellement accepte. Parmi celles proposes, nous avons choisis de
prsenter quelques dfinitions les plus connues donnes par les experts. Lune des
premires dfinitions est donne par Gready Booch :
Un composant logiciel rutilisable est un module logiquement cohsif et faiblement
coupl qui dnote une simple abstraction 10.
Cette dfinition reflte lide quun composant rutilisable est un module logiciel
encapsul comprenant des lments troitement lis [11]. Plus tard, Clment Szyperski a
prsent sa clbre dfinition dun composant logiciel dans la Confrence europenne sur
la programmation oriente objet en 1996.
Un composant logiciel est une unit de composition avec des interfaces
contractuellement spcifies et des dpendances explicites au contexte. Un composant
logiciel peut tre dploy indpendamment et est sujet une tierce composition .
Cette dfinition est la plus couramment admise parmi celle proposes. Elle montre
trois proprits dun composant :
1) Un composant encapsule totalement son implmentation et communique avec son
environnement au travers de ses interfaces. Les interfaces spcifient les
fonctionnalits fournies par le composant, et pour assurer ces fonctionnalits,
certaines dpendances vers dautres composants ou mme vers lenvironnement
doivent tre rsolues
2) Un composant est une unit de composition et est sujet composition. il doit donc
tre conu pour la composition, cest--dire pour tre combin avec dautres
composants afin de construire des entits logicielles de taille plus importante.
3) Un composant peut tre dploy dune manire indpendante. Il nest pas
ncessaire de lintgrer dans une application pour pouvoir le dployer.
En 2000, une notion plus gnrale dun composant logiciel a t dfinit par Alan W.
Brown [9]: une partie fonctionnelle indpendamment dlivre qui permet laccs ses
services travers des interfaces.11
Rcemment, Bill Councill et George T. Heineman ont donn une nouvelle dfinition
qui souligne limportance, dun modle de composants et de son standard de composition
dans la construction de composant et de logiciel base de composant [11].
10 En anglais A reusable software component is a logically cohesive, loosely coupled module that denotes
a single abstraction .
11 En anglais An independently deliverable piece of functionality providing access to its services through
interfaces.

30

CHAPITRE I

Dveloppement logiciel base de composants

Un composant logiciel est un lment logiciel conforme un modle de composants


et peut tre indpendamment dploy et compos sans modification selon un standard de
composition.
3.4.3.3

Modle de composants

Un modle de composants consiste en un ensemble de conventions respecter dans la


construction et lutilisation des composants [26]. Lobjectif de ces conventions est de
permettre de dfinir et de grer dune manire uniforme les composants. Elles couvrent
toutes les phases du cycle de vie dun logiciel base de composants : la conception,
limplantation, lassemblage, le dploiement et lexcution. Concrtement, un modle de
composants dcrit certains aspects des composants comme la dfinition de composants
partir dobjets (classes, modules, etc.), les relations entre les composants, les proprits
fonctionnelles et non fonctionnelles de chaque composant, les techniques dassemblage des
composants, le dploiement et lexcution dun logiciel base de composants, etc.
Dans la pratique, un modle de composants donn est spcifique une phase du cycle
de vie du composant et du logiciel. On trouve ainsi des modles de composants pour la
phase de conception (patrons de conception), et dautres pour les phases dimplantation et
de dploiement (EJB, CCM, etc.) [26]. Dans la section suivante des exemples sur des
standards de composants logiciels sera prsent.
3.4.3.4

Technologies Standards pour le CBD

Nous prsentons dans cette section quelques exemples de modles de composants :


a. Component Object Model
COM (Component Object Model) [31] est un modle de composants dvelopp par
Microsoft en 1995. Son objectif est de permettre le dveloppement dapplications en
assemblant des composants pouvant tre crits en diffrents langages, et communiquant en
COM. Ces composants, pour quils puissent interagir, doivent adhrer une structure
binaire commune, spcifie par Microsoft. Ceci signifie que les compilateurs des diffrents
langages de programmation, gnrent les composants suivant le mme format binaire. Un
composant COM, crit dans un langage donn, peut ainsi interagir avec un autre
composant, mme sil est crit dans un langage diffrent [27].
b. Java Beans
Le modle des Java Beans a t propos par Sun Microsystems en 1996. Son premier
et principal domaine dapplication est la construction dinterfaces graphiques, mais son
utilisation peut tre tendue dautres domaines.
Suivant la dfinition de Sun Microsystems, un Java Bean est un composant logiciel
rutilisable qui peut tre manipul visuellement travers un outil logiciel [7]. Un Java
31

CHAPITRE I

Dveloppement logiciel base de composants

Bean possde une interface qui dcrit ses mthodes et ses attributs. La composition des
instances repose sur la notification et lcoute dvnements. Le modle des Java Beans a
contribu lvolution de la notion de composant sur tagre. Le modle de
communication par vnements a rvolutionn la faon dassembler des composants
logiciels.
Cette forme de composition permet des Java Beans ntant pas initialement conus
pour fonctionner ensemble, dtre composs a posteriori : il suffit que lun soit producteur
et lautre consommateur dun mme type dvnement. Pour faciliter un assemblage a
posteriori, il faut videmment possder des types dvnements standards partir desquels
les Java Beans sont dfinis [7].
c. Enterprise Java Bean
Le modle des composants EJB (Enterprise Java Bean) est le fruit dun travail de
normalisation, publi dans sa version initiale en juin 1998 (spcification 1.0). Il est ddi
au dveloppement, la gestion et lvolution de composants serveurs au sein
dapplications distribues 3-tiers (clients/serveurs/bases de donnes) [7].
Plus particulirement, un EJB est un composant logiciel crit en Java, et sexcutant
du ct serveur. La norme EJB est essentiellement oriente vers le dveloppement
dapplications offrant des services complmentaires au dessus dun systme dinformation
dentreprise [27]. La couche client comporte les applications (applets, applications Java,
pages HTML) qui permettent aux utilisateurs dinteragir avec les donnes de
lentreprise. La couche donne concerne les bases de donnes de lentreprise. Enfin, la
couche serveur joue le rle dintermdiaire entre les deux autres couches. Elle englobe un
serveur Web incluant les JSP (JAVA server page), les servlets JAVA, et un serveur de
composants mtiers li des conteneurs EJB [27].
d. CORBA Component Model
Le modle composants de CORBA (CCM) ajoute une couche au dessus de
lintergiciel CORBA permettant de dfinir larchitecture dune application distribue sous
forme de composition dinstances de composant [32]. La description dune composition,
appele Assembly, est ralise de faon dclarative et permet de guider le dploiement,
sur plusieurs emplacements, des classes de composant ainsi que la cration, configuration,
connexion et activation des instances de ces derniers. Une autre caractristique de ce
modle est quil supporte limplmentation de composants dans diffrents langages ; ceci
est facilit par lutilisation dun langage abstrait pour la description dinterfaces (IDL).
Le modle CCM repose sur deux points essentiels : le premier est quun composant
CCM est une boite noire dont on ne sait rien de limplantation; le second que la structure
du composant doit tre entirement dcrite en IDL [7]. La structure est dfinit en terme
dinterfaces fournies (i.e. que le composant implmente) et dinterfaces requises (i.e. dont
le composant requiert lutilisation). A chaque interface, fournie ou requise, correspond un
32

CHAPITRE I

Dveloppement logiciel base de composants

port qui dfinit le mode de communication associ cette interface. Il y a cinq diffrents
types de ports [10]:
Facettes, qui sont les interfaces fournies par les composants pour linteraction du
client;
Rceptacles, qui sont les points de connexion qui dcrivent les interfaces utilises
par le composant;
Sources dvnement, qui sont les points de connexion qui mettent des
vnements dun type spcifique aux consommateurs dvnement intresss;
Puits dvnement, qui sont les points de connexion dans lesquels des vnements
dun type spcifique sont annoncs;
Les attributs, qui sont des valeurs principalement utilises pour la configuration du
composant.

4. Conclusion
Nous avons prsent dans ce chapitre une vue densemble sur le gnie logiciel base
de composant. Pour ce faire, on a commenc tout dabord, par une brve description des
diffrentes approches classiques qui on prcdes les approches de lingnierie logicielle
base de composants et qui ont t proposes en ingnierie logicielle. Ces approches ont
montr des insuffisances et des lacunes en tant concentr sur un systme la fois sans
considrer les besoins volutionnistes du systme. Le dveloppement bas composant
(CBD) a t une solution cl pour pallier aux problmes des approches classiques. Cette
approche favorise la rutilisation de briques logicielles prfabriques pour construire des
systmes logiciels entirement nouveaux et cela par assemblage. Cela a induit bien
videment rduire le temps et le cot de dveloppement et des logiciels de qualit
meilleure. Dans le processus de dveloppement des applications base de composant, la
slection des composants logiciels reprsentant les entits rutilisables constitue une phase
trs importante. Les composants slectionns doivent tre valu. Le processus
dvaluation inclut des aspects techniques qui sont [1] : lintgration, la validation et la
vrification des composants. Dans de nombreux cas, il est peut tre plus adquat dvaluer
un ensemble de composants composs comme un assemblage que dvaluer un composant
[1]. Lintgration des composants slectionns en un assemblage rsulte en une unit
fonctionnelle. Dans de tels cas, il est ncessaire dvaluer cette composition. Pour cette fin
une spcification dune telle composition ainsi que celles des entits lmentaire savre
indispensable. Cest dont nous nous sommes propos faire dans ce mmoire en utilisant
le formalisme des ECATNets (Extended Concurrent Algebraic Term Nets), qui sont un
type de rseau de ptri algbrique de haut niveau intgrs dans la logique de rcriture.
Ceux-ci seront le sujet du prochain chapitre.

33

CHAPITRE II

ECATNets et logique de rcriture

CHAPITRE II :

ECATNets et logique de rcriture

1. Introduction
On entend par mthodes formelles, les langages, techniques, et les outils bass sur la
logique mathmatique. En effet la base des mthodes formelles est de nous permettre de
construire des modles mathmatiques bien dfinis du systme analyser. Une fois le
modle en main, des techniques mathmatiques de haut niveau peuvent tre utilises pour
raisonner sur le modle. En outre puisque la smantique du modle est bien dfinit grce
aux fondements mathmatiques, on peut utiliser des outils qui peuvent analyss le modle
de diverses manires [47].
En tant que formalisme de spcification, les rseaux de Petri prsentent un certain
nombre de qualits trs importantes. Une dfinition formelle permettant de construire des
modles exempts dambigut, un grand pouvoir dexpression facilitant la description des
systmes complexes, et leurs capacits dtre excutable et interprter par un programme
offrant la possibilit de simuler le fonctionnement du systme en cours de spcification.
Les ECATNets sont des types de rseaux de Petri algbrique de haut niveau. Ils ont t
proposs comme une manire pour la spcification, la modlisation, et la validation des
applications du domaine des rseaux de communication, la conception des ordinateurs, et
dautres systmes complexes [51]. Ce qui les distinguent des autres types de rseaux est
leur smantique interprter en termes de la logique de rcriture. La logique de rcriture
introduite par Meseguer est une logique pour raisonner correctement sur les systmes
concurrents ayant des tats, et qui voluent au moyen de transitions. Elle constitue un
Framework ou tout modle peut tre naturellement reprsent au sein de cette logique. A
travers ce chapitre nous nous sommes pench sur la prsentation de ce couplage entre les
ECATNets et la logique de rcriture et cela de la manire suivante. Dabord un bref
survol sur les RdPs, puis la prsentation des RdPs de haut niveau et algbriques. Nous
montrons ensuite les ingrdients qui nous permettrons de se mettre dans le bain de la
logique de rcriture, cela se fera par le biais de quelques dfinitions de base. Ensuite, en
parlons de cette logique et dans la logique des choses nous prsenterons le langage Maude,
34

CHAPITRE II

ECATNets et logique de rcriture

le langage de la logique de rcriture. Enfin, la dernire section de ce chapitre sera


consacre aux ECATNets dont nous allons dtailler leurs formalismes en se basant sur des
exemples illustratifs.

2. Rseaux de Petri
Les rseaux de Petri sont des outils de modlisation graphique et mathmatique qui
peuvent tre appliqus plusieurs systmes. Ils sont considr comme des outils
prometteur pour dcrire et tudier les systmes qui se caractrisent comme tant
concurrent, asynchrone, distribu, parallle, non dterministe, et / ou stochastiques.
2.1 Dfinitions de base
Un rseau de Petri (RdP) est un graphe biparti constitu de places, de transitions et
darcs orients qui relient les transitions aux places et les places aux transitions. Il est
reprsent formellement par un quintuple PN = (P, T, F, W, M0) o [35]:
P = {p1, p2, , pm} est un ensemble finie de places,
T = {t1, t2, , tn} est un ensemble finie de transitions,
F (P x T) ( T x P) est un ensemble darcs,
W : F{1, 2, 3, .} est la fonction dfinissant le poids port par les arcs,
M0 : P {0,1, 2, 3, .} est le marquage initial,
P T = et P T
Une structure N = (P, T, F, W) dun RdP sans aucun marquage initial est dsigne par N.
Un rseau de Petri avec un marquage initial donn est dnot par (N, M0).
2.2 Rgle de franchissement
Le comportement de plusieurs systmes peut tre dcrit en termes des tats du systme
et de leurs changements. Pour simuler le comportement dynamique dun systme, un tat
de marquage dans un RdP est chang suivant les rgles de franchissement des transitions
[35] :
1) On dit quune transition t est franchissable partir dun marquage M, si et
seulement si chaque place p dentre de la transition contient au moins un nombre
de jetons qui est suprieur ou gale au poids de larc reliant cette place dentre p
avec la transition t, tel que : M (p) W (p, t) o M(p) reprsente le marquage de la
place p et W (p, t) est le poids de larc reliant la place p avec la transition t.
2) Le franchissement dune transition franchissable t enlve W (p, t) jetons partir de
chaque place dentre la transition t et ajoute W (t, p) jetons dans chaque place de
sortie de la transition t, o W (t, p) est le poids de larc reliant la transition t avec la
place p.
35

CHAPITRE II

ECATNets et logique de rcriture

2.3 Reprsentation graphique dun rseau de Petri


Lun des aspects les plus agrables des rseaux de Petri est quil dispose dune
reprsentation graphique attrayante, qui accrot la lisibilit et facilite la comprhension des
modles. Sa structure peut tre reprsente travers un graphe bipartie fait de deux types
de sommet : les places et les transitions relies alternativement par des arcs orients qui
portent des poids entier positifs, si un poids nest pas port alors il est gal 1 [39]. Le
marquage dun RdP est reprsent par la distribution de jetons dans lensemble de places
telle que chaque place peut contenir un ou plusieurs jetons. Lexemple suivant (figure 9)
montre une reprsentation graphique dun RdP modlisant une raction chimique 2H2 + O2
2H2O. Les deux jetons dans chaque place dentre de la transition t dans la figure (a)
montre que deux units de H2 et O2 sont disponible et que la transition t est franchissable.
Aprs franchissement le nouveau marquage est illustr dans la figure (b).
H2

H2

t
2

H2O

t
2

O2

H2O

O2

(b)

(a)

Fig. 9 Reprsentation graphique dun RdP modlisant une raction chimique :


(a) marquage avant de franchir la transition t, (b) marquage aprs le franchissement.
2.4 Proprits comportementales dun RdP
Un des points forts des rseaux de Petri est leur support pour lanalyse de nombreuses
proprits et les problmes associs aux systmes concurrents. Deux types de proprits
peuvent tre tudies avec un RdP: ceux qui dpendent du marquage initial et ceux qui
sont indpendants du marquage initial. Le premier type reprsente les proprits
comportementales, alors que le deuxime reprsente les proprits structurelles [36]. Nous
allons se limiter prsenter les proprits comportementales, tant donn que, travers ces
dernires on peut tudier laspect dynamique des systmes modliss.
a) Atteignabilit
Etant donn un RdP PN= (P, T, F, W, M0) est un marquage M. le problme
datteignabilit consiste vrifi sil existe une squence de transitions qui transforme M0
en M [36].
b) Bornitude
Une place Pi est borne pour un marquage initial M0 si pour tout marquage atteignable
partir de M0, le nombre de jetons dans Pi reste born. Elle est dite k-borne si le nombre

36

CHAPITRE II

ECATNets et logique de rcriture

de jetons dans Pi est toujours infrieur ou gal k. Un RdP marqu est (k) born si toutes
ses places sont (k) bornes [37].
c) Vivacit et blocage
Lvolution du marquage dun RdP se fait par franchissement de transitions.
Lorsquau cours de son volution, certaines transitions ne sont jamais franchies, cela
indique que lvnement associ la transition ne se produit pas et que le marquage dune
partie du RdP nvolue pas. Cela indique que le sous systme modlis par cette partie-l
ne fonctionnera pas [37].
Une transition Tj est vivante pour un marquage initial M0 si pour tout marquage
atteignable Mk, il existe une squence de franchissements partir de M0 contenant Tj.
Un RdP marqu est vivant pour un marquage initial M0 si toutes ses transitions sont
vivantes pour ce marquage initial.
Un marquage atteignable M dun RdP est blocage si aucune transition nest
franchissable partir de M.
Un RdP marqu est dit sans blocage pour un marquage initial M0 si aucun marquage
atteignable nest un blocage.

3. Rseaux de Petri de haut niveau


Les rseaux de Petri ont t utiliss pour dcrire une large gamme de systmes depuis
leur invention en 1962. Leur problme est lexplosion du nombre dlments de leurs
formes graphiques quand ils sont utiliss pour dcrire des systmes complexes.
Les rseaux de Petri de haut niveau (HLPN12) ont t dvelopps pour surmonter ce
problme en introduisant des concepts de haut niveau, tels que lutilisation de structures de
donnes complexe comme des jetons, et en utilisant des expressions algbriques pour
annoter les lments du rseau [38]. Les HLPN peuvent tre considr comme
lintgration de la description de processus et de type de donnes [40]. Lavantage
principal de cette intgration est quelle permet une prsentation plus compacte des
systmes complexes [41]. Une des premires formes des HLPN sont les rseaux de Petri
colors introduit pour la premire fois en 1979 et dvelopp au cours des annes 1980 et
les rseaux de Petri algbrique de haut niveau (AHL nets13) [40].
3.1 Dfinition dun HLPN
Une structure algbrique comprenant [38]:

12
13

un ensemble de places, un ensemble de transitions,


un ensemble de types,
une fonction associant un type chaque place,
et un ensemble de modes (type) chaque transition,

High-Level Petri Nets


Algebraic High-Level nets

37

CHAPITRE II

ECATNets et logique de rcriture

Pre est une fonction qui impose les exigences de jeton (multi-ensembles14 de
jetons) sur les places pour chaque mode de transition;
Post une fonction qui dtermine les jetons de sortie (multisets de jetons) pour
les places pour chaque mode de transition ;
et un marquage initial.
Un HLPN est une structure HLPN = (P; T; D; Type; Pre; Post; M0) o [38]:

P est un ensemble fini dlments appels Places.


T est un ensemble fini dlments appels Transitions P T = .
D est un ensemble non vide de domaines non vide o chaque lment de D est
appel un type

Type: P TD est une fonction utilise pour attribuer les types aux places et de
dterminer les modes de transition.

Pre; Post : TRANS PLACE sont les mappages Pre et Post avec
TRANS = {(t, m) | t T, m Type (t)}
PLACE = {(p, g) | p P, g Type (p)}

M0 PLACE est un multiset appel le marquage initial du rseau.

3.2 Rseaux de Petri Algbriques de haut niveau


Le concept des rseaux de Petri algbrique de haut niveau (AHL nets) constitue une
variante spcifique des rseaux de Petri de haut niveau, qui combinent les rseaux de Petri
et les spcifications algbriques. Les rseaux de Petri sont connus comme des modles
fondamentaux de concurrence, les spcifications algbriques sont bien tablies pour la
spcification formelle de types abstraits de donnes et des systmes logiciels. Les HLPN
sont trs utiles pour la spcification des systmes concurrents et distribus [42].
Formellement un rseau de Petri algbrique est dfinit comme suit [52] :
Un tuple AN = [; P, T, F; , , , m0] est un rseau de Petri algbrique Ssi :
1) = [S, ] est une spcification algbrique, o S est un ensemble de sortes et un
ensemble de symbole de fonctions. est appele signature;
2) [P, T, F] est un rseau i.e : P et T sont des ensembles finis est disjoints appels
respectivement places et transitions, et F est une relation F ( P T ) U (T P ) o
ses lments sont appels arcs ;
3) est une affectation de sorte : P S ;
4) affecte un ensemble de -variables (t) pour chaque transition t T ;
5) est linscription darcs tel que pour f = [p, t] F, (f) est un multi-terme ;
6) m0 est le marquage initial.

14

Nous utiliserons dans le reste de ce mmoire le terme anglais Multisets

38

CHAPITRE II

ECATNets et logique de rcriture

4. Logique de rcriture et Maude


Nous allons prsenter dans cette section la logique de rcriture dune manire non
dtaille, mais avant cela il est ncessaire de comprendre ce que veut dire la rcriture ainsi
que les lments de base qui dfinissent cette logique. Ensuite nous allons prsenter le
langage Maude comme tant un langage de spcification formel bas sur la logique de
rcriture.
4.1 Dfinitions de base
Dfinition 1. Une signature F est un ensemble doprateurs (symboles de fonction),
chacun tant associ un entier naturel par la fonction arit : FN, associant chaque
oprateur son arit. Fn dsigne le sous ensemble doprateurs darit n [43].
On peut alors dfinir les termes construits sur ces oprateurs et un ensemble de
Variables X.
Dfinition 2. Les termes sur F sont dfinis par clture comme le plus petit ensemble T
(F, X) tel que :
X T (F, X) : toute variable de X est un terme de T (F, X)
Pour tous t1, . . ., tn termes de T (F, X) et pour tout oprateur f darit n, f (t1, . .
., tn) est un terme de T (F, X).
On peut dfinir lensemble Var (t ) des variables dun terme t de manire inductive
[43]:
Var (t ) = si t F0,
Var (t ) = {t} si t X
Var (t ) =

Ui=1Var (ti) si t = f (t1, . . ., tn).

Lensemble des termes clos (termes dans lesquels il ny a pas de variables) est not T
(F). On peut considrer un terme comme un arbre dont les feuilles sont des constantes (que
lon peut dfinir comme des oprateurs darit 0) ou des variables (si le terme nest pas
clos) et les nuds sont des oprateurs darit strictement positive. Par exemple, le terme
f(x, g(y1, . . . , yn)) peut tre reprsent par larbre :
f
g

x
Y1

...

Yn

39

CHAPITRE II

ECATNets et logique de rcriture

La position dun nud dans cet arbre est dfinie :


Dfinition 3. Une position (ou occurrence) dans un terme t est reprsente par une
suite dentiers naturels positifs dcrivant le chemin de la racine du terme jusqu la
racine du sous terme cette position, not t|. Un terme u a une occurrence dans t si u = t|
pour une position dans t. On note t [t] pour indiquer le fait que le terme t a le terme t
la position . Par exemple soit t=f (a, g (f(y, a))), t|2=g (f(y, a)).
Nous allons prsenter la dfinition dune opration sur les termes nomme la
substitution. Une substitution est une opration de remplacement spciale, uniquement
dfinie par une fonction des variables vers les termes. Effectuer une substitution consiste
remplacer une variable dun terme par un autre terme [44].
Dfinition 4. La substitution de la variable x par le terme u dans le terme t, note
<xu>t est la composition de chacun des remplacements du terme u chacune des
positions p telle que t(p) = x.
Dfinition 5. Une substitution est une fonction accomplissant en simultanes
plusieurs substitutions de diffrentes variables par des termes. Lapplication dune
substitution un terme t sera note < xu1,, xnun>t [44].
Une paire de terme (l, r) est appele galit ou quation est note (l=r). Par exemple,
lopration suivante dfinit sur une pile : top (puch(x, y)) = x.
tant donn un ensemble dquations E sur un ensemble de terme T, la thorie
quationnelle de E, Th(E), est lensemble dquations qui peuvent tre obtenues en
prenant la rflexivit, la symtrie, transitivit, et lapplication de contexte (ou la
rflexivit fonctionnelle) comme rgles dinfrences et toutes les instances dquations
dans E comme axiomes [45].
4.2 Systmes de rcriture
Lide centrale de la rcriture est dimposer une direction dans lutilisation
daxiomes, par la dfinition de rgles de rcriture [44]. Contrairement aux quations, qui
ne sont pas orientes, une rgle sur un ensemble de termes T est une paire ordonne <l, r>
de termes, que lon note l r [45]. Les rgles se diffrent des quations par leurs
utilisation. Comme les quations les rgles sont utilises pour remplacer les instances de l
par leurs correspondantes de r, en revanche, elles ne sont pas utilises pour remplacer les
instances de la partie droite r.
Dfinition 6. Une rgle de rcriture est une paire ordonne <l, r> de termes dans T
(F, X), note l r. l est le membre gauche de la rgle, et r son membre droite.
Un systme de rcriture sur les termes est un ensemble de rgles de rcriture. On
impose gnralement des conditions sur la construction des rgles de rcriture [44]:
les variables du membre droite de la rgle font partie des variables du membre
gauche (V ar(r) V ar(l)).
40

CHAPITRE II

ECATNets et logique de rcriture

le membre gauche dune rgle nest pas une variable (l X)


La rcriture, cest--dire le processus de remplacer les instances dun motif (pattern)
membre gauche dune rgle par linstance correspondante au motif (pattern) du membre
droite de cette rgle, est un paradigme de calcul intrinsquement concurrent [43]. Ainsi,
une mme rgle peut tre applique simultanment diffrentes positions.
Exemple
Lexemple suivant montre la rcriture dun terme en utilisant un systme de
rcriture R construit par des oprations sur une pile. Les rgles de rcriture qui
composent le systme sont les suivantes [45]:
top (puch(x, y)) x
pop (puch(x, y)) y
alternate (, z) z
alternate (puch(x, y), z) puch (x, alternate (z, y)
Une rcriture :
alternate (puch(top(puch(0, z)), z), ) R alternate (puch(0,z), )
R puch(0, alternate (, z)) R puch(0, z).
La premire tape est lapplication de la rgle top-puch loccurrence top(puch(0, z) ;
la deuxime est celle de la rgle alternate-puch avec 0 pour x et z pour y et pour z ; la
troisime est celle de la rgle alternate (, z) z.
Aprs avoir prsent les concepts de base qui permettent de comprendre la logique de
rcriture, nous allons introduire dans la section suivante ce que cest cette logique.
4.3 Logique de rcriture
La logique de rcriture est destin servir comme modle mathmatique unifi et
utilise les notions des systmes de rcriture sur les thories quationnelles. Elle permet de
sparer entre la description des aspects statiques et dynamiques dun systme distribu
[53]. Plus prcisment, elle distingue entre les lois dcrivant la structure des tats du
systme et les rgles qui prcisent ses ventuelles transitions. Cette logique, dote dune
smantique saine et complte, a t introduite par Meseguer. Elle permet de dcrire les
systmes concurrents. Plusieurs modles formels qui expriment la concurrence peuvent
tre reprsents naturellement dans cette logique.
La logique de rcriture est une logique qui permet de raisonner dune manire
correcte sur les systmes concurrents ayant des tats et voluant en termes de transitions
[54]. Elle a t propose comme une manire dinterprter les systmes de rcriture [44].
La syntaxe ncessaire pour dfinir une logique est spcifie par sa signature qui nous
permet des construire des formules.
41

CHAPITRE II

ECATNets et logique de rcriture

Une signature dans la logique de rcriture est une thorie quationnelle (, E), o
est une signature quationnelle et E un ensemble de -quation [54]. Elle exprime une
structure particulire pour les tats dun systme (par exemple : un multiset, arbre
binaireetc.) de sorte que ses tats peuvent tre distribu selon cette structure.
Etant donn une signature (, E), les formules de la logique de rcriture sont des
squents de la forme [54] : [t]E [t]E, o t et t sont des -termes qui peuvent impliqus
des variables de lensemble X= {x1,, xn,} et [t]E dnote la E classe dquivalence de t.
Lensemble des symboles de fonction est un alphabet darit = { n | n }.
Formellement la logique de rcriture est dfinit comme suit [55]:
Dfinition 7. Une thorie de rcriture est un 4-tuple = (, E, L, R), o est un
alphabet de symboles de fonction, E un ensemble de -quation, L est un ensemble
dtiquettes, et R est lensemble des paires R L (T,E(X))2 tel que le premier
composant est une tiquette et le second est une paire des classes dquivalence des termes
modulo les quations E avec X = {x1,, xn,} un ensemble comptable et infini des
variables. Les lments de R sappellent les rgles de rcriture, qui peuvent tre
conditionnelles ou inconditionnelles (si la partie condition est vide). On utilise la notation
suivante pour dcrire une rgle de rcriture, r : [t] [t]. La forme la plus gnrale dune
rgle de rcriture est comme suit : r : [t ] [t ' ] if [u1 ] [v1 ] [u k ] [v k ]
Pour indiquer que {x1,, xn} est lensemble de variables qui se produisent dans t ou t,
on crit, r : [t (x1,, xn)] [t (x1,, xn)], on notation abrger on crit, r :[t ( x )] [t ( x )].
Les rgles de rcriture dcrivent les transitions lmentaires locales qui sont possibles
dans ltat distribu dun systme, par des transformations locales concurrentes. Elle
reprsente donc laspect dynamique dun systme. La rcriture fonctionne sur les classes
dquivalence de termes modulo E.
tant donne une thorie de rcriture , on dit que le squent [t] [t] se dduit
partir de et on crit : [t] [t] Ssi [t] [t] (t deviens t) peut tre obtenue en
appliquant un nombre fini de fois les rgles de dduction suivantes [55] :
1- Rflexivit. Pour chaque t T,E (X),

[t ] [t ]
2- Congruence. Pour chaque f n , n

[t ] [t ' ]...[t n ] [t ' n ]


.
[ f (t1 ,...t n )] [ f (t '1 ,...t ' n )]
3- Remplacement. Pour chaque rgle de rcriture r : [t ( x1 ,..., x n )] [t ' ( x1 ,..., x n )]
dans R,
42

CHAPITRE II

ECATNets et logique de rcriture

[ w1 ] [ w1' ] ... [ wn ] [ wn' ]


_

[t ( w/ x)] [t '( w '/ x)]


Tel que t ( x w ) indique la substitution simultane des wi pour xi dans t.
4- Transitivit.

[t1 ] [t 2 ] [t 2 ] [t3 ]
.
[t1 ] [t3 ]
Une logique quationnelle (modulo un ensemble daxiomes E) est obtenue en ajoutant
la rgle suivante :

5- Symtrie.

[t1 ] [t 2 ]
, dans ce cas on adopte la notation [t ] [t ' ] est appeler
[t 2 ] [t1 ]

cette squence bidirectionnelle quation.


Dfinition 8. tant donne une thorie de rcriture = (, E, L, R), le squent [t]
[t] est dit -rcriture concurrente Ssi, il peut tre driv partir de par une application
finie des rgles 1-4 [55].
4.3.1 Rseau de Petri dans la logique de rcriture
La logique de rcriture est essentiellement une logique de changement dans laquelle
la dduction correspond directement aux changements [54]. Cette logique comme dj
mentionner peut naturellement exprimer et unifier divers modles de concurrence. Les
rseaux de Petri reprsentent un exemple simple mais assez riche des systmes prsentant
des changements concurrents. Gnralement, un RdP est prsent comme un ensemble de
places, un ensemble disjoint de transitions et une relation entre eux qui associe chaque
transition lensemble des ressources consommes ainsi que ceux produit par son
franchissement.
Cette reprsentation a t propose dans un Framework algbrique [54]. Dans ce
contexte les ressources sont reprsentes par des multisets de places, et donc nous avons
une opration binaire (union ensembliste dnote ) qui est associative, commutative, est
qui a le multiset vide comme lment identit. Un rseau de Petri est vu donc, comme un
graphe o les arcs sont des transitions et les nuds sont des multisets sur lensemble des
places nomms gnralement marquage. Lexemple suivant (figure 10) montre un RdP qui
modlise une machine concurrente pour vendre des tartes et des pommes.

43

CHAPITRE II

ECATNets et logique de rcriture

Fig. 10 RdP dune machine vendeuse de tartes et de pommes [54]

Une tarte cote un dollar et une pomme cote trois quarts de dollar. Lachat dune
pomme (buy-a) par exemple provoque le dpt dun jeton a dans la place a (une pomme) et
un quart de dollar dans la place q (un quart de dollars). Par dfaut de fabrication la machine
naccepte que des pices dun dollar que lutilisateur doit dposer pour acheter une
pomme. Ainsi en ayant 4 quarts de dollar dans la place q cela provoque leurs changement
(change) en un dollar dans la place $ (une pice de 1 dollars) pour surmonter le problme.
Les rseaux de Petri ont une expression naturelle et simple comme thories de
rcriture [56]. Leurs tats distribus correspondent aux marquages des places reprsents
par des multisets finis.
Pour notre exemple, lRdP peut tre vu comme un graphe ayant les arcs suivants :
buy-c : $ c
buy-a : $ a q
change : q q q q $
On peut remarquer que la reprsentation de cet RdP en logique de rcriture est
vidente. Une transition t est simplement une rgle de rcriture tiquete t : M M ' (1)
entre deux marquages ( M et M ' ) de multiset. Ainsi, un RdP N peut tre vu comme une
thorie de rcriture N avec une axiomatisation algbrique (1) pour son marquage et avec
une rgle de rcriture par transition. Le franchissement dune transition correspond alors
une rcriture modulo ACI par la rgle de rcriture correspondante [56]. La machine
modlise dans notre exemple est concurrente, car plusieurs rgles de rcriture peuvent
tre appliques en parallle suite au fait dappuyer en mme temps sur plusieurs boutons.
La logique de rcriture fournit une smantique complte pour exprimer laspect
dynamique dun RdP, et rponds parfaitement sur les questions concernant les tats que ce
dernier peut atteindre. Cela a t prcis comme suit [55] :

44

CHAPITRE II

ECATNets et logique de rcriture

Etant donn un RdP N avec un ensemble de place S et un ensemble de transition T, '


est la thorie de rcriture qui reprsente cet RdP, et tant donn M et M ' des marquages
sur S. Alors, le marquage M ' est atteignable depuis M dans lRdP N Ssi la rcriture
M M ' est une squence drivable de la thorie ' en utilisant les rgles de dduction
de la logique de rcriture.
La thorie de rcriture correspondante a lRdP de notre exemple peut tre exprimer
en langage Maude comme suit :
mod PETRI-MACHINE is
sort Marking .
ops null $ c a q : -> Marking [ctor].
ops _ _ : Marking Marking -> Marking [ctor assoc comm id: null].
rl [buy-c] : $ => c.
rl [buy-a] : $ => a q.
rl [chng] : q q q q => $.
endm
Pour comprendre lexemple ci-dessus, nous allons essayer de prsenter plus de dtail
sur ce langage et montr son intrt comme tant un langage formel bas sur la logique de
rcriture.
4.3.2 Maude
Le langage Maude est un langage de programmation formel et dclaratif bas sur la
thorie mathmatique de la logique de rcriture [47]. Il a t dvelopp ainsi que la
logique de rcriture par Jos Meseguer et son groupe dans le laboratoire dinformatique
en SRI International. Cest un langage de haut niveau et un systme de haute performance
qui supporte deux types de calcul celui de la logique quationnelle et de la logique de
rcriture pour une large gamme dapplications [57].
Le langage Maude spcifie des thories de la logique de rcriture. Les types de
donnes sont dfinies algbriquement par des quations et le comportement dynamique
dun systme est dfini par des rgles de rcriture qui dcrivent comment une partie dun
tat du systme peut changer on un seul pas.
Maude est un langage de programmation trs puissant qui modlise les systmes et les
actions lintrieur de ces systmes. Il peut presque tout modliser, de lensemble des
nombres rationnels aux systmes biologiques, ou toute chose dcrite avec le langage
humain peut tre exprime par un code Maude.

45

CHAPITRE II

ECATNets et logique de rcriture

Maude a t influenc de manire importante par le langage OBJ315, il contient ce


dernier comme sous langage de la logique quationnelle. Il se diffre de OBJ3 sur le
niveau quationnel par une meilleure performance et une logique quationnelle plus riche,
savoir, la logique quationnelle dappartenance16 [57].
Maude et un interprteur de haute performance, il excute des programmes
quationnels crit en Maude en commenant par une expression initiale et en appliquant
les quations "de gauche droite" jusqu ce que aucune quation ne peut tre applique.
Linterprteur excute des programmes de rcriture par une application "arbitraire" des
rgles de rcriture (aussi de gauche droite) sur lexpression ou ltat initial jusqu ce
quaucune rgle ne soit applicable, ou une limite suprieure sur le nombre de rcriture
donne par lutilisateur a t atteinte [47].
Une thorie de rcriture est souvent non dterministe et peut exhiber diffrents
comportements. La commande rewrite de Maude peut tre utilise pour excuter lun de
ces comportements partir dun tat initial. Pour analyser tous les comportements
possibles partir dun tat initial donn, on peut utiliser la commande search de haute
performance.
Le module est le concept cl de Maude. Il sagit essentiellement dun ensemble de
dfinitions. Il dfinit un ensemble doprations et comment elles interagissent, ou,
mathmatiquement parlant, ils dfinissent une algbre. Une algbre est un ensemble
densembles et les oprations sur eux. En Maude, un module fournira une collection de
sortes et une collection doprations sur ces sortes, ainsi que les informations ncessaires
pour rduire et de rcrire des expressions entres par lutilisateur dans lenvironnement
Maude.
Il y a trois types de module dans Maude pour la spcification des systmes [55] :
1. Modules fonctionnels, introduit par le mot cl fmod,
2. Modules systmes, introduit par le mot cl mod, et
3. Modules orients objet, introduit par le mot cl omod.
Nous allons essayer de prsenter brivement chaque module et cela dans le cadre de
son utilisation et son application dans ce mmoire, pour la vrification des proprits
comportementales des logiciels base de composants.
4.3.2.1

Modules fonctionnels

Les modules fonctionnels sont des thories quationnelles. Ces derniers dfinissent
des types de donnes et des oprations applicables sur elles. Les types de donnes
consistent en des lments qui peuvent tre nomms par termes clos (ground terms) qui
15

Cest un langage de programmation et de spcification algbrique de la famille OBJ bas sur une logique
quationnelle de sorte ordonnn (Order sorted equational logic).
16
En anglais membership equational logic.

46

CHAPITRE II

ECATNets et logique de rcriture

sont des termes sans variables [58]. Deux termes clos dsignent le mme lment si et
seulement si elles appartiennent la mme classe dquivalence tel que dtermin par les
quations. Les quations sont considres comme des rgles de simplification orientes et
sont utilises seulement de gauche droite.
Le calcul dans un module fonctionnel est accompli en utilisant les quations comme
rgles de rcriture jusqu ce quune forme canonique soit trouve [57]. Le rsultat du
calcul (forme canonique) est le mme quelque soit lordre dans lequel les quations sont
appliques. Les quations sont dclares en utilisant les mots cls eq ou ceq (pour les
quations conditionnelles). Maude supporte des simplifications quationnelles modulo
nimporte quel combinaison des oprateurs dassociativit (spcifi par le mot cl : assoc)
et/ou de commutativit (le mot cl : comm) et qui peut avoir aussi un lment identit (le
mot cl : id :). Ce qui veut dire que la simplification a lieu pas seulement entre les termes,
mais entre les classes dquivalence de termes modulo de tels axiomes quationnels [59].
La logique quationnelle sur laquelle les modules fonctionnels de Maude sont bass
est une extension de la logique quationnelle de sorte ordonn nomme logique
quationnelle dappartenance (membership equational logic). Ainsi, les modules
fonctionnels supportent la dclaration de sortes (types) multiples, la relation entre les sous
sortes (subsorts), et la surcharge des oprateurs [58]. Les axiomes dans cette logique
peuvent tre conditionnels ou inconditionnels.
Un module fonctionnel est de la forme : fmod endfm, o reprsente une thorie
quationnelle. Lexemple suivant illustre un module fonctionnel dun type abstrait de
donne celui des naturels :
fmod BASIC-NAT is
*** BASIC-NAT est le nom du module
sort Nat .
*** une sorte (type) Nat
op 0 : -> Nat [ctor] .
*** une opration
op s_ : Nat -> Nat [ctor] .
***le mot cl ctor dsigne un constructeur
op _+_ : Nat Nat -> Nat .
*** opration daddition sur deux naturels
op max : Nat Nat -> Nat .
vars N M : Nat .
*** dclaration de deux variables de type Nat
eq s M + N = s (M + N) .
*** une quation
eq 0 + N = N .
*** N + 0 et N dnotent le mme terme (mme classe dquivalence) qui est [N]
eq max(0, M) = M .
eq max(N, 0) = N .
eq max(s N, s M) = s max(N, M) .
endfm

Lvaluation des expressions dans les modules fonctionnels se fait laide de la


commande reduce (en abrger red).

47

CHAPITRE II
4.3.2.2

ECATNets et logique de rcriture

Modules systmes

Un module systme spcifie une thorie de rcriture. De la mme manire quun


module fonctionnel principalement la forme, fmod (, E) endfm, tel que (, E) une
thorie de la logique quationnelle dappartenance, un module systme essentiellement la
forme mod (, E, R) endm, tel que (, E, R) est une thorie de rcriture [59]. Une thorie
de rcriture inclut des sortes et des oprateurs et peut avoir trois types dinstructions : les
quations, lappartenance, et les rgles de rcriture, qui peuvent tous tre conditionnel
[58].
Une rgle de rcriture conditionnelle est spcifie en Maude avec la syntaxe :
crl [l] : t => t ' if cond, de mme, une rgle de rcriture inconditionnelle est spcifie
comme suit : rl [l] : t => t ' .
Smantiquement, les rgles de rcriture expriment le comportement dynamique dun
systme. Une rgle spcifie une transition concurrente locale qui peut se produire dans un
systme si la partie gauche de la rgle correspond un fragment de ltat du systme avec
la condition tant valide. Dans un module systme ou orient objet les quations sont
dclares par les mots cl ax ou cax. Un module systme est de la forme :
mod <ModuleName> is <DeclarationsAndStatements> endm
Revenant maintenant notre exemple prsent dans la section 4.3.1, qui modlise la
machine vendeuse de pommes et de tartes pour quelques explications.
mod PETRI-MACHINE is
sort Marking .
ops null $ c a q : -> Marking [ctor].
ops _ _ : Marking Marking -> Marking [ctor assoc comm id: null].
rl [buy-c] : $ => c.
rl [buy-a] : $ => a q.
rl [chng] : q q q q => $.
endm
La spcification de cette machine est donne par le type (sort) Marking reprsentant
le marquage dans un RdP. Les oprations sur ces marquages sont dfinit laide du mot
cl op ou ops (pour plusieurs oprations). Chaque place dans un RdP constitue un
marquage, cela est dfinit par le constructeur ctor indiquant que c, a, $, q, et null sont des
marquages de places. Les mots cls assoc et comm signifient les oprations dassociativit
et de commutativit entre deux multisets de marquages, ayant null comme lments
identit.

48

CHAPITRE II

ECATNets et logique de rcriture

La dynamique de ce systme est exprime en termes de rgles de rcriture montrant


les changements lmentaires se produisant durant son excution. Lexcution dun
module systme Maude se fait par la commande rewrite (rew).
4.3.2.3

Modules orients objets

Il y a le Core Maude qui contient principalement les modules systmes et le modules


fonctionnels, et le Full Maude qui est une extension du Core Maude avec les modules
orients objets pour permettre la dfinition des systmes concurrents orients objets.
Dans les systmes concurrents orients objets ltat concurrent, qui est appel
habituellement une configuration, a typiquement la structure dun multiset constitu
dobjets et de messages. Ces derniers voluent par rcriture concurrente modulo
lassociativit, commutativit, et llment identit en utilisant des rgles dcrivant les
effets des vnements de communication entre les objets et les messages [57]. Tout les
modules orients objets incluent un module nomm CONFIGURATION qui dfinit les
concepts de base des systmes objets concurrents. Ce dernier inclus la dclaration de
sortes suivantes :
Oid : identificateurs dobjets,
Cid : identificateurs de classes,
Objsect : pour les objets, et
Msg : pour les messages.

Ltat dun objet est reprsent dans Maude par un terme <O : C | a1 : v1, , an : vn>,
tel que O est le nom de lobjet ou lidentificateur, C est lidentificateur de sa classe, les ai
sont les noms des identificateurs des attributs de lobjet et les vi leurs valeurs
correspondantes. Les classes sont dfinies par le mot cl class suivit du nom de la classe
C, et dune liste dattributs spars par des virgules. Chaque attribut est de la forme a : S, a
est un attribut, S est la sorte (type) des valeurs de lattribut ; C | a1 : S, , an : Sn. Les rgles
de rcriture dans un module orient objet nous spcifient le comportement associ avec
les messages. Lexemple suivant illustre un module orient objet modlisant des comptes
bancaires :
(omod ACCOUNT is
protecting QID . *** importation du module quoted identifiers
protecting INT . *** importation du module des entiers.
subsort Qid < Oid . *** dclarer Qid comme sous sorte de Oid
class Account | bal : Int . *** dclaration dune classe Account avec un attribute de balancebal de typr int.
msgs credit debit : Oid Int -> Msg .
respectivement.

dclarer deux messages credit et debit de type Oid et Int

msg from_to_transfer_ : Oid Oid Int -> Msg .


vars A B : Oid .
var M : Nat .
vars N N : Int .

49

CHAPITRE II

ECATNets et logique de rcriture

rl [credit] :
credit(A, M)
< A : Account | bal : N >
=> < A : Account | bal : N + M > . *** une rgle de rcriture inconditionnelle
crl [debit] :
debit(A, M)
< A : Account | bal : N > => < A : Account | bal : N - M > if N >= M . *** une rgle de rcriture
conditionnelle
crl [transfer] :
(from A to B transfer M)
< A : Account | bal : N > < B : Account | bal : N >
=> < A : Account | bal : N - M > < B : Account | bal : N + M > if N >= M .
endom)

Nous pouvons maintenant rcrire une simple configuration compose dun compte et
un message comme suit:
Maude> (rew < A-06238 : Account | bal : 2000 >
debit(A-06238, 1000) .)
result Object :
< A-06238 : Account | bal : 1000 >
Si on utilise le Full Maude, tel est notre cas, on met le tout entre parenthses.

5. ECATNets
Les rseaux de Petri sont des modles de concurrence largement utiliss. Ce modle
est attractif dun point de vue thorique, en raison de sa simplicit attrayante est de sa
nature intrinsquement concurrente [60]. Linterprtation dun rseau de Petri simple dans
la logique de rcriture a t donne plus haut, o pour chaque transition on associe la
rgle de rcriture approprie, et deuximement le marquage dans le rseau est reprsent
par un terme compos de places (en utilisant loprateur ) contenant des jetons.
La logique de rcriture offre un Framework naturel pour donner une smantique a
diffrents types de rseaux de Petri algbrique [56]. Plusieurs propositions ont t
introduite dans ce contexte, parmi elles dont nous nous somme intresss dans ce mmoire
pour la modlisation des logiciels base de composants sont les ECATNets (Extended
Concurrent Algebraic Term Nets). Ces derniers constituent une catgorie des rseaux de
ptri algbrique de hauts niveaux bass sur une combinaison saine des rseaux de Petri de
haut niveau et des types abstraits algbriques.
Les ECATNets ont t proposs comme une extension des CATNets (Concurrent
Algebraic Term Nets) initialement introduits et dfinis par Bettaz et Maouche dans [48]. Ils
combinent (ECATNets) la force des RdPs avec celle des types abstraits de donnes. Les
50

CHAPITRE II

ECATNets et logique de rcriture

rseaux de Petri sont utiliss pour leur puissance dexprimer la concurrence et leurs
dynamiques, alors que les types abstraits de donnes sont motivs pour leurs pouvoirs
dabstraction de donnes et leurs bases mathmatiques solides [61]. La smantique des
ECATNets est donne en termes de la logique de rcriture, permettant ainsi dtudier et
de spcifier formellement le comportement des systmes modliss.
La logique de rcriture dans ces modles consiste en un ensemble daxiomes et un
ensemble de rgles de dduction [61]. Les axiomes sont des rgles de rcriture dcrivant
leffet des transitions comme tant des types lmentaires de changement dtat. Les rgles
de dduction permettent de propager leffet des changements lmentaires sur ltat
global du systme. Sous ces hypothses le comportement dun systme (dfini en termes
de changements dtat) peut tre dcrit par une preuve (en utilisant la logique en question)
qui nous permet de dduire un tat partir dun autre [62].
La dfinition de base des ECATNets est fonde sur celle de leurs prdcesseurs les
CATNets dfinit pour la premire fois dans [48], o on peut trouv plus de dtails. Nous
allons prsenter dans la section suivante la dfinition formelle des ECATNets.
5.1 Dfinition formelle dun ECATNets
Etant donn CATNas(X) la structure syntaxique de CATNet qui constitue une
structure algbrique (pour plus de dtails voir [48]). La structure syntaxique dun
ECATNet dnot CATNas(X)+ est dfinit par induction comme suit [61] :
-

CATNas(X) CATNas(X)+
Empty (Llment vide) CATNas(X)+
Si [m] CATNas(X) alors ~[m] CATNas(X)+

Dans la suite, CATNas(X) sera appel la structure syntaxique dun ECATNet.


Un ECATNet est un rseau de Petri de haut niveau dune structure [61] :
(P, T, s, IC, DT, CT, C, TC) o,
-

P est lensemble de places et T est lensemble de transitions ;

s : P S est une fonction qui associe un sorte a chaque place ;

IC : (P T) CATNas(X)+ est une fonction partielle tel que pour tout


(p,t) domaine(IC), si IC(p, t) CATNas(X) alors IC(p, t) CATNas(X)s(p)
sinon, si IC(p, t) empty alors [m] CATNas(X)s(p) tel que IC(p, t) = ~[m] ;

DT : (P T) CATNas(X) est une fonction tel que pour tout (p, t) (P T),
DT(p, t) CATNas(X)s(p) ;

CT : (P T) CATNas(X) est une fonction tel que pour tout (p, t) (P T),
CT(p, t) CATNas(X)s(p);

51

CHAPITRE II

ECATNets et logique de rcriture

C : P CATNas() est une fonction partielle tel que pour tout p domaine(C),
C(p) CATNas() ; si une place p nappartiens pas a domaine(C) elle est
considre comme place avec une capacit infinie.

TC : T CATNas(X)bool est une fonction tel que pour tout t T, TC(t)


CATNas(X(t))bool o X(t) est lensemble de variable qui se produisent dans
IC(p,t), DT(p, t) et CT(p, t) pour tout p P.

5.2 Syntaxe des ECATNets


Les ECATNets permettent la construction de modles hautement compacte grce
leurs notations syntaxique puissante. Dun point de vue syntaxique, la diffrence entre les
RdPs ordinaire et les ECATNets est que les places et les arcs sont inscrits par des multisets
(multi-ensembles) de termes algbriques.
Un ECATNet est une paire = (Spec, N) o Spec = ( , E) est une spcification
algbrique dun type abstrait de donne, et N est un rseau de Petri dans lequel les
marquages des places sont des multisets de -terms [63]. Le marquage dune place p par
un ensemble de jetons est dnot M(p). Le marquage dun ECATNets est donc des
multisets de termes algbriques spcifis par lutilisateur. La reprsentation graphique dun
ECATNet est donne par la figure 11 :

DT(p, t)
IC(p, t)
p: s

TC(t)
CT(p, t)
t

p: s

Fig. 11 Reprsentation gnrique dun ECATNet


On distingue entre trois types de multisets utiliss pour inscrire les arcs dans un
ECATNet qui sont IC, DT et CT. Les arcs entrants de chaque transition t i.e. (p, t) sont
tiquets par deux inscriptions IC(p, t) (Input Conditions) et DT(p, t) (Destroyed Tockens).
Les arcs sortants de chaque transition t i.e. (t, p) sont tiquets par CT(p, t) (Created
Tockens). Finalement, chaque transition t peut tre tiquete par TC(t) (Transition
Condition) qui prend comme valeur par dfaut le terme true (quand TC(t) est omis).
IC(p, t) spcifie la condition de franchissement de la transition t, DT(p, t) spcifie les
jetons (un multiset) qui doivent tre enlever depuis p quand t est franchie. Il est vident que
le multiset DT(p, t) doit tre inclut dans le marquage de la place p (i.e. DT(p, t) IC(p,
t)). IC(p, t) ou DT(p, t) sont omis dans la reprsentation graphique des ECATNets lorsque
IC(p, t) = DT(p, t). CT(t, p) spcifie les jetons qui doivent tre ajouts a p quand t est
franchie, et finalement TC(t) reprsente un terme boolen qui spcifie une condition de
franchissement additionnelle pour la transition t, elle prcise quelques contraintes sur les
valeurs prises par les variables locales de t.

52

CHAPITRE II

ECATNets et logique de rcriture

Une caractristique importante des ECATNets est quils font la distinction entre la
condition de franchissement et les jetons qui devrons tre enlevs durant le franchissement
de la transition t (reprsents respectivement par IC(p, t) et DT(p, t)), alors que dans
plusieurs type de rseaux de Petri de haut niveau les jetons (multiset) a enlever sont
exactement les jetons qui satisfassent la condition dentre [63].
Ltat courant dun ECATNet reprsent par un marquage est donn par lunion des
termes ayant la forme (p, M(p)) [60].
Lexemple suivant montre ltat distribu dun ECATNet reprsent par une
transition, une place dentre p, et une place de sortie vide p.
abc

s= (p, a b c) (p, ) o dnote lunion sur les multisets, et dnote


lopration interne sur les termes considrs comme singleton (a b c). Le symbole
est distributif par rapport loprateur .
5.3 Smantique des ECATNets
Le comportement dun ECATNet comme mentionner plus haut est donne en terme de
la logique de rcriture. Elle consiste dans ce contexte en un ensemble de rgles de
rcritures qui constituent les axiomes, et un ensemble de rgles de dduction. Le
comportement de ce type de rseau tel est le cas pour les autres types aussi, est traduit par
un changement dtat d au franchissement successif des transitions qui font pass le
systme dun tat un autre.
Une transition dans un ECATNet est franchissable a nimporte quel moment si
plusieurs conditions sont satisfaites simultanment [61] :
La premire est que tout IC(p, t) pour chaque place dentre p est satisfaite.
La deuxime est que TC(t) est vraie.
Et enfin, laddition de CT(t, p) chaque place de sortie p ne doit pas avoir
comme consquence dexcder sa capacit quand cette capacit est finie.
Lors du franchissement dune transition t, DT (p, t) est enlev totalement (cas positif)
de la place dentre p et simultanment CT(t, p) est ajout a la place de sortie p. Notons
que dans le cas non positif, on enlve les lments en commun entre DT(p, t) et M(p). Le
franchissement dune transition et les conditions de ce franchissement sont formellement
exprims par des rgles de la logique de rcriture. Les axiomes sont en ralit des rgles
de rcriture conditionnelles dcrivant les effets des transitions comme des types
lmentaires de changement. Les rgles de dduction nous permettent davoir des
conclusions valides des ECATNets partir des changements.
53

CHAPITRE II

ECATNets et logique de rcriture

Une rgles de rcriture est de la forme t: u v if boolexp; o u et v sont


respectivement les cts gauche et droit de la rgle, t est la transition lie cette rgle, et
boolexp est un terme boolen. Plus prcisment, u et v sont des multisets des pairs de
la forme (p, [m]), telle que p est une place du rseau, [m] est un multiset des termes
algbriques. Lunion des multiset sur les pairs (p, [m]) est dnot par . [x] dnote la
classe dquivalence de x, selon les axiomes ACI (Associativity Commutativity Identity =
B) pour [60]. Nous allons prsenter les rgles de rcriture (les mtargles) associes
aux ECATNets, qui dfinissent et capture le comportement concurrent et distribu de ces
derniers. La forme de ces rgles dpends fortement sur la relation entre IC(p, t) et DT(p,
t).la forme gnrale des rgles de rcriture est la suivante [62]:
IC(p,t) est de la forme [m]
Cas 1. [IC(p,t)] = [DT(p,t)]
Cest la relation la plus simple est corresponds aux cas habituellement traits dans les RdPs
simple ainsi que dans les CATNets (prdcesseur des ECATNets).
La mtargle a La forme suivante : t : (p, [IC(p, t)]) (p, [CT(t, p)]) (R1 : rgle1).
Cas 2. [IC(p, t)] [DT(p, t)] = M
Cette situation correspond vrifier que IC(p, t) est inclus dans M(p) et, retirer DT(p,
t) de M(p). Il est clair quil ny a pas dlment en commun entre IC(p, t) et DT(p, t) et que
IC(p, t) est juste utilis pour jouer le rle dun jeton dclencheur permettant le
franchissement de la transition en question.
La forme de la rgle est : t : (p, [IC(p, t)]) (p, [DT(p, t)]) (p, [IC(p, t)])
(p, [CT(t, p)]) (R2).
Cette forme simple et inconditionnelle peut conduire une description non correcte de
la nature du paralllisme dsir par le spcifieur, lindterminisme ou le vrai paralllisme
[64]. Un cas de figure a t discut dans [64] montrant une situation o on veut exprimer le
vrai paralllisme mais qui ne peut tre reprsent avec la forme simple de la rgle, il sagit
dune place p partage comme place dentre de deux transitions t1 et t2, et ayant chacune
une place de sortie. Une deuxime forme a t propose, pour montrer une smantique de
vrai paralllisme au lieu dune smantique dentrelacement. Dans ce derniers cas le tirage
dune transition est non dterministe. La forme de la rgle est la suivante :
(p, [DT(p, t)]) (p, [CT(t, p)]) if (p, [IC(p, t)]) [M(p)] (p, [IC(p,
t)]) (R2' )
Cette rgle montre que le tirage dune transition est conditionner par la prsence de
IC(p,t) et se traduit par le retrait de DT(p, t) de p suivit du dpt de CT(t, p)dans p.
54

CHAPITRE II

ECATNets et logique de rcriture

Cas 3. [IC(p, t)] [DT(p, t)] M (R3)


Cette situation correspond au cas le plus gnral. Elle peut cependant tre rsolue
dune manire lgante en remarquant quelle pourrait tre apporte aux deux cas
prcdents. Ceci est ralis en remplaant la transition t de ce cas par deux transitions t1 et
t2. Ces transitions, une fois elles sont franchises concurremment, donnent le mme effet
global que notre transition. Nous clatons IC(p, t) en deux multisets IC1(p, t1) et IC1(p,
t2). Nous clatons galement DT(p, t) en deux multisets DT1(p, t1) et DT1(p, t2) :
IC(p, t) = IC1(p, t1) IC1(p, t2), DT(p, t) = DT1(p, t1) DT1(p, t2).
Les quatre multisets obtenus doivent raliser IC1(p, t1) = DT1(p, t1) et IC2(p, t2)
DT2(p, t2) = M. Le franchissement de la transition t est identique au franchissement en
parallle des deux transitions t1 et t2.
IC(p, t) est de la forme ~[m]
Dans quelques situations on sintresse au franchissement dune transition lorsque sa
place dentre ne contient pas un multiset de jetons prcis M. Dans ce cas, on utilise la
notation ~M a la place du multiset IC(p, t). La forme de la rgle correspondante est:
t : (p, [DT(p, t)] [M(p)]) (p, [CT(t, p)]) if ([IC(p, t)] \ ([IC(p, t)] [M(p)]))
= M [false]. (R4).
La partie conditionnelle traduise le fait que la transition t est franchissable si le
marquage de sa place dentre ne contient aucun jeton appartenant M.
IC(p, t) = empty
Dans dautres situations on sintresse par le franchissement dune transition lorsque
sa place dentre est vide. On utilise dans ce cas la notation empty a la place du multiset
IC(p, t). La forme de la rgle correspondante est:
t : (p, [DT(p, t)] [M(p)]) (p, [CT(t, p)]) if [M(p)] M (R5).
Si la capacit de la place de sortie C(p) est finie, la partie conditionnelle de la rgle de
rcriture doit inclure le composant suivant :
[CT(p, t)] [M(p)] [C(p)] [CT(p, t)] [M(p)] (Cap).
Dans le cas o il y a une condition de transition TC(t), chaque mtargle doit contenir
dans sa partie conditionnelle lexpression conditionnelle : and TC(t) true (R6).

55

CHAPITRE II

ECATNets et logique de rcriture

La forme dune rgle qui correspond une transition avec une place dentre et
plusieurs places de sorties est obtenue par lunion de tous les multisets CT(t, p) des arcs
sortants [64]. La situation o une transition a plusieurs places dentres peut tre
considre comme la composition de lapplication des rgles sur tous les arcs de bases.
Nous allons maintenant citer lensemble des rgles de dduction dfinit dans les
ECATNets. Soit R la thorie de rcriture dun ECATNet, on dit que la squence s s
est prouvable dans R, o (s, s) sont deux tat diffrents, Ssi s s peut tre obtenu par
des applications finies et concurrentes des rgles de dduction suivantes : Rflexivit
(Reflexivity), Congruence (Congruence), Remplacement (Replacement) [55];
Dcomposition (Splitting), Recombinaison (Recombination) et lIdentit (Identity) [48].
Les trois premires rgles ont t dj abordes dans la logique de rcriture, les trois
dernires rgles sont inhrentes aux ECATNets :
Dcomposition: p P, [mi] et [M] des lments de type CATNas(X),

Exemple : (p, a b) = (p, a) (p, b)


Recombinaison
p P, [m] et [m] des lments de type CATNas(X),

Exemple : (p, a) (p, b)= (p, a b)


Identit
p P,

(p, M) = B

Nous rappelons que la rgle de rflexivit dcrit que chaque tat se transforme en luimme. La rgle de congruence que les changements lmentaires doivent tre correctement
propags. La rgle de remplacement est utilise quand les instanciations de variables
deviennent ncessaires. Les rgles de dcomposition et de recombinaison nous permettent,
en dcomposant et recombinant "judicieusement" les multi-ensembles des classes
dquivalences des termes, pour dtecter les calculs montrant un maximum de
concurrence. La rgle didentit permet de lier M (llment identit de ) avec B
(llment identit de ).
56

CHAPITRE II

ECATNets et logique de rcriture

La logique de rcriture, i.e., la thorie de rcriture et les rgles de dduction, signifie


que le comportement dun ECATNet est donn par un systme de dduction, qui pour un
tat donn s, il va cherch tout les changements de base possible (application des
axiomes) est essaye de les composs (application des rgles de dduction) de manire
atteindre ltat suivant s, qui correspond au calcul concurrent prvu par le rseau [48]. Un
exemple dtaill peut tre trouv dans [65].
5.4 Exemples de modlisation avec les ECATNets
Nous allons essayer travers un exemple illustratif de montrer lutilisation du
formalisme des ECATNets dans la modlisation des systmes rels. Lexemple suivant, a
t modlis en utilisant les ECATNets dans [64].
5.4.1 Prsentation de lexemple 1
Lexemple est propos dune cellule de production qui fabrique des pices forges de
mtal laide dune pression. Cette cellule se compose de table A qui sert alimenter la
cellule en pices brutes, dun robot de manutention, dune presse et dune table B qui sert
au stockage des pices forges. Le robot inclut deux bras, disposs perpendiculairement sur
un mme plan horizontal, interdpendant dun mme axe de rotation et sans possibilit
verticale de mobilit. La figure 12 reprsente la disposition spatiale des lments de la
cellule. Le robot peut prendre une pice brute de la table A et la dposer dans la presse
laide du bras 1. Il peut galement prendre une pice forge de la presse et la dposer sur la
table du stockage B laide du bras 2. En bref, le robot peut faire deux mouvements de
rotation. Le premier lui permet de passer de sa position initiale sa position secondaire. Ce
mouvement permet au robot de dposer une pice brute dans la pression et probablement
celui dune pice forge sur la table du stockage B. Le second lui permet de passer de sa
position secondaire vers sa position initiale et de poursuivre le cycle de la rotation.

Table B

Presse

Table A

Fig. 12 Cellule de production [64]


Modle ECATNet
La figure 13 reprsente le modle ECATNet de la cellule de production schmatise
ci-dessus. Le symbole est utilis pour dnoter le multiset (multi-ensemble) vide dans les
inscriptions des arcs. Les multisets r sur les arcs dnote raw (brute) et f dnote forge
(forge). On a prcdemment indiqu que ces derniers sont des spcifications algbriques
57

CHAPITRE II

ECATNets et logique de rcriture

de type abstrait de donnes qui doivent tre bien videment dfinit par lutilisateur. Si les
inscriptions IC(p, t) et DT(p, t) sont identiques, alors nous prsentons uniquement IC(p, t)
sur larc (p, t).
Les places
Ta : table A ; ensemble, potentiellement vide, des pices brutes.
Tb : table B ; ensemble, potentiellement vide, des pices forges.
Ar1 : bras 1 du robot ; au plus une pice brute.
Ar2 : bras 2 du robot ; au plus une pice forge.
Pr : presse ; au plus une pice brute ou une pice forge.
PosI : position initiale du robot ; elle est marque "ok"si elle est la position courante du
robot.
PosS : position secondaire du robot ; elle est marque "ok" si elle est la position courante
du robot.
EA : cette place a t ajoute pour tester si les deux bras du robot sont vides.
Les transitions
T1 : prise dune pice brute par le bras 1 du robot.
T2 : prise dune pice forge par le bras 2 du robot.
D1 : dpt dune pice brute dans la presse.
D2 : dpt dune pice forge sur la table B.
TS1, TS2 : rotation du robot de la position initiale vers la position secondaire.
TI : rotation du robot de la position secondaire vers la position initiale.
F : forge de la pice brute introduite dans la presse.
E : dpt dune pice brute sur la table A.
R : retire des pices forges de la table B.

58

CHAPITRE II

ECATNets et logique de rcriture

Fig. 13 Modle ECATNet de la cellule de production [64]


Les rgles de rcriture
[T1]: appliquer (R2' ) % (Ta, raw) (Ar1, raw) if (M(Pos-I) ok)
and ((Ar1, raw) M(Ar1) C(Ar1)) (Ar1, raw) M(Ar1) ..(1)
(1) ajoute car la capacit de la place Ar1 est finie (une pice brute au plus)
[T2]: appliquer (R2' ) % (Pr, forge) (Ar2, forge) if (M(Pos-I) ok)
and ((Ar2, raw) M(Ar2) C(Ar2)) (Ar2, raw) M(Ar2)
[D1]: appliquer (R2' ) % (Ar1, raw) (Pr, raw) (Ea, Ear1) if (M(Pos-S) ok)
[D2]: appliquer (R2' ) % (Ar2, forge) (Tb, forge) (Ea, Ear2) if (M(Pos-S) ok))
[TS1]: (Pos-I, ok) (Pos-S, ok) if (M(Ar1) raw)
[TS2]: (Pos-I, ok) (Pos-S, ok) if (M(Ar2) forge)
[TI]: (Pos-S, ok) (Ea, Ear1) (Ea, Ear2) (Pos-I, ok) if (M(Pos-S) ok)
[F] : (Pr, raw) (Pr, forge)
[E] : (Ta, raw)
[R] : (Tb, forge)

59

CHAPITRE II

ECATNets et logique de rcriture

5.4.2 Prsentation de lexemple 2


Lexemple suivant [62] est tir du domaine des protocoles de communication. Il
consiste modliser le protocole Ethernet vu par une station mettrice. Cette dernire est
compose de quatre modules : un module de construction de trames et dbut de
transmission, un module qui a la fonction de transmission avec succs, le troisime traite la
dtection de collision, le dernier est relatif la fonction de retransmission. Nous allons se
limiter dans notre cas prsenter seulement le premier module. Expliquons maintenant le
rle de ce module. La construction de la trame commence lorsque un jeton <d,s,data>est
dpos dans la place FROM_USER (figure 14).

Fig. 14 Modle ECATNet du module dbut de transmission


dune station mettrice Ethernet [62]
Ce jeton est considrer comme une primitive transfre depuis la couche utilisateur
vers la sous couche MAC (Medium Access Control) demandant la transmission dune
valeur data depuis la source s vers la destination d. La place FROM_USER est
60

CHAPITRE II

ECATNets et logique de rcriture

considre comme une interface entre les deux couches. Ensuite, un code de contrle
derreur sur la donne est ajouts la trame fcs (Frame Check Sequence) d.s.data.fcs, qui
sera compose dans un registre de transmission TRANS_REG. Une copie de la trame est
conserve dans un registre de retransmission RETR_REG.
Dautre part, la sous couche MAC coute le canal de transmission
CARRIER_SENSE pour viter les collisions qui peuvent se produire avec la
transmission en cours. La place CARRIER_SENSE est une interface entre la sous couche
MAC et la couche physique. Si le canal est libre (un jeton false est prsent dans la place
CARRIER_SENSE) elle attend pendant une priode de temps qui corresponds au
parcours dune trame entre les deux nuds les plus loigns dans le rseau. Ensuite, si la
transmission a eut lieu avec succs (dpt dun jeton false dans la place
BUSY_CHANNEL, et un jeton true dans la place SUC_TRANS) elle prend
possession du canal CHANNEL_ACCESS et la transmission commence (dpt dun
jeton true dans la place INIT_TRANS).
Les rgles de rcriture
COMPUTE_FCS : appliquer (R2)% (FROM_USER,<d,s,data>)
(FROM_USER,<d,s,data>) (ERROR_SEQ, fcs).
ASSEMB_FRAME : appliquer (R1)% (FROM_USER,<d,s,data>) (ERROR_SEQ, fcs)
(TRANS_REG, d.s.data.fcs) (RETR_REG, d.s.data.fcs).
CHANNEL_ACCESS: appliquer (R2) et (R1) % (TRANS_REG, d.s.data.fcs)
(BUSY_CHANNEL, false) (INIT_TRANS, true) (TRANS_REG, d.s.data.fcs).
DELAY: appliquer (R1) et (R6) % (CARRIER_SENSE, false) (SUC_TRANS, x)
(BUSY_CHANNEL, x) (SUC_TRANS, not(x)) if (x=false) true.
6. Conclusion
Nous avons pu voir travers ce chapitre les parties qui constituent les lments de
base de notre travail, il sagit de proposer une approche de modlisation des logiciels
base de composants en utilisant les RdPs. On a commenc par un bref survol sur les
rseaux de ptri dans lequel nous avons introduit ce formalisme. Les RdPs existent sur
plusieurs formes, les HLPN en constituent lune delles. Ils taient introduits pour rsoudre
le problme dexplosion dtat, permettant ainsi une reprsentation plus compacte des
systmes complexes concurrent et distribus. On a prsent ensuite les RdPs algbriques
(AHL nets) qui reprsente une variante spcifique des HLPN, ils combinent les rseaux de
Petri et les spcifications algbriques. Ces derniers sont bien tablis pour la spcification
formelle de types abstraits de donnes et des systmes logiciels. On a introduit par la suite
la logique de rcriture qui constitue un Framework pour la spcification des systmes
distribus et concurrents ainsi que son langage Maude. Plusieurs modles peuvent tre
61

CHAPITRE II

ECATNets et logique de rcriture

naturellement reprsents dans cette logique, y compris les RdPs. Dans ce contexte, des
efforts considrables ont t investit pour faire le couplage entre les RdPs algbrique et
cette logique donnant naissance par exemple aux ECATNets. Notre choix a t port dans
ce mmoire sur ce formalisme, pour la modlisation des logiciels base de composants.
Nous allons expliquer nos motivations sur ce choix dans le prochain chapitre qui sera
consacr la prsentation de notre approche.

62

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

CHAPITRE III :

Modlisation des logiciels base de


composants avec les ECATNets

1. Introduction
Dans ce chapitre nous allons prsenter une approche formelle de modlisation des
logiciels base de composants en utilisant le formalisme des ECATNets. Les
spcifications de composants logiciels utiliss dans les pratiques du dveloppement
logiciels aujourdhui sont limites aux spcifications syntaxiques. Ce type de spcification
noffre pas suffisamment dinformations sur la smantique des oprations qui dfinissent
les interfaces dun composant, ce qui peut faciliter la comprhension du comportement de
ces derniers. Pour pouvoir assurer cette smantique et disposer de plus ample
dinformations sur le comportement des composants, nous avons choisis lalternative
dutiliser les mthodes formelles. Celles-ci, nous permettent de construire des modles
mathmatiques ayant une smantique bien dfinit, et rendent possible lanalyse et la
vrification des systmes en cours de spcification. Ceci peut aider viter les erreurs de
composition qui peuvent mener assez souvent des comportements bizarres dune
application base de composant.
Une multitude de travaux ont t raliss dans ce contexte. Nous prsenterons
quelques uns dans la deuxime section de ce chapitre. Dans le mme contexte, et dans le
cadre de travail de ce mmoire, nous nous somme proposs contribu dans la discipline
du CBSE et participer a la faire voluer.

2. Travaux voisins
Peu de travaux en t consacr pour les fondements thoriques et formels dans le
dveloppement bas composants. Nous allons se limiter prsenter brivement quelques
travaux de formalisations des composants logiciels. Le premier [46] offre une manire
solide pour spcifi un composant logiciel en se basant sur la thorie de la logique du
premier ordre et les types abstraits de donnes (ADTs17). Les auteurs de ce travail ont
proposs une approche de spcification base sur la notion quils ont nomme a priori
correctness. Celle-ci suppose que lon peut prdire quun assemblage de composants est
17

Abstract Data Types

63

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

correct (correctness) avant de faire la composition, i.e. quil satisfait la spcification dont il
a t conu pour remplir, partir de lexactitude (correctness) des composants lmentaires
qui compose lassemblage dans tous les contextes prvus pour le composant. La
spcification dun composant suit une structure dfinit formellement un contexte pour le
composant reprsent par une signature (axiomes, fonctions, relations), une interface qui
dfinit des oprations et de contraintes, et un code.
De notre point de vue, ce travail offre un moyen pour spcifier et de vrifier
formellement la spcification dun ensemble de composants logiciels sparment et
dduire que lassemblage de ces composants est aussi correct. En revanche, il ne montre
pas les interconnexions et les relations qui existent entre ces composants, i.e. quel
composant doit tre connect avec tel ou tel composant, et quels sont les services changs
entre ces derniers via quels interfaces. Il ne modlise donc pas laspect de communication
dfinit gnralement par les modles de composants actuellement connus.
Le travail de [66] reprsente une tentative pour la modlisation formelle dun
composant logiciel. Les auteurs ont proposs une syntaxe et une smantique bien dfinit
pour un model de composant logiciel qui capture les concepts essentiels dont les
composants sont btis autours. Diffrents travaux de formalisations ont t cit dans ce
travail parmi eux, la spcification formelle de CORBA en utilisant le langage de
spcification Z pour assurer que les facilits ajouts CORBA sont correctes, une tentative
pour la formalisation du model COM qui consiste en un model bas sur la thorie des
ensembles du premier ordre exprime en langage Z. Chacune de ces formalisations dcrit
un modle de composants, et est destin un usage particulier. Lapproche propose par
les auteurs consiste dfinir un composant formellement comme tant un 4-tuple X de la
forme (inports, outports, function, triggers). Ils considrent le composant par analogie
comme une fonction qui des entres (inports) et des sorties (outports) ralisant une
tche prcise (function) qui est ralise en recevant un vnement en provenance dun
autre composant (triggers). Les (inports) et (outports) fournissent une interface via
laquelle le composant interagit avec les autres composants. Les auteurs renforcent le
modle par des reprsentations graphiques qui permettent la ralisation dassemblage de
composants. Une smantique reprsentant ltat, lexcution, la composition dun
composant est clairement dfinie.
Un autre travail, celui de [67] est similaire notre approche du fait que les auteurs en
utiliss une catgorie des rseaux de Petri de haut niveau qui sont les rseaux de Petri
colors, pour fournir une smantique formelle pour les concepts de base des composants
logiciels. Pour cette fin les auteurs ont suivis une approche dans laquelle ils ont commenc
tout dabord par la dfinition dun model de composant quils ont nomm CompoNet une
abrviation de Component and Petri Nets avec une reprsentation graphique. Le modle
est largement inspir du modle abstrait du CCM de CORBA, puisque il garde le mme
vocabulaire utilis par ce dernier. La notion dassemblage de composants est alors bien
dcrite. Ils ont ensuite proposs une notation pour spcifier formellement le comportement
interne dun composant logiciel. A travers cette notation les caractristiques et les

64

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

fonctionnalits dun composant logiciel tel que, laspect de communication et les interfaces
sont spcifis. Cette notation est base sur les RdPs colors. Ces derniers tant bien adapt
pour la spcification des systmes distribus et concurrents. Le concepteur qui va utiliser
lapproche doit en premier lieux dfinir larchitecture logicielle de son systme sous forme
dun assemblage de composants en utilisant CompoNet.Ensuite un mapping est dfinit
depuis les constructions du modle de composant (CompoNet) (facettes, rceptacles,)
vers les constructions des notations base sur les RdPs colors (places, transitions,) et
cela pour chaque composant. Les connexions inters composants sont aussi dfinit
formellement en terme des RdPs colors. Finalement, une spcification formelle du
comportement de lassemblage de composants est obtenue en reliant les composants entre
eux.
Le travail sest principalement focalis sur la smantique du comportement des
activits des composants logiciels.

3. Prsentation de lapproche de modlisation


Comme nous lavons mentionn dans le premier chapitre, le dveloppement et
lvolution dun produit logiciel suit un processus appel le processus logiciel. Plusieurs
approches ont t proposes dans ce cadre, mais elles se basent toutes sur les mmes
activits et se diffrent seulement de la manire dont elles sont ralises. Lenchanement
de ces activits dj abordes dans la section 2.1 du premier chapitre constitue le cycle de
vie dun produit logiciel. La phase de conception est une activit dans laquelle les
spcifications de larchitecture gnrale du logiciel sont labores. Les abstractions
fondamentales du systme logiciel et les relations entre elles sont dcrites et identifies
dans cette phase. Dans une approche de dveloppement bas composants, ltape qui suit
la spcification du systme consiste en la recherche et la slection des composants
rpondant aux besoins spcifis.
Lapproche de modlisation de logiciels base de composants que nous proposons
dmarre partir de larchitecture du systme logiciel, montrant linterconnexion de ses
diffrents composants ainsi que leurs spcifications. Pour ce faire, on sest bas sur le
formalisme des ECATNets pour la spcification des composants ainsi que leurs
connexions.
Nous distinguons trois tapes dans lapproche suivre (figure 15) :
1) Spcification du systme : lors de cette tape, les interfaces de chaque composant
ainsi que les connexions inters composants sont spcifies en utilisant la notation
propose qui est base sur le formalisme des ECATNets. Le rsultat de cette tape est
un modle ECATNet reprsentant la spcification dun assemblage de composant.
2) Gnration des rgles de rcriture : partir du modle ECATNet construit dans la
premire tape, lutilisateur gnre les rgles de rcriture associes au systme
modlis comme il a t montr dans les exemples du deuxime chapitre.

65

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

3) Vrification du systme : cette tape conclus la finalit et le but dune modlisation,


cest de pouvoir analyser et tudier certains aspects du systme spcifi. Cela est
ralis par le biais dune spcification crite en langage Maude, qui intgre dans son
corps les rgles de rcritures dfinies dans ltape prcdente. Le rsultat de cette
tape est une spcification excutable introduite dans linterprteur du langage
Maude pour tre vrifi.

Etape I

Etape II

Spcification du systme

Gnration des rgles de rcriture

Etape III
Vrification & analyse du systme

Spcification des
interfaces

Spcification des
connexions des
composants

Modle
ECATNet dun
assemblage de
composants

Application des
Mtargles
ECATNets sur le
modle de
lassemblage

Spcification
excutable en
langage Maude
(module
fonctionnel+modu
le systme)

Excution &
vrification de la
spcification

Fig. 15 Etapes de lapproche de modlisation des logiciels base de composants


Nous aborderons dans ce qui suit chaque tape de notre approche en dtail, dans
lesquelles nous motivons implicitement et explicitement le choix port sur les ECATNets.
3.1 Spcification du systme
Dans une approche de dveloppement bas composant la construction dapplications
logicielles est ralise par composition. Pour spcifier un systme logiciel base de
composants, cela revient spcifier les composants qui le constituent ainsi quaux
interconnexions entre ces composants. Un composant logiciel est dcrit en termes de ces
interfaces travers lesquelles il peut interagir avec lenvironnement externe constitu des
autres composants dans le systme.

66

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

La plupart des approches actuelles pour la dfinition des interfaces des composants se
limitent essentiellement aux spcifications syntaxiques. Cette forme de spcification
comprend les spcifications utilises dans des technologies comme COM, CORBA, et
JavaBeans [1]. Les deux premires utilisent les IDLs, alors que la troisime utilise le
langage de programmation Java pour spcifier les interfaces dun composant. Or, les
spcifications syntaxiques noffrent pas des informations sur la smantique des oprations
qui dfinissent ces interfaces tel que, par exemple les contraintes imposes pour
lexcution des oprations.
Nous proposant dans ce qui suit (figure 16) une notation base sur le formalisme des
ECATNets. A travers cette notation nous apporterons un formalisme smantique par lequel
une smantique formelle du systme peut tre spcifie. Ainsi, nous esprons couvrir deux
niveaux de spcification de proprits dans un composant : le niveau comportemental et le
niveau synchronisation. Le premier niveau exprime les conditions dentres et de sorties
des oprations qui dfinissent les interfaces dun composant logiciel. Alors que le
deuxime, exprime les dpendances entre les services fournis par un composant, tel que le
paralllisme.
Environnement externe

Service requis
(Rceptacle)

T
C

IC(p, t)
DT(p, t)

Wait
CT(t, Wait)

T
C

Service offert

T
C

IC(Wait, t)
T
C

Evnement
requis (Puit)

DT(p, t)
IC(p, t)

(Facette)

DT(Wait, t)
CT(t, q)

CT(t, q)

T CT(t, q)
C

CT(t, q)

Evnement
offert (Source)

Fig.16 Spcification dun composant logiciel


Cette notation graphique reprsente la spcification formelle des interfaces dun
composant logiciel. Une interface dun composant peut tre dfinie comme une
spcification de ces points daccs. Les composants clients accdent aux services fournis
par le composant en utilisant ces points. Si un composant plusieurs points daccs dont
chacun reprsente un service offert par le composant, le composant est suppos avoir
plusieurs interfaces.
En omettant les diffrences dans les dtails techniques tels que, le langage
dimplmentation, les mcanismes de paramtrage, mthodologies de dfinition
dinterfaces,etc, les technologies de composants (CORBA, COM, EJB,) ont
essentiellement des architectures et fonctionnalits similaires. Chacune de ces technologies
dfinit un composant comme tant une boite noire qui met et reoit des messages vers et

67

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

depuis dautres composants via des interfaces bien dfinies, et ralise des calculs en
rponse des vnements [66].
Notre travail est similaire celui de [67], nous avons suivi le mme vocabulaire du
modle composant utilis pour la spcification des interfaces du composant logiciel qui
est le CCM de CORBA pour sa simplicit. Les fonctionnalits offertes (Facettes) sont
considres comme des services ncessaires dautres composants, ceux qui sont requis
(Rceptacles) sont des services essentiels pour le composant pour accomplir ses fonctions
et qui sont fournis par dautres composants. Linteraction entre les composants est
reprsente par la communication par vnement et par invocations de mthodes. Chaque
composant peut envoyer (vnements source) et recevoir (vnements puits) des
vnements de son environnement externe.
Une caractristique essentielle dun composant est la sparation explicite entre les
aspects interne et externe de lentit encapsuler pour reprsenter un composant. En
dautre terme, un composant possde un intrieur cach et des interfaces exposes [10].
Dans la notation propose (fig.14) cet aspect dans les composants logiciels est pris en
considration et est reprsent par la zone nomme vue interne . Plus tard dans ce
chapitre, nous allons voir que cette partie du composant t spcifie seulement dans le
but de simuler le fonctionnement interne et non pas de spcifier limplmentation du
composant logiciel qui doit tre entirement encapsuler.
Pour modliser donc un logiciel base de composant en utilisant la notation propose,
nous devons spcifier les interfaces de chaque composant ainsi quaux interconnexions
entre ces composants. Nous allons dtailler dans la section suivante, outre la spcification
de chaque interface, la spcification des interconnexions qui permettent de construire un
assemblage de composants.
3.1.1 Service requis (Rceptacle)
Un service requis modlise une invocation de mthode qui rside dans un autre
composant. Linvocation dune mthode reprsente une communication de type synchrone
entre le composant client et le composant serveur (fournisseur du service). Un Rceptacle
est spcifi par deux transitions quon a nommes (StartInvocation, EndInvocation) et une
place (Wait) comme il est illustr par la figure 17.
DT(p, t)

StartNameInvocation

T
C

IC(p, t)
CT(t, q)

EndNameInvocation

T
C

Wait

DT(p, t)
IC(p, t)
CT(t, q)

Fig.17 Spcification dun service requis (Rceptacle)

68

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

La transition StartInvocation (SnameInv en abrg) spcifie le dbut de linvocation.


Larc entrant modlise un contrat (section 3.4.1.2 du chapitre 2) qui reprsente les prconditions (contraintes) qui doivent tre assures par le comportement interne du
composant pour pouvoir invoquer une mthode. Le nom de la mthode est explicitement
donn par le nom de la transition (exemple: StartExtractInvocation, Extract est le nom de
la mthode).
Larc sortant est connect la place Wait, cette dernire modlise le fait quun
composant est dans un tat bloqu en attente dune rponse depuis le composant
fournisseur du service. Cet arc est tiquet par le multiset de terme CT (Created Token) qui
indique ltat que le composant devrait atteindre.
La transition EndInvocation (ENameInv) spcifie la fin de linvocation de mthode.
Son arc entrant arrivant depuis la place Wait, modlise le contrat reprsentant les
conditions pouvant faire basculer ltat du composant vers ltat non bloqu. Larc sortant
reprsente les post-conditions qui devront tre valides pour le comportement interne du
composant aprs lexcution de laction modlise par la transition.
3.1.2 Service offert (facette)
Un service offert est une interface reprsente par une opration ncessaire pour
dautres clients pour accomplir leurs tches. Une facette vhicule les fonctionnalits
spcifiques quoffre le composant ses clients et que le dveloppeur doit implanter. On a
modlis une facette dans notre notation (figure 18) par deux places (NameRequest,
NameResult) et une transition (Name : est le nom donn lopration associe la
transition).
IC(p, t)

NameRequest

DT(p, t)
T
C

Name
CT(t, q)

NameResult

Fig. 18 Spcification dun service offert (Facette)


La place NameRequest modlise les invocations reues depuis les composants
clients existant dans lenvironnement du composant offrant le service. Ainsi, un service
fournit peut tre invoqu par plusieurs composants simultanment. Le franchissement de la
transition qui dpend des multisets de termes IC (Input Condition) et TC (Transition
Condition) reprsente lexcution de lopration associe cette transition. La place
NameResult modlise le service fournit comme rsultat de la transition franchie.
Dans certains cas lorsquun composant client invoque un service offert situ dans un
autre composant, ce dernier pour fournir le service doit faire appel dautres services
situs chez dautres composants qui eux mme peuvent demands leurs tours des services
69

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

dautres composants. Nous proposons une adaptation du modle plus haut (fig.16), en
clatant la transition Name en deux et en ajoutant une place Wait qui modlise un tat
de blocage du composant. Ltat de blocage reprsente lattente dune rponse dun autre
composant. La premire modlise le dbut du service et la deuxime sa fin. Ce modle
(figure 19) reprsente le cas le plus gnral pour modliser un service offert (Facette).
IC(p, t)

NameRequest

DT(p, t)
T
C

SName
Wait

T
C

EName
CT(t, q)

NameResult

Fig. 19 Modle gnrale dun service offert (Facette)


3.1.3 Evnement offert (source)
Un vnement offert ou bien vnement source dcrit un vnement qui peut tre mis
par le composant. Cet vnement peut tre intercept par dautres composants qui ont
manifest leurs intrts pour lui, il peut tre alors envoy en multicast plusieurs
rcepteurs. On a modlis ce type dvnement par une transition (NameSource) et une
place quon a nomme signal pour diffrencier entre la communication par invocation de
mthode et la communication par vnement dans un composant, et donner une manire
signifiante pour reprsenter lvnement mis (figure 20).
NameSource
T CT(t, q)
C

Signal

Fig. 20 Spcification dun vnement source


Le franchissement de la transition NameSource aura comme consquence le dpt
dun jeton CT (Created Token) dans la place signal, pour tre consomm par la suite par
la transition puit en relation dun autre composant qui prsent son intrt lvnement
source.
3.1.4 Evnement requis (puit)
Un vnement puit est un vnement que le composant est dispos recevoir. On a
conserv pour la modlisation dun vnement puit la mme notation graphique pour la
modlisation dun vnement source.
NameSink

CT(t, q)
T
C

Fig. 21 Spcification dun vnement puit


70

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

La transition est interface pour recevoir un vnement source. Le fait quune


transition soit franchie modlise la rception dun vnement et le dpt dun jeton CT
dans la place reliant larc sortant de la transition valide larrive dun vnement source en
provenance dun autre composant.
3.1.5 Spcification des connexions
Une composition peut tre obtenue entre les composants en reliant chaque
fonctionnalit spcifie une autre, les services offerts avec les services requis et les
vnements offerts avec les vnements requis de telle faon on obtiendra un assemblage
de composants.

Spcification dune connexion : Evnement source / puit

Un vnement source peut tre connect un nimporte quel nombre dvnements


puits, cest ainsi que le multicast dvnement vers plusieurs destinations (composants) est
modlis. Un vnement puit (requis) peut tre connect de la mme manire, ce qui
implique quil peut recevoir le mme vnement de sources distinctes. La figure 22 montre
le modle de connexion entre un vnement source et un vnement puit en utilisant la
notation graphique propose.
Evnement offert
(Source)
NameSource
Vue
interne

T CT(t, q)
C

Evnement
requis (Puit)
DT(p, t)
IC(p, t)

NameSink
T
C

CT(t, q)

Vue
interne

Place Signal
Composant B

Composant A

Fig. 22 spcification dune connexion :


vnement Source /Puit
La connexion entre les deux types dvnement est ralise simplement en reliant la
place du composant metteur A avec la transition NameSink du composant rcepteur
B tout en respectant le formalisme des ECATNets.
Le franchissement de la transition NameSink dpend de la prsence dun jeton CT
dans la place de sortie de la transition NameSource. On a nomm cette place Signal
pour illustrer la communication par vnement.

Spcification dune connexion : Services offerts / requis

La spcification dune connexion entre un service offert (facette) et un service requis


(Rceptacle) modlisant une invocation de mthode unicast, est donne par la rutilisation

71

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

du modle client / serveur dfinit dans [68]. La connexion est ralise par deux arcs (figure
23) :
-

Le premier est un arc sortant depuis la transition SNameInv du composant B vers la


place NameRequest du composant A.

Le second est un arc sortant depuis la place NameResult du composant A vers la


transition ENameInv du composant B.
Service requis
(Rceptacle)

Service offert
(Facette)
NameRequest
IC(p, t)

SNameInv DT(p, t)

CT(t, q)

DT(p, t)

Vue
interne

T
C

Name
CT(t, q)
NameResult

DT(p, t)
IC(p, t)

T
C

Wait
CT(t, Wait)
IC(Wait, t)

Vue
interne

T
C

ENameInv

Composant A

IC(p, t)

CT(t, q)

Composant B

Fig.23 Spcification dune connexion :


Services offerts / requis
La transition SNameInv du composant B est connecte avec la place
NameRequest du composant A par un arc sortant. Le franchissement de cette transition
reprsente linvocation du service demand et ajoute un jeton CT la place
NameRequest ce qui aura comme consquence le dclanchement du franchissement de la
transition Name du composant A. Dun autre ct, la transition SNameInv du
composant B dpose un second jeton dans la place Wait, ce qui changera bien sr ltat
du composant.
Aprs le franchissement de la transition Name, un jeton est cr dans la place
NameResult et de cette manire le rsultat du service est prt tre reus. La transition
EnameInv est maintenant franchissable, son tirage fait dlivrer le rsultat au composant
et change son tat dun tat dattente bloquant vers un tat non bloquant.
Maintenant, pour modliser un assemblage de composants logiciels avec les notations
proposes, il suffit didentifier en premier lieu pour chaque composant le type dinterfaces
qui expose aux autres composants et dgager les oprations qui les reprsentent. Le
langage de description utilis pour dfinir les interfaces du composant peut tre par
exemple de la famille des IDLs, le langage Java, une spcification en diagramme de
composants UML, ou mme une description en langage naturel qui spcifie toutes les
oprations de chaque interface. Lintrt de cette tape est de prciser lenveloppe quun
composant expose lenvironnement externe dont il fait partie, ainsi que les types de
paramtres imports et exports par ce composant. Ensuite, en utilisera bien sur les
spcifications donnes plus haut pour modliser chaque type dinterface.

72

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

Les types de paramtres des oprations de chaque interface reprsenteront les


structures de donnes dfinies par le modle de donnes des ECATNets qui est un
formalisme algbrique (spcifications algbriques de types abstrait de donnes). Le rsultat
final de cette dmarche est un modle ECATNets modlisant une application base de
composants.
3.2 Gnration des rgles de rcriture
Ce qui caractrise les ECATNets des autres types de rseaux de Petri, est que leurs
smantique est donne en terme de la logique de rcriture pour dcrire le comportement
dynamique des systmes modliss. Cette logique consiste en un ensemble daxiomes sous
la forme de rgles de rcriture et un ensemble de rgles dinfrence. Avec cette logique, le
comportement du systme peut tre expliqu par un raisonnement formel.
Pour pouvoir raisonner correctement sur le systme en conception, modlis par le
biais des notations bases sur le formalisme des ECATNets, la phase suivante de
lapproche suivre consiste en la gnration des rgles de rcriture spcifique au modle
ECATNet construit dans la phase antrieure. Pour chaque composant dans le modle il faut
identifier ses transitions, et appliquer ensuite pour chaque transition la mtargle
approprie (section 5.4 du chapitre 2) pour gnrer la rgle de rcriture associe.
3.3 Vrification du systme
Dans cette phase le concepteur du systme doit prciser tout dabord les proprits
vrifi. Ces proprits permettent danalyser un aspect comportemental du systme
modlis. La vrification se fait travers une spcification excutable crite en langage
Maude qui inclut dans son corps les rgles de rcritures gnres partir du modle
ECATNet du systme en cours de spcification. Cette spcification permet de vrifier
formellement le comportement dynamique du systme modlis. Lapport de la
vrification formelle est significatif en particulier dans les premires phases du processus
de dveloppement logiciel. Elle permet dliminer trs tt dans ce processus les erreurs qui
peuvent se produire dans la spcification des besoins, et de rsoudre les inconsistances
dcouvertes vitant ainsi leurs propagations durant tous le cycle de dveloppement.
Lusage des ECATNets regroupe la fois, lavantage dune reprsentation graphique
simple qui accrot la lisibilit et facilite la comprhension des modles tel est le cas pour
tous les types des rseaux de Petri, et dtient la spcificit de possder lavantage de
pouvoir vrifier formellement des proprits via une spcification en logique de rcriture.
Cette dernire possde un langage formel trs puissant qui limplmente, permettant ainsi
de fournir une spcification excutable du systme. Cest le langage est Maude.
La spcification Maude doit contenir deux modules :
1) Un module fonctionnel qui capte laspect statique du systme en dfinissant les types
de donnes et les oprations qui les manipulent. Les donnes dclarer dans ce module

73

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

reprsentent les paramtres faisant partie des signatures des oprations de chaque
interface dans le composant. En dautres termes cest les entres et les sorties de chaque
opration. Le module suivant emprunt de [69] dcrit les oprations de base pour un
ECATNet :
fmod ECATNET is
sorts Place Marking GenericTerm.
op null : -> Marking .
op <_ | _> : place GenericTerm -> Marking .
op __ : Marking Marking -> Marking [assoc comm id: null] .
endfm
Comme il est illustr dans ce code, null est le marquage vide qui implmente llment
identit pour . Lopration <_ | _> permet la construction des marquages lmentaires.
Les deux caractres souligns indiquent la position des paramtres de lopration. Le
premier paramtre est une place, le second est un terme algbrique (un marquage) dans la
place. Lopration qui implmente lopration nest pas dfinit dans ce code.
Lopration __ qui implmente lopration est suffisante tout en se basant sur la notion
de dcomposition. Si une place contient plusieurs termes, par exemple (p, a b c) alors
en peut lcrire sous la forme (p, a) (p, b) (p, c).
2) Un module systme qui capte laspect dynamique en termes de rgles de rcriture.
Dans ce module on inclut les modules fonctionnels dj dfinis, ainsi que les rgles
dfinies dans la deuxime phase.
On utilise le mot cl including pour limportation la plus gnrale de modules. Cette
opration peut galement tre faite on utilisant dautres modes dimportation via
protecting ou extending . Une fois le code est spcifi, la vrification du systme se
fera laide des commandes de Maude rewrite, frewrite, search, show path, etc
Nous prfrons montrer comment cette tache peut tre ralise travers un exemple
qui sera dvelopp dans la section 4 du prsent chapitre.

4. Etude de cas
Nous allons essayer travers deux exemples de montrer en dtails lapplication de
notre approche de modlisation propose dans le cadre dune mthodologie de
dveloppement base composants. Le premier exemple est tir du domaine des interfaces
utilisateurs, il a t prsent dans [67]. Nous avons rutilis cet exemple pour prsenter
lutilisation des notations proposes pour modliser une application base de composants
(assemblage de composants). Nous nous sommes limits prsenter seulement la phase de
spcification du systme dans cet exemple. Le deuxime exemple que nous proposons,
reprsente un systme connu dans la littrature du domaine de gestion des processus mtier
(BPM18). Il modlise le processus de rservation dune agence de voyage. On a effectu
18

Business Process Management

74

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

de lgre modification pour des raisons de simplicit. Dans cet exemple, toutes les tapes
seront prsentes.
4.1 Prsentation de lexemple1
Pour illustrer notre approche pour modliser formellement des logiciels base de
composants, nous prsentons un exemple emprunt de [67]. Dans cet exemple, une simple
application du domaine des interfaces utilisateurs est montre (figure 24) :

PutTextField
PutButton
GetButton
GetTextField

Fig.24 Interface utilisateur de lexemple [67]


Cette application permet lutilisateur de saisir une chane de caractres (texte) dans
une zone ddition de texte PutTextField, et mettre le texte tap dans une mmoire
tampon (buffer) dune capacit inconnue en cliquant sur un bouton PutButton. En
revanche, un autre bouton GetButton permet lutilisateur dobtenir une chane de
caractre partir de la mmoire tampon, et affiche le texte retir dans une autre zone de
texte. Les boutons doivent tre activs ou dsactivs en fonction de ltat de la mmoire
tampon : si le buffer est plein, le bouton PutButton doit tre dsactiv. En revanche, si le
buffer est vide, le bouton GetButton doit tre dsactiv.
Lexemple identifie quatre composants visuels (PutButton, GetButton, PutTexField et
GetTextField) (figure 24), et trois composants non visuels : MyBuffer qui modlise la
mmoire tampon de capacit inconnue, GetAdapter et PutAdapter qui fournissent la
logique ncessaire pour assembler les diffrentes pices.
Dans le travail de [67], larchitecture du systme montrant lassemblage de
composants a t donne en terme dune notation base sur le modle CCM de CORBA en
gardant le vocabulaire utilis par celui-ci. La spcification de chaque composant a t
donne en utilisant le langage CPN-ML, une variante du standard ML. Ce langage ne
supporte pas la notion dinterface. De notre part nous avons utilis le langage de
description dinterface de CORBA lIDL3 pour la spcification des interfaces de chaque
composant. Ce choix est motiv pour sa simplicit et sa clart, en revanche lutilisation
dun autre langage comme Java est possible aussi. Il est noter que la spcification des
composants en IDL3 nest pas incluse comme une tape de notre approche mais elle
constitue le point de dpart de celle-ci dont le concepteur va utiliser durant la modlisation.
75

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

Nous procdons dans ce qui suit la spcification de chaque composant de notre exemple
part.
4.1.1 GetButton
Cest un composant visuel qui prsente une enveloppe de quatre vnements ; trois
vnements Puit (requis) et un vnement Source (offert). La syntaxe en IDL3 pour la
spcification dun vnement Source et un vnement Puit dans un composant est donne
respectivement par les figures 25 et 26 :
Le cas dun broadcast (plusieurs destinataires):
publishes <event_type> <name_identifier>
Le cas dune connexion point point:
emits <event type> <name identifier>

consumes <event_type> <name_identifier>

Fig.25 Syntaxe IDL3 pour un Source

Fig.26 Syntaxe IDL3 pour un Puit

La dclaration dun vnement se fait par le mot cl eventtype. Ce dernier dfinit un


bloc qui contient des champs reprsentant les donnes de lvnement et ventuellement
des oprations qui permettent de manipuler ces donnes.

eventtype EnableEvent
{
public string text
en ;
};

eventtype DisableEvent
{
public string text
dis;;
};

eventtype ClickPEvent
{
public string text
ck ;;
};

eventtype ClickSEvent
{
public string text ;
};
//syntaxe de dclaration dun composant
component <name> [ :<base>][supports<interface>],[,<interface>]
{<attribute declaration>
<port declaration>
}
component GetButton
{
emits ClickSEvent to_GetAdapter; // vnement offert au composant GetAdapter
consumes EnableEvent from_MyBuffer ; //vnement consomm offert par le composant MyBuffer
consumes DisableEvent
from
MyBuffer ;
consumes
EnableEvent
from_MyBuffer
;
consumes ClickPEvent from_MyBuffer ;
};

Fig.27 Spcification du composant GetButton en IDL3

76

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

A partir de cette spcification nous pouvons construire le modle quivalent en


utilisant les notations proposes, en faisant un mapping du modle en IDL vers celui en
ECATNet. Le rsultat est illustr dans la figure 28 :

Enable

Disable

DisableEvent

EnableEvent
dis

en

Disabled

Enabled

ClickSEvent

Ck

dis
en

Clicked
Clicked Signal place

Ready
Ck

ClickPEvent

Click

Fig.28 Modle ECATNet du composant GetButton


Les inscriptions sur les arcs sont des termes algbriques (marquages) reprsentant les
messages envoys via une communication asynchrone par vnement entre les
composants. Ce composant vhicule une chane de caractre Ck par lvnement source
Clicked, et consomme trois chane de caractres dis,en, et Ck respectivement par les
puits dvnements DisableSink, EnableSink, et ClickSink. Selon ltat du buffer
plein ou vide le composant est soit dans un tat actif ou inactif, il reoit sil est actif un
vnement click de souris, ce qui provoque lenvoi dun vnement source vers le
composant GetAdapter comme il est spcifi dans la dclaration du composant. Ce
dernier contient la logique pour extraire un texte du buffer et de le remettre dans la zone de
texte GetTextField. Si le buffer est vide le bouton est signal par un vnement qui sera
consomm et remettra son tat vers inactif. Pour offrir une smantique pour le
comportement interne du composant GetButton nous allons simuler le fonctionnement
interne qui doit tre masqu. La figure 29 montre le comportement dynamique du
composant.
MyBuffer
dis

en
Enable

Disable

dis

en
Enabled

Disabled
en

dis

en>1

Ck

en
Clicked

Ck

GetAdapter

Clicked
Signal place

Ready
Ck
Click

Fig.29 Spcification formelle du comportement du composant GetButton

77

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

La condition additive (en>1) impose sur la transition Clicked modlise la contrainte


de la prsence de deux jetons en dans la place Enabled, pour que la transition qui
reprsente lenvoi dun vnement source Clicked soit franchissable. Le fait de recevoir
un click de souris avec un seul jeton modlise la perte du signal (lvnement est ignor) et
la transition nest pas franchissable. Cela montre bien la puissance des notations
syntaxiques des ECATNets dans la modlisation des communications asynchrones par
vnement.
En comparant les deux types de spcification celle de la figure 27 en IDL3 et celle de
la figure 28 utilisant le formalisme des ECATNets, on remarque que la premire noffre
aucune smantique sur les oprations mais simplement une description de celles-ci. A
linverse celle de la figure 29 offre une smantique formelle des oprations fournies par le
composant. Les pr / post conditions prcisant les contraintes dexcution de chacune
delles sont bien spcifies.
4.1.2 PutButton
Ce composant est la copie identique du composant GetButton. Il reprsente une
instance du mme type de composant, lexception de lvnement source quil met vers
le composant PutAdapter. Pour cela, nous prsenterons seulement la dclaration du
composant (figure 30) :
component PutButton
{
emits ClickSEvent to_PutAdapter ; //vnement offert au composant PutAdapter
consumes EnableEvent from_MyBuffer ; //vnement consomm offert par le composant MyBuffer
consumes DisableEvent from_MyBuffer ;
consumes ClickPEvent from_MyBuffer ;
}

Fig.30 Spcification du composant PutButton en IDL3


Le composant PutAdapter contient la logique pour extraire une chane de caractre de
la zone de texte PutTextField puis de la remettre dans la mmoire tampon. Si ce dernier
est plein le bouton est signal par un vnement qui sera consomm est remettra son tat
vers inactif.
4.1.3 MyBuffer
Ce composant non visuel expose quatre sources dvnements et deux services offerts.
Il modlise une mmoire tampon. Dans notre cas on considre quil est de capacit N, il
peut tre dans deux tats plein ou vide. La dfinition dune facette se fait par le mot cl
provides (figure 31). Sa spcification est donne dans la figure 32 :

78

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets


provides <Interface > <name_identifier>

Fig.31 Syntaxe IDL3 pour une facette


eventtype NotFull
{
public string Nful ;
}

eventtype Full
{
public string ful ;
}

eventtype empty
{
public string em ;
}

eventtype Notempty
{
public string Nem ;
}
interface Buffer
{
void get (out string text) ; //service offert au composant GetAdapter
void put (in string text, out string text) ;// service offert au composant PutAdapter
}
component MyBuffer supports Buffer
{
provides Buffer buf ; //interface fournit a GetAdapter et PutAdapter
emits NotFull to_PutButton ; //vnement offert au composant PutAdapter
emits Full to_ PutButton ; //vnement consomm offert par le composant MyBuffer
emits empty to_GetButton ;
emits Notempty to_ GetButton ;
}

Fig.32 Spcification du composant MyBuffer en IDL3


On remarque bien que ce composant communique de manire asynchrone avec deux
composants, PutButton et GetButton les notifiant de son tat lors dune extraction ou
insertion dun message. Cela est ralis via les vnements sources quil met. Les
conditions de son fonctionnement napparaissent pas dans la spcification fournie. Lorsque
par exemple le buffer est rempli par linsertion dun message et quaucune place nest vide,
le buffer notifie les deux boutons. PutButton par lvnement Full indiquant quil est
plein et quil ne peut pas recevoir des messages ce qui remettra son tat vers inactif.
GetButton par lvnement NotEmpty signalant quil y a une place vide et qui peut
contenir un message ce qui remettra son tat vers actif.
Le composant offre aussi une interface Buffer dfinit par deux oprations qui
constituent des services offerts par le composant lui permettant de jouer un rle prcis. Ces
derniers reprsentent des services requis par les composants PutAdapter et GetAdapter.
Le premier fait usage de lopration put, celle-ci permet le dpt dun message dans la
mmoire tampon. Le second invoque lopration get pour extraire un message de la
mmoire tampon. La dfinition dinterfaces de type Facette et Rceptacle permet une
communication synchrone par invocation de mthode o lappelant et lappel agissent
selon le modle client/serveur. Le client demande le service et se met en tat de blocage,
jusqu ce que le fournisseur du service (serveur) lui renvoi le rsultat. Le modle

79

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

ECATNet spcifique au composant MyBuffer est donn dans la figure 33 aprs un


mapping partir de la spcification fournie plut haut :

GetRequest
Ack
PutResult

Inv

Get

Put

put () ;

get () ;
S
S
PutRequest

GetResult

NotFull

NotFull
en
NotFull
Signal place

Full
dis

NotEmpty
Signal place

Empty
Signal place

Full
Signal place

NotEmpty

NotEmpty
en

Empty
dis

Fig.33 Modle ECATNet du composant MyBuffer


La smantique du comportement dynamique du composant est spcifie formellement
dans la figure 34. La spcification du comportement interne des composants est donne
dans le but dune vrification du systme suivant lapproche propose.
GetRequest
Ack
Ack
PutResult

PutAdapter

Cp>0
S

Cp

Cp

Put

Capacity
(Cp, S)

eg
(Cp, S)

EndPut

GetAdapter
S

ep

PutRequest

Inv

Cp<N

(Cp, S)
Text

Get

Inv

GetResult

EndGet

ep

eg
ep

eg
Cp >0

NotFull
en

(Cp, S)
(Cp, S)
Cp =0
dis

NotFull
Full
Signal place Signal place
en

(Cp, S)

Cp = N

Full

Cp < N

dis Empty

dis

PutButton

en
NotEmpty
Signal place

Empty
Signal place

dis

NotEmpty

en

GetButton

Fig.34 Spcification formelle du comportement du composant MyBuffer


Nous avons effectu une lgre modification sur la modlisation du composant
MyBuffer par rapport lexemple dorigine de tel sorte il pourra contenir N message en
vue dexprimer plus de paralllisme dans notre modle. La variable N dans le modle cidessus reprsente la capacit du buffer, Cp est le nombre de places vides qui peut avoir
initialement une valeur infrieur ou gale N contenue dans la place Capacity. Le terme
algbrique compos (Cp, S) nous indique la prsence dune chane de caractre Savec
ltat courant du buffer en nombre de places vides. La prsence dun jeton de ce type dans
la place text permettra au buffer de dcider sur le comportement suivre, activer ou

80

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

dsactiver les composants PutButton et GetButton. Les places EndPut et EndGet


indiquent respectivement la fin dune opration dinsertion et dextraction de messages.
4.1.4 PutTextField
Cest un composant visuel qui permet la saisie dune chane de caractre. Il offre une
enveloppe constitue dune facette et dun vnement Puit. Sa spcification est donne
dans la figure 35 :
eventtype KeyPressed
{
public string KeyPr ;
}
interface GetText
{
void get (out string text) ; // service fournis au composant PutAdapter
}
component PutTextField supports Text
{
provides GetText My_GetText ; //interface fournit au composant PutAdapter
consumes KeyPressed id_keypressed; //vnement consomm par frappe de clavier
}

Fig.35 Spcification du composant PutTextField en IDL3


Le mapping entre cette spcification et celle propose nous donne le modle ECATNet
de la figure 36 :
GetRequest
Get

Inv

GetResult
Text
S

Keypressed

Fig.36 Modle ECATNet du composant PutTextField


Ce composant consomme un vnement Puit suite une frappe sur le clavier ce qui
fait vhicul un caractre vers la zone de texte. Il offre ventuellement un service a utilis
par le composant non visuel PutAdapter pour insrer la chane de caractre saisie dans la
zone de texte dans la mmoire tampon. Lopration de dpt dun message ralis par
PutAdapter ne se lancera que si ce dernier a t notifi par le composant PutButton via
une source dvnement, comme il a t montr dans sa spcification. La figure 37 montre
le comportement dynamique du composant.

81

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

GetRequest
Get

Inv

Inv

PutAdapter

S
S
GetResult
Text
S
Keypressed

Fig.37 Spcification formelle du comportement du composant PutTextField


4.1.5 GetTextField
Ce composant visuel possde un service fournir pour le composant GetAdapter. Il
modlise une zone de texte pour afficher le texte reu du buffer. La spcification en IDL3
est donne dans la figure 38 :
interface PutText
{
void put (in string text) ; // service fournis au composant PutAdapter
}
component GetTextField supports Text
{
provides PutText My_PutText ; //interface fournit au composant GetAdapter
}

Fig.38 Spcification du composant GetTextField en IDL3


Le modle ECATNet quivalent (figure 39) :
PutRequest
S
S
Put
Ack
PutResult

Fig.39 Modle ECATNet du composant GetTextField


En la prsence dun message dans le buffer, le composant GetAdapter le fait
rcuprer suite un click du bouton GetButton et le dpose dans la zone de texte
reprsent par GetTextField en invoquant lopration put fournie par linterface
PutText. Cette dynamique est exprime dans la figure 40 :

82

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets


PutRequest
S
S
S

GetAdapter

Put
Ack

Ack

Text

PutResult

Fig.40 Spcification formelle du comportement du composant PutTextField


4.1.6 PutAdapter et GetAdapter
Ces deux composants non visuels reprsentent deux instances identiques du mme
type de composant. Leurs rles sont dadapter les vnements en provenance des boutons
aux services fournis par le buffer et les zones de texte. Le mapping dun service requis
(Rceptacle) est montr travers la modlisation de ces composants. La spcification en
IDL3 des deux composants (figure 42, 43). La syntaxe pour dfinir un Rceptacle (figure
41). On utilise le mot cl uses.
uses <Interface > <name_identifier>

Fig.41 Syntaxe IDL3 pour une facette


eventtype PerformGet
{
public string PerGt ;
}
component GetAdapter
{
uses PutText id_PutText ; //interface requise offerte par GetTextField
uses Buffer id_Buffer; // interface requise offerte par MyBuffer
consumes PerformGet from_GetButton; //vnement offert par GetButton
}

Fig.42 Spcification du composant GetAdapter en IDL3


eventtype PerformPut
{
public string PerPt ;
}
component PutAdapter
{
uses GetText id_PutText ; //interface requise offerte par PutTextField
uses Buffer id_Buffer; // interface requise offerte par MyBuffer
consumes PerformPut from_PutButton; //vnement offert par PutButton
}

Fig.43 Spcification du composant PutAdapter en IDL3


Pour modliser une interface requise, nous devons voir les oprations dclares dans
sa spcification. Par exemple, linterface buffer contient deux services offerts reprsents
par les oprations get() pour le composant GetAdapter et put() pour le composant
PutAdapter. Ensuite, reprsenter chaque service requis par la notation propose. La figure
44 est le rsultat de la modlisation.
83

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

SGetInv

SPutInv
Ck

W
Wait

Wait
W

Ack

W
S

S
EPutInv

EGetInv

EPutInv

Ready

Ready

Ck

Wait
W

Wait

Wait

Text
S

Wait
W

EGetInv

Ack

Ck

Ck
W

SPutInv

SGetInv

Ck
PerformPut

PerformGet

(a)

(b)

Fig.44 Modle ECATNet : (a) GetAdapter, (b) PutAdapter


Le composant PutAdapter soccupe dextraire une chane de caractre de la zone de
texte puis de la dpose dans le buffer en invoquant successivement les oprations get() de
PutTextFiels et put() de MyBuffer. De mme, GetAdapter rcupre le texte dpos
partir du buffer puis le remet dans la zone de texte GetTextField en invoquant
successivement les oprations get() de MyBuffer et put() de GetTextField. La figure 45
illustre ce comportement.
SGetInv
AckReceived

Ck

Inv

Ack
W

PutTextField

Wait
S

SPutInv
Ack

MyBuffer

Wait
W

Text
S

EPutInv

EGetInv
Ready
Ck

Ck

PerformPut

(a)

PutButton
SGetInv

SPutInv

Inv

Ck

S
W

MyBuffer

Wait
W

Text

GetTextField

Wait
AckReceived

Ack

Ack

EPutInv

EGetInv
Ck

Ready

(b)

PerformGet
Ck

GetButton

Fig.45 Spcification formelle du comportement du composant :


(a) PutAdapter, (b) GetAdapter
84

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

Lassemblage des composants ECATNets est maintenant vident. Une vue externe
de chaque composant de lapplication de notre exemple et leur assemblage est
formellement spcifie par notre approche dans la figure 46.
PutAdapter

PutTextField

SGetInv
GetRequest
Ck
Inv
Get Inv
S
S
GetResult
Text

Wait

Wait

S
EGetInv

Inv

Get

Wait
W

Full
dis

Ck
NotFull
Signal place
PerformPut
Enable

Ack

NotEmpty
Signal place

Put
Ack

EPutInv

Ready

Ck

PerformGet

en

Disable

Disable

Enable
Ck

en

Ck

dis

Enabled
Ck
Clicked
Signal place

Clicked

dis
Disabled

en

en
Enabled

Disabled

en

dis

dis

Ck
en

Ck

Clicked

Ck

Clicked
Signal place

Ready
Ck

Ready

Click

Click

GetButton

PutButton

Fig.46 Assemblage formel des composants


Aprs avoir reprsent la spcification formelle des connexions entre les interfaces de
composants en utilisant les ECATNets, le dtail du comportement interne de chaque
composant dans lassemblage est donn par la figure 47. Celle-ci illustre bien et offre une
smantique formelle du comportement de tout le systme base de composants. Le
droulement de lexcution de ce systme se fait on supposant un tat initial. Le choix de
cet tat est arbitraire ; nous pouvons commencer par exemple avec le composant
PutButton inactif, un message dans le composant MyBuffer, et GetButton actif. La
place Enabled doit contenir un jeton en.
Cest ainsi que la phase de spcification du systme est acheve, et lapplication
constitue dun assemblage de composants a pt tre modlise.

85

S
S

Wait
W

EGetInv

dis

dis

Wait
Text

en

Empty
Signal place

Full
Signal place

en

Empty
dis

NotEmpty

PutRequest
S

Ck

GetResult

NotFull
en

S
PutRequest

EPutInv

SPutInv
Ck

Inv

S
S

Ready

Keypressed

Wait
W

SGetInv
GetRequest
Ack
Put
PutResult

GetTextField

GetAdapter

SPutInv
Ack

Ack

MyBuffer

Ack
PutResult

PutTextField

PutAdapter

MyBuffer

GetRequest

Inv

Get Inv

AckReceived

Ck

Wait

S
S

Ack
PutResult

W
S
EPutInv

EGetInv
Text

Cp

Cp

Put
Cp>0

Text

(Cp, S)

Keypressed

ep

eg

NotFull
Signal place

en

Clicked
Signal place

Clicked

en
NotEmpty
Signal place

Disable

Disable

Ck

en
Enable

dis

en
Enabled

Disabled

en

en>1

NotEmpty

Cp <

dis

Disabled

en

Ck

en

dis

dis

Ck
en>1

en

Ck

Clicked

Ck

Ready

PerformGet

Empty
Signal place

dis

Enabled

EPutInv
Ck

dis Empty

dis

en
Enable

(Cp, S)

Cp =

dis Full
Full
Signal place

Clicked
Signal place

Ready
Ck

Ready

Click

Click

PutButton

GetButton

Fig.47 spcification comportementale formelle de lassemblage de composants

86

Ack

Ack

(Cp, S)
Cp =0

en

Ck

(Cp, S)

Cp

NotFull

AckReceived

EGetInv

eg

PerformPut

Put
W

Text

EndGet

ep

S
S

Wait

W
S
GetResult

(Cp, S)

W
Wait

ep

EndPut

PutRequest
S

Ck
W

eg

PutRequest

Ready

Inv

Inv

Cp<N

(Cp, S)
Text

Get

Capacity

Ck

SPutInv

GetRequest

Wait

GetResult

Ack
W

SGetInv

SPutInv
Ack

SGetInv

GetTextField

GetAdapter

Ack
PutResult

Text

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

4.2 Prsentation de lexemple 2


A travers cet exemple nous allons examiner une application de rservation de voyage,
qui modlise un processus mtier (Business Process). La description informelle du
processus de lapplication est comme suit [71] :
1) Obtenir litinraire du client.
2) Pour chaque point de litinraire, tenter de rserver avec la socit cible. Plus
prcisment, rserver un vol avec la compagnie arienne, une chambre lhtel.
Ces rservations peuvent tre effectues en parallle.
3) Si toutes les rservations russissent, obtenir le paiement du client et envoyer au
client une confirmation. Processus termin normalement.
4) Si au moins une rservation choue, annuler les rservations effectues et signaler
le problme au client.
Pour un dveloppeur de logiciels, cette liste est interprte comme un algorithme: il
sagit dune squence dtapes avec des conditions, des boucles et un peu de paralllisme.
En effet, un processus soigneusement conu est algorithmique et est souvent reprsent
sous forme de diagramme. La figure 48 reprsente un diagramme dactivit UML
modlisant le processus de rservation de lagence de voyage. Le diagramme inclus la
location de voiture quon a omis dans notre modlisation pour simplifier.

Fig.48 Diagramme dactivit UML du processus de rservation [50]


Nous avons identifi trois composants dans lapplication qui modlise un systme
distribu. Un composant AgenceVoyage qui joue le rle de coordinateur, un composant
ReservVol qui assure la rservation dun vol, et finalement un composant ReservHotel
qui assure la rservation dune chambre dhtel. Les deux derniers composants
reprsentent respectivement des agences de rservation de vols et dhtels. Le client
soumet sa demande via lapplication Web de lagence de voyage qui va invoque le
composant coordinateur. Ce dernier invoque deux services en parallle depuis les
composants ReservVol et ReservHotel. Les interfaces quexpose chaque composant
doivent tre identifies partir par exemple, dune spcification en IDL3, une spcification

87

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

en langage Java, un diagramme de composants UML qui montre les interfaces de chaque
composant, ou mme une description intuitive en langage naturel.
4.2.1 Spcification du systme
A. AgenceVoyage
Ce composant reoit les requtes de rservation de voyages des clients soumises via
lapplication Web de lagence, il peut recevoir plusieurs demandes la fois modlises par
la place ResRequest. Le service est rendu par le biais dune interface fournie par le
composant. Le service est rellement la combinaison du rsultat de deux services invoqus
en parallle (rceptacles) et rendu par les deux autres composants. Les clients sont notifis
du rsultat de lopration de rservation positivement ou ngativement (vnements
sources) par des messages lectroniques. La rponse de ce composant dpend des rsultats
signals par les composants ReservHotel et ReservVol (vnements puits). Le client
fourni dans sa requte un identificateur, la destination de son voyage, et son numro de
carte bancaire ou carte de crdit (ce systme est bien sur pas utilis dans notre pays). Le
composant fera usage de ces paramtres pour formuler des requtes pour les deux autres
composants, en invoquant leurs services SResVInv et SResHInv et en fournissant
lidentificateur et la destination du client comme paramtres. Daprs la description des
fonctionnalits du composant quon a prsent, on pourra donner son modle ECATNet
spcifique (figure 49) :
ResRequest

ResResult

(Id, Des, Ncd)

Ca_Res
Signal Place

W
Wait

SResVoyInv

EResVoyInv

Id

(Id, IdHot,Idvol)
Discard

Cf_Hotel

Payment
(Id, IdVol)

(Id, IdHot)

RHConfirmed
Ca_Hotel

(Id, AckRVoyage)

Cf_Vol

RVConfirmed
Id

Id

RHCancled

Cf_Res
Signal Place

WaitH

(Id, AckH)
W

(Id, Des) WaitV


(Id, Des)
W W

Ca_Vol

RVCancled
(Id, AckV)

EResHInv SResHInv SResVInv EResVInv

Fig.49 Modle ECATNet du composant AgneceVoyage


On a utilis dans cet exemple la notation gnrale pour modliser le service offert par
ce composant, puisquil fait appel dautres services pour accomplir sa tche. Il se met en
tat de blocage jusqu rception dacquittements des composants ReservHotel et
ReservVol disant que lopration de rservation du vol et de lhtel est en cours. A ce
moment la, le composant AgenceVoyage se dbloque et retourne un acquittement au
client pour lui dire que la rservation est en cours modlis par la place ResResult. Dans
88

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

le cas dune rponse positive, le composant reoit deux vnements puits de confirmation
Cf_Hotel et Cf_Vol et met un vnement source de notification du service de
rservation rendu au client, modlis par le franchissement de la transition Payement et le
dpt dun jeton dans la place signal Cf_Res. Dans le cas chant il reoit Ca_Hotel et
Ca_Vol et met un vnement source pour notifi un service non rendu pour le client
reprsent par le franchissement de la transition Discard et le dpt dun jeton dans la
place signal Ca_Res.
Nous allons se restreindre prsenter seulement les modles ECATNets de chaque
composant. Leurs modles spcifiant leurs comportements seront illustrs dans le modle
spcifiant lassemblage des composants, puisquon a montr comment compos les
composants dans le premier exemple.
B. ReservHotel
Cest un composant implment au niveau dune agence de rservation dhtel. Il
assure la rservation dune chambre dhtel pour un client particulier en se basant sur les
paramtres fournis par le composant AgenceVoyage (un identificateur du client et la
destination demande). La demande du service est modlise par la place ResHRequest.
Lacquittement est transmis informant le composant qui a invoqu le service que
lopration est en cours. Le composant consulte une base de donnes pour voir la
disponibilit dune chambre dhtel dans la destination sollicite par le client. Dans le cas
positif, une confirmation est envoye par un vnement source modlis par le
franchissement de la transition SuccessH et le dpt dun jeton dans la place signal
Confirm_H. Le cas ngatif (pas de chambre) est modlis par lenvoi dun vnement
source reprsent par le franchissement de la transition FailH et le dpt dun jeton dans
la place signal Cancel_H.
ResHRequest

ResHResult
(Id, AckH)

Cancel_H
Signal Place

(Id, Des)
ResH

FailH
Id

Confirm_H
Signal Place

(Id, IdHot)
SuccessH

Fig.50 Modle ECATNet du composant ReservHotel


C. ReservVol
Cest un composant implment au niveau dune agence de rservation de vol. Il
assure la rservation dun billet de vol pour un client, dans une compagnie arienne
quelconque qui possde des places vides pour la destination souhait. Linvocation du

89

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

service est modlise par la place ResVRequest ; le franchissement de la transition


ResV constitue le rendement du service acquitt dans la place ResHResult pour le
composant AgenceVoyage. Le composant consulte la aussi la prsence dun place libre
pour un vol quelconque dans une base de donnes. Le comportement de ce composant est
identique celui du composant ReservHotel. En la prsence dune place libre dans un
vol, une confirmation est envoye par un vnement source modlis par le franchissement
de la transition SuccessV et le dpt dun jeton dans la place signal Confirm_V. Le cas
ngatif est modlis par lenvoi dun vnement source reprsent par le franchissement de
la transition FailV et le dpt dun jeton dans la place signal Cancel_V (figure 51).
ResVRequset
(Id, Des)
ResV

ResVResult
(Id, AckV)
FailV
Id

Cancel_V
Signal Place

(Id, IdVol)

SuccessV

Confirm_V
Signal Place

Fig.51 Modle ECATNet du composant ReservVol


La spcification de lassemblage des composants est donne dans la figure 52, et la
smantique du comportement dynamique du systme modlis est reprsente
formellement dans la figure 53.

90

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

Client

AgenceVoyage

ResRequest

ResResult

(Id, Des, Ncd)

SResVoyInv

Ca_Res
Signal Place

(Id, AckRVoyage)

Wait

EResVoyInv

Payment

Discard

(Id, IdHot,Idvol)

Id

Cf_Res
Signal Place

Cf_Hotel

RVConfirmed

RHConfirmed

(Id, IdVol)

(Id, IdHot)

Id

Ca_Hotel

Cf_Vol

RVCancled

RHCancled
WaitH
(Id, AckH)

SResHInv

(Id, AckH)

(Id, AckH)

SResVInv
(Id, Des)
ResHRequest

ResHResult

(Id, AckV)

(Id, Des)
ResVRequset
(Id, Des)
ResV

(Id, Des)
ResH

ResVResult
(Id, AckV)
FailV

FailH
Id

Id

Id

Cancel_V
Signal Place
Id

(Id, IdVol)

(Id, IdHot)

Confirm_H
Signal Place

Ca_Vol

(Id, AckV)

EResVInv

EResHInv

Cancel_H
Signal Place

(Id, Des) WaitV


(Id, Des)
W

Id

(Id, IdHot)
SuccessV

SuccessH

ReservHotel

ReservVol

Fig.52 Assemblage formel des composants

91

(Id, IdVol)

Confirm_V
Signal Place

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

Client

AgenceVoyage (C1)

ResRequest

(Id, Des, Ncd)

Id

(Id, Ncd)

(Id, Des) InfoClient

Fail
Id

Tc6

(Id, IdHot,Idvol)

(Id, IdHot)

(Id, Des)

Id

Payment

(Id, AckV)

VFail

Id

EResVoyInv

Tc8

(Id, Ncd)
Discard

(Id, AckRVoyage)

Wait

SResVoyInv

Ca_Res
Signal Place

ResResult

Tc5

7
Cf_Res
Signal Place

Requests
HFail

Id

17

(Id, Des)

Tc7

(Id, IdVol)

Id

Id

Id

Id
HVFail

Cf_Hotel

RHConfirmed

Tc1 (Id, IdHot)

(Id, IdHot)

(Id, AckH)

12

(Id, AckH)

Tc2

Id

(Id, Des)

10

FailH

Rooms 3

Confirm_H
Signal Place

(Id, IdHot)
SuccessH

ResVRequset

(Id, Des)

4 StateH

StateV 4

ResVResult
(Id, AckV)

(Id,Des)

Tc9

Id

(Id, IdHot)

(Id, AckV)

(Id, Des)
ResV

(Id, Des)

Tc10

Ca_Vol

EResVInv

FailV

(Id,Des)

Tc4

(Id, AckV)

(Id, Des)

ResHRequest

(Id, Des)
ResH

(Id, AckH)

Id

SResVInv
(Id, Des)

15

Tc11

Tc11
SResHInv

ResHResult

Id

RVCancled

Tc3

11

WaitV

(Id, AckH)

(Id, IdVol)

(Id, AckV)
(Id, AckV)

(Id, Des)

WaitH

16

EResHInv

Id

14

13

Cf_Vol

(Id, IdVol)

Invoke

(Id, AckH)

Cancel_H
Signal Place

AckVol

AckHot

RHCancled

Ca_Hotel

RVConfirmed

(Id, AckH)

(Id, IdVol)

(Id,Des)
SuccessV

ReservHotel (C3)

Id

Tickets
Tck

(Id,Des)

Cancel_V
Signal Place

(Id, IdVol)

Confirm_V
Signal Place

ReservVol (C2)

Fig.53 Spcification comportementale formelle de lassemblage de composants

92

CHAPITRE III

Modlisation des logiciels base de composants avec les ECATNets

Le modle donn dans la figure 53 modlise les requtes du service de rservation de


voyages de plusieurs clients en mme temps. Celles-ci sont reprsentes par la prsence de
jetons <Id,Des,Ncd> dans la place ResRequest ce qui provoque le dclanchement de
lopration de rservation modlise par le franchissement de la transition SResVInv. Le
composant extrait ensuite les informations de chaque client et les stockent dans une base de
donnes reprsente par la place InfoClient, puis invoque en parallle les deux services
de rservation dhtel et de vol et se met en tat de blocage en attente du rsultat.
Grce au formalisme des ECATNets on a pu exprimer le vrai paralllisme dans le
franchissement des deux transitions SResVInv et SResHInv qui modlise les services
requis par le composant AgenceVoyage. Cela est exprim smantiquement par la
mtargle (R2' ) aborde dans le chapitre 2 (section 5.3, cas 2). La prsence dun jeton (Id,
Des) dans la place Invoke suffira pour excuter les deux transitions en parallle est
dinvoqu les services de rservation de lhtel et de vol. La prsence de jetons (Id, Des)
dans les places ResHRequest et ResVRequest dclanche le processus de rservation de
vol et de lhtel par le franchissement des transitions ResV et ResH. Le composant
AgenceVoyage est acquitt via les places ResHResult et ResVResult du composant
ReservHotel et ReservVol par deux jetons de termes algbriques composs (Id, AckH)
et (Id, AckV). Le dpt de ces derniers dans les places AckHot et AckVol
respectivement permet le franchissement de la transition EResVoyInv est dbloque le
composant AgenceVoyage. Les clients sont acquitts par des messages leurs indiquant
que leurs requtes sont en cours, cela est modlis par le dpt des jetons dans la place
ResResult.
Paralllement et indpendamment, les composants ReservHotel et ReservVol
consulte la disponibilit de chambres dhtel et de place vide dans un vol dans leurs bases
de donnes modlises respectivement par les places Rooms et Tickets. Suite la
rception dvnements sources de confirmation, le composant AgenceVoyage fait le
payement partir des informations pralablement stockes sur les clients, puis notifie les
clients par des messages lectroniques. Le cas chant, i.e. la rception dvnements
sources dannulation est modlis par labsence de jetons dans les places Rooms et
Tickets. Le comportement du composant AgenceVoyage qui en rsulte est lannulation
du service de rservation de voyage, par lenvoi dun vnement source reprsent par la
transition Discard et la place Ca_Res. Ce dernier vhicule un message au client
concern parmi ceux qui ont soumis des demandes de rservation pour laviser que le
service na pas pu aboutir.
Les conditions de transitions (TC) on t ajout pour assur que seules les requtes de
clients qui ont t traites et acquittes par les composants ReservHotel et ReservVol
peuvent tre traites par le composant AgenceVoyage. De cette faon on pourra
modliser correctement un nombre important de demandes de clients de manire trs
compacte. Le modle de donnes du formalisme des ECATNets qui est un formalisme
algbrique permet aussi de dfinir des fonctions et enrichir la smantique du modle. head
(param1, param2) est une fonction qui retourne le premier paramtre, et permettra ainsi de
93

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
comparer les identificateurs de clients ayant des demandes acquitts et traits pour pouvoir
par la suite les notifis.

Tc1: If (head(Id, IdHot) = head(Id, AckH))


Tc2: If (Id = head(Id, AckH))
Tc3: If (head(Id, IdVol) = head(Id,AckV))
Tc4: If (Id = head(Id, AckV))
Tc5: If (head(Id, IdHot) = head(Id, IdVol) and head (Id, IdHot) = head(Id, Ncd))
Tc6: If (Id= head(Id, IdHot))
Tc7: If (Id= head(Id, IdVol))
Tc8: If (head(Id, AckV) = head(Id, AckH) and head (Id, AckV) = head(Id, Des))
Tc9: If (M(Tickets) )
Tc10: If (M(Rooms) )
Tc11: If (M(Invoke) <Id, Des>)
head (param1,param2): une fonction qui retourne le premier paramtre.
4.2.2 Gnration des rgles de rcriture
Cette phase consiste exprim le comportement dynamique du systme et capturer le
paralllisme inhrent dans les composants distribus. Cela est spcifi en termes de rgles
de rcritures gnres par lapplication des mtargles aborde dans le deuxime chapitre.

Les rgles de rcriture


[SResVoyInv] :(ResRequest,<Id,Des, Ncd>) (InfoClient,<Id, Ncd>) (Invoke,<Id, Des>)
(Wait,W) (Requests,<Id, Des>) *R1*
[EResVoyInv]:(AckHot,<Id,AckH>)(AckVol,<Id,AckV>)(Requests,<Id,Des>)

(Wait,W)
(ResResult,<Id,AckRVoyage>)(AckHot,<Id,AckH>)(AckVol,<Id,AckV>)
if [(head(Id, AckV)= head(Id, AckH) and head (Id, AckV)=head(Id, Des))] true.
*R1 et R2 et R6*
[Discard]: (Fail, Id) (Ca_Res, Id) *R1*
[Payement]:(InfoClient,<Id,Ncd>)(RVConfirmed,<Id,IdVol>)
(RHConfirmed,<Id,IdHot>)(Cf_Res,<Id, IdHot, IdVol>)

if [(head(Id, IdHot) = head(Id, IdVol) and head (Id, IdHot) = head(Id, Ncd)) ] true. *R1 et R6*
[VFail]: (RHConfirmed,<Id, IdHot>) (RVCancled, Id) (Fail, Id)

if [(Id= head(Id, IdHot))] true . *R1 et R6*


[HFail]: (RVConfirmed,<Id, IdVol>) (RHCancled, Id) (Fail, Id)

if [(Id= head(Id, IdVol))] true . *R1 et R6*


[HVFail]: (RVCancled,Id) (RHCancled, Id) (Fail, Id) *R1*
[Cf_Hotel]:(AckHot,<Id,

AckH>) (Confirm_H,<Id,

IdHot>) (AckHot,<Id,

AckH>)

(RHConfirmed,<Id,IdHot>) if [(head(Id, IdHot) = head(Id, AckH))] true. *R1, R2 et R6*

94

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
[Ca_Hotel]: (AckHot,<Id, AckH>) (Cancel_H, Id) (AckHot,<Id, AckH>) (RHCancled, Id)
if [(Id = head(Id, AckH))] true. *R1, R2 et R6*
[Cf_Vol]: (AckVol,<Id, AckV>) (Confirm_V,<Id, IdVol>) (AckVol,<Id, AckV>)
(RVConfirmed,<Id, IdVol>)
if [(head(Id, IdVol) = head(Id,AckV))] *R1, R2 et R6*
[Ca_Vol]: (AckVol,<Id, AckV>) (Confirm_V,<Id, IdVol>) (AckVol,<Id, AckV>)
(RVCancled, Id) if (Id = head(Id, AckV)) *R1, R2 et R6*
[SResVInv]:(Invoke, )(WaitV,W)(ResVRequest,<Id, Des>) if (M(Invoke)<Id,Des>)*R2*
[SResHInv]:(Invoke, )(WaitH,W)(ResHRequest,<Id, Des>) if (M(Invoke)<Id,Des>)*R2*
[EResVInv]: (WaitV, W) (ResVResult,<Id, AckV>) (AckVol,<Id, AckV>) *R1*
[EResHInv]: (WaitH, W) (ResHResult,<Id, AckH>) (AckHot,<Id, AckH>) *R1*
[ResV]: (ResVRequest, <Id, Des>) (ResVResult,<Id, AckV>) (StateV,<Id, Des>) *R1*
[FailV]: (StateV, <Id,Des>) (Tickets, ) (Cancel_V, Id) if (M(Tickets) ) *R5 et R1*
[SuccessV]: (StateV, <Id,Des>) (Tickets, Tck) (Confirm_V, <Id, IdVol>) *R1*
[ResH]: (ResHRequest, <Id, Des>) (ResHResult,<Id, AckH>) (StateH,<Id, Des>) *R1*
[FailH]: (StateH, <Id,Des>) (Rooms, ) (Cancel_H, Id) if (M(Rooms) ) *R5 et R1*
[SuccessH]: (StateH, <Id,Des>) (Rooms, R) (Confirm_H, <Id, IdHot>) *R1*

4.2.3 Vrification du systme


Cette phase consiste en la vrification des proprits spcifies par le concepteur du
systme modlis. Une diversit de proprits peut tre vrifie dans une application base
de composants. Nous avons choisit de prsent les proprits qui nous on sembl les plus
intressantes. Pour raliser la vrification de notre systme prsent dans le deuxime
exemple, nous avons modifi et enrichi le module fonctionnel prsent dans la section 3.3,
avec des oprations supplmentaires (figure 54).
fmod ECATNET is
protecting STRING .
sorts Place Marking TOKENS token elem .
subsort String < Place .
subsort String < elem .
subsort token < TOKENS .
op none : -> elem [ctor] .
op _-_ : elem elem -> elem [ctor comm assoc ] .
op T(_) : elem -> token .
op nill : -> token [ctor] .
op _;_ : token token -> token [ctor comm assoc id: nill] .
op mt : -> Marking [ctor] .
op __ : Marking Marking -> Marking [ctor comm assoc id: mt] .
op <_|_> : Place TOKENS -> Marking .
op init : -> Marking .
endfm

Fig.54 Spcification en Maude du module fonctionnel dun composant ECATNets


Nous avons suivis la notation suivante dans la reprsentation de la sorte place pour
avoir une reprsentation plus lisible de notre spcification et moins encombre : PiCi, ce
qui signifie, la place i du composant i; tel que i N. Nous devons donc numroter les
95

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
composants de notre exemple ainsi que leurs places. Dans notre cas nous avons trois
composants (C1, C2, C3) reprsentant respectivement AgenceVoyage, ReservVol,
ReservHotel. Nous avons reprsent donc laspect statique du systme, il reste
maintenant reprsenter laspect dynamique par un module systme.
mod ECATNET-COMPONENT is
including ECATNET
vars X X1 X2 X3 X4 X5 : TOKENS . vars Id Des Ncd IdHot IdVol Tck R : elem . var M : Marking . var T : String .
rl [SResVoyInv] : < "P17C1" | X4 > < "P1C1" | T( Id - Des - Ncd ) ; X > < "P4C1" | X1 > < "P14C1" | X2 > < "P3C1"
| X3 > => < "P1C1" | X > < "P4C1" | T( Id - Ncd ) ; X1 > < "P14C1" | T( Id - Des ) ; X2 > < "P3C1" | T("W") ; X3 >
< "P17C1" | T( Id - Des ) ; X4 > .
rl [EResVoyInv] : < "P17C1" | T( Id - Des ) ; X2 > < "P12C1" | T( Id - "AckH" ) ; X > < "P13C1" | T( Id - "AckV" ) ;
X1 > < "P3C1" | T("W") ; X3 > < "P2C1" | X4 > => < "P2C1" | T( Id - "AckRVoyage" ) ; X4 >
< "P12C1" | T( Id - "AckH" ) ; X > < "P13C1" | T( Id - "AckV" ) ; X1 > < "P3C1" | X3 > < "P17C1" | X2 > .
rl [VFail] : < "P8C1" | T( Id - IdHot ) ; X > < "P11C1" | T(Id) ; X1 > < "P5C1" | X2 > => < "P5C1" | T(Id) ; X2 >
< "P8C1" | X > < "P11C1" | X1 > .
rl [Discard] : < "P5C1" | T(Id) ; X > < "P6C1" | X1 > => < "P6C1" | T(Id) ; X1 > < "P5C1" | X > .
rl [Payement] : < "P4C1" | T( Id - Ncd ) ; X > < "P9C1" | T( Id - IdVol ) ; X1 > < "P8C1" | T( Id - IdHot ) ; X2 >
< "P7C1" | X3 > => < "P4C1" | X > < "P9C1" | X1 > < "P8C1" | X2 > < "P7C1" | T( Id - IdHot - IdVol ) ; X3 > .
rl [HFail]: < "P9C1" | T( Id - IdVol) ; X > < "P10C1" | T(Id) ; X1 > < "P5C1" | X2 > =>
< "P9C1" | X > < "P10C1" | X1 > < "P5C1" | T(Id) ; X2 > .
rl [HVFail]: < "P11C1" | T(Id) ; X > < "P10C1" | T(Id) ; X1 > < "P5C1" | X2 > => < "P11C1" | X > < "P10C1" | X1 >
< "P5C1" | T(Id) ; X2 > .
rl [Cf_Hotel]: < "P12C1" | T( Id - "AckH" ) ; X > < "P6C3" | T( Id - IdHot ) ; X1 > < "P8C1" | X2 > =>
< "P12C1" | T( Id - "AckH" ) ; X > < "P6C3" | X1 > < "P8C1" | T( Id - IdHot ) ; X2 > .
rl [Ca_Hotel]: < "P12C1" | T( Id - "AckH" ) ; X > < "P5C3" | T(Id) ; X1 > < "P10C1" | X2 > =>
< "P12C1" | T( Id - "AckH" ) ; X > < "P5C3" | X1 > < "P10C1" | T(Id) ; X2 > .
rl [Cf_Vol]: < "P13C1" | T( Id - "AckV" ) ; X > < "P6C2" | T( Id - IdVol ) ; X1 > < "P9C1" | X2 > =>
< "P13C1" | T( Id - "AckV" ) ; X > < "P6C2" | X1 > < "P9C1" | T( Id - IdVol ) ; X2 > .
rl [Ca_Vol]: < "P13C1" | T( Id - "AckV" ) ; X > < "P5C2" | T(Id) ; X1 > < "P11C1" | X2 > =>
< "P13C1" | T( Id - "AckV" ) ; X > < "P5C2" | X1 > < "P11C1" | T(Id) ; X2 > .
rl [SResVInv-SResHInv]: < "P14C1" | T( Id - Des ) ; X > < "P15C1" | X1 > < "P16C1" | X2 > < "P1C2" | X3 >
< "P1C3" | X4 > => < "P14C1" | X > < "P15C1" | T("W") ; X1 > < "P16C1" | T("W") ; X2 >
< "P1C2" | T( Id - Des ) ; X3 > < "P1C3" | T( Id - Des ) ; X4 > .
rl [EResVInv]: < "P15C1" | T("W") ; X > < "P2C2" | T( Id - "AckV" ) ; X1 > < "P13C1" | X2 > =>
< "P15C1" | X > < "P2C2" | X1 > < "P13C1" | T( Id - "AckV" ) ; X2 > .
rl [EResHInv]: < "P16C1" | T("W") ; X > < "P2C3" | T( Id - "AckH" ) ; X1 > < "P12C1" | X2 > =>
< "P16C1" | X > < "P2C3" | X1 > < "P12C1" | T( Id - "AckH" ) ; X2 > .
rl [ResV]: < "P1C2" | T( Id - Des ) ; X > < "P2C2" | X1 > < "P4C2" | X2 > =>
< "P1C2" | X > < "P2C2" | T( Id - "AckV" ) ; X1 > < "P4C2" | T( Id - Des ) ; X2 > .
rl [FailV]: < "P4C2" | T( Id - Des ) ; X > < "P3C2" | nill > < "P5C2" | X1 > => < "P4C2" | X > < "P3C2" | nill >
< "P5C2" | T(Id) ; X1 > .
rl [SuccessV]: < "P4C2" | T( Id - Des ) ; X > < "P3C2" | T(Tck) ; X1 > < "P6C2" | X2 > =>
< "P4C2" | X > < "P3C2" | X1 > < "P6C2" | T( Id - "IdVol" ) ; X2 > .
rl [ResH]: < "P1C3" | T( Id - Des ) ; X > < "P2C3" | X1 > < "P4C3" | X2 > =>
< "P1C3" | X > < "P2C3" | T( Id - "AckH" ) ; X1 > < "P4C3" | T( Id - Des ) ; X2 > .
rl [FailH]: < "P4C3" | T( Id - Des ) ; X > < "P3C3" | nill > < "P5C3" | X1 > => < "P4C3" | X > < "P3C3" | nill >
< "P5C3" | T(Id) ; X1 > .
rl [SuccessH]: < "P4C3" | T( Id - Des ) ; X > < "P3C3" | T(R) ; X1 > < "P6C3" | X2 > =>
< "P4C3" | X > < "P3C3" | X1 > < "P6C3" | T( Id - "IdHot" ) ; X2 > .
eq init = < "P1C1" | T( "id" - "Des" - "Ncd" ) ; T( "id2" - "Des2" - "Ncd2" ) ; T( "id3" - "Des3" - "Ncd3" ) >
< "P3C2" | T("Tck1") ; T("Tck2") > < "P3C3" | T("R1") ; T("R2") > < "P4C1" | nill > < "P14C1" | nill > < "P3C1" | nill
> < "P10C1" | nill > < "P11C1" | nill > < "P12C1" | nill > < "P13C1" | nill > < "P14C1" | nill > < "P15C1" | nill >
< "P16C1" | nill > < "P17C1" | nill > < "P1C2" | nill > < "P1C3" | nill > < "P2C1" | nill > < "P2C2" | nill > < "P2C3" |
nill > < "P4C2" | nill > < "P4C3" | nill > < "P5C1" | nill > < "P5C2" | nill > < "P5C3" | nill > < "P6C1" | nill >
< "P6C2" | nill > < "P6C3" | nill > < "P7C1" | nill > < "P8C1" | nill > < "P9C1" | nill > .
endm

Fig.55 Spcification en Maude du module systme de lapplication

96

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
Ce dernier inclus outre le module fonctionnel dfini plus haut, les rgles de rcriture
gnres partir du modle de composants ECATNets.
Maude offre diffrentes faons dexcuter une spcification tels que :
-

Les commandes Maude rew (rewrite) et frew (frewrite) excute (ou simule) lun des
nombreux comportements partir dun tat initial donn, par lapplication des rgles
de rcriture ltat initial.
Maude fournit une commande de recherche search pour la recherche de tous les
comportements possibles partir dun tat initial donn. Cela se fait par la recherche
des termes qui peuvent tre atteints depuis ltat initial et qui satisfont une condition
donne.
Maude est dot dun modle Checking de logique temporel pour vrifier si tous les
comportements partir dun certain tat initial satisfait une proprit de logique
temporelle.

Nous allons montrer dans ce qui suit comment peut on vrifis des proprits
comportementales du systme quon a modlis, en utilisant le model de spcification
propos plus haut dans ce chapitre. La vrification se fera videmment par la spcification
en Maude reprsente par la figure (56, 57). Nous avons mentionn dans le deuxime
chapitre que le problme datteignabilit consiste vrifi sil existe une squence de
transitions qui transforme M0 (marquage initial) en un marquage M. Nous allons utiliser
cette proprit pour montrer que le systme va rpondre exactement comme prvus suite
la rception de requtes de clients. Considrons ltat initial suivant :
-

Trois demandes de rservations reprsentes dans le modle par trois jetons de type (Id,
Des, Ncd) dans la place P1C1.
Deux billets davion dans les vols dsirs (deux jetons de type (Tck) dans la place
P3C2).
Deux chambres dhtel dans les destinations souhaites (deux jetons de type (R) dans
la place P3C3).
Les autres places resteront vides, elles contiennent donc des marquages nill.

Ltat initial M0 est reprsent en Maude par lquation : eq init = < "P1C1" | T( "id"
- "Des" - "Ncd" ) ; T( "id2" - "Des2" - "Ncd2" ) ; T( "id3" - "Des3" - "Ncd3" ) > < "P3C2" |
T("Tck1") ; T("Tck2") > < "P3C3" | T("R1") ; T("R2") > < "P4C1" | nill > < "P14C1" | nill
> < "P3C1" | nill > < "P10C1" | nill > < "P11C1" | nill > < "P12C1" | nill > < "P13C1" | nill
> < "P14C1" | nill > < "P15C1" | nill > < "P16C1" | nill > < "P17C1" | nill > < "P1C2" | nill
> < "P1C3" | nill > < "P2C1" | nill > < "P2C2" | nill > < "P2C3" | nill > < "P4C2" | nill > <
"P4C3" | nill > < "P5C1" | nill > < "P5C2" | nill > < "P5C3" | nill > < "P6C1" | nill > <
"P6C2" | nill > < "P6C3" | nill > < "P7C1" | nill > < "P8C1" | nill > < "P9C1" | nill > .
Le systme ne peut satisfaire que deux demandes de rservations. Ltat que nous
devons atteindre est videmment, deux rponses de confirmations, une rponse

97

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
dannulation ainsi que trois accuss de rception envoys aux clients qui signifient que
leurs requtes sont en cours. Deux jetons de type (Id, IdHot, Idvol) dans la place P7C1,
un jeton dans la place P6C1 de type (Id), et trois jetons de type (Id - "AckRVoyage")
doivent tre prsent.
Nous avons runis la spcification des deux modules fonctionnel et systme
reprsents respectivement par les figures (54, 55), dans un module appel ECATNETCOMPONENT. Ce dernier est sauvegard dans un fichier nomm ECATNET. Pour
excuter la spcification nous devons tout dabord charger le fichier qui la contient en
utilisant la commande load (figure 56).

Fig.56 Chargement de la spcification par la commande load.

Lexcution de la spcification se fait laide de la commande rew ou frew en


partant de ltat initial init.

Fig.57 Rsultat dexcution de la spcification.


98

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
La commande rew (abrviation de rewrite) excute les rgles qui sappliquent avec
ltat initial init, en substituant la partie gauche de ces rgles par la partie droite. Prenant
par exemple la rgle :

rl [SResVoyInv] : < "P17C1" | X4 > < "P1C1" | T( Id - Des - Ncd ) ; X > < "P4C1" |
X1 > < "P14C1" | X2 > < "P3C1" | X3 > => < "P1C1" | X > < "P4C1" | T( Id - Ncd ) ; X1
> < "P14C1" | T( Id - Des ) ; X2 > < "P3C1" | T("W") ; X3 > < "P17C1" | T( Id - Des ) ;
X4 > .
La partie gauche de cette rgle contient une place initialise qui est P1C1. Maude fait
se quon appel le matching de ltat initial avec cette rgle, est fait les remplacement
suivant : X arbitrairement par T ( "id2" - "Des2" - "Ncd2" ) ; T( "id3" - "Des3" - "Ncd3"
) ; Id : "id" ; Des : "Des" ; Ncd : "Ncd" ; X1, X2, X3, X4 : nill. Le rsultat de
lapplication de la rgle constitue une rcriture et sera comme suit :
< "P17C1" | nill > < "P1C1" | T( "id" - "Des" - "Ncd" ) ; T( "id2" - "Des2" - "Ncd2" ) ;
T( "id3" - "Des3" - "Ncd3" ) > < "P4C1" | nill > < "P14C1" | nill > < "P3C1" | nill > => <
"P1C1" | T( "id2" - "Des2" - "Ncd2" ) ; T( "id3" - "Des3" - "Ncd3" ) > < "P4C1" | T("id" "Ncd" ) ; nill > < "P14C1" | T("id"- "Des") ; nill > < "P3C1" | T("W") ; nill > < "P17C1" |
T( "id"- "Des" ) ; nill >. Et ainsi de suite pour le reste des rgles. Nous remarquons que
Maude a ralis 38 rcriture pour atteindre ltat final M illustr par la figure 57. Nous
avons pu donc, vrifier quil existe un franchissement dune squence de transition qui a
transform le marquage initial M0 en un marquage final M. Pour pouvoir explorer tous
les chemins possibles qui ont men ltat final, et analyser les ventuels comportements
qui peuvent se produire nous pouvons utiliser la puissance de la commande search. La
figure 58 montre le rsultat dexcution de cette commande. Nous avons dmarr avec un
tat initial trs simple init qui est le suivant :
-

Une demande de rservation reprsente dans le modle par un jeton de type (Id, Des,
Ncd) dans la place P1C1.
Un billet davion dans le vol dsir (Un jeton de type (Tck) dans la place P3C2).
Une chambre dhtel dans la destination souhaite (Un jeton de type (R) dans la place
P3C3).
Les autres places resteront vides avec des marquages nill.

Ltat final que lon prvoit atteindre est exprim aprs le signe => de la commande.
Le signe * signifie que lon cherche tous les chemins possibles partir de ltat initial.
La commande a appliqu est comme suit :
search init =>* ( < "P12C1" | T( "id" - "AckH" ) > < "P13C1" | T( "id" - "AckV" ) > <
"P7C1" | T( "id" - "IdHot" - "id" - "IdVol" ) > < "P2C1" | T( "id" - "AckRVoyage" ) >
X:Marking ) .

99

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets
Nous voulons tudier les comportements possibles que le systme peut exhiber. Dans
notre cas le systme montre un seul comportement exprim par la solution 1 (figure 58).

Fig.58 Rsultat dexcution de la commande search.

Pour analyser le chemin emprunter par le systme et voir la squence de rcriture qui
a permis darriver ltat affich, nous utilisons la commande show path en fournissant
ltat 15364. La squence de franchissement emprunter par le systme est reprsente par
la figure 59 :
[SResVoyInv], [SResVInv-SResHInv], [ResV], [EResVInv], [SuccessV], [Cf_Vol],
[ResH], [EResHInv], [EResVoyInv], [SuccessH], [Cf_Hotel], [Payement].

100

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets

Fig.59 Rsultat dexcution de la commande show path.

101

CHAPITRE III Modlisation des logiciels base de composants avec les ECATNets

5. Conclusion
Nous avons prsent dans ce chapitre lapplication de notre approche pour la
modlisation des logiciels base de composants. Cela a t ralis en utilisant deux
exemples diffrents issus de deux pratiques diffrentes. A travers le premier qui est tir du
domaine des interfaces utilisateurs, nous avons montr la manire de spcifier les
composants logiciels ainsi que de leurs assemblages en faisant usage du model de
spcification propos. Lexemple modlise une simple application ralise en assemblant
des composants visuels et non visuels.
Le deuxime exemple modlise un processus mtier dune agence de voyage. On a montr
comment spcifi le comportement dynamique des composants, ainsi que celui de
lassemblage des composants par des rgles de rcritures gnres partir du modle
ECATNet qui modlise le systme entier. On a aussi prsent comment vrifier les
proprits du systme que le concepteur souhaite vrifier, en utilisant le langage Maude.
Nous avons choisi la proprit datteignabilit pour montrer comment analyser et tudier le
comportement du systme. La vrification reprsente la finalit de notre travail de
modlisation.

102

Conclusion gnrale et perspectives

Conclusion gnrale et perspectives


A travers ce mmoire, notre objectif tait de proposer une approche de modlisation
des logiciels base de composants en utilisant les rseaux de Petri. Notre choix a t port
sur les ECATNets (Extended Concurrent Algebraic Term Nets) qui sont considrs comme
une catgorie de rseaux de Petri algbrique de haut niveau. Ce choix est motiv par leurs
capacits de fournir des modles hautement compacts des systmes concurrents et
distribus, grce aux notations syntaxiques riches qui possdent et qui leurs donnent une
puissance dexpression particulire. En outre, ils sont caractriss par une smantique saine
et non ambigu exprime en terme de la logique de rcriture, celle-ci constitue un
Framework logique et smantique particulirement adapt pour la spcification du
comportement dynamique des systmes parallles et distribus. Les logiciels base de
composants sont des systmes connus par leurs paralllismes inhrents, du fait quils sont
essentiellement conus par linterconnexion dun ensemble de composants logiciels
prfabriqus non autonomes qui peuvent tre locales ou distribus. Le dveloppement de
ce genre de systmes suit donc une approche bien adapte connue sous le nom de CBD, ou
le dveloppement bas composants.
Nous avons prsent dans le premier chapitre lvolution des approches de
dveloppements logiciels traditionnelles qui ntaient pas bien adapts pour suivre le cours
de lvolution que les systmes logiciels ont connue. La complexit croissante de ces
derniers a fait que leurs checs taient incontournables. Ensuite, nous avons prsent le
CBD comme une solution base sur la notion de rutilisation pour palier aux problmes
des approches classiques. Son principe est de construire des applications logicielles par
assemblage de briques logicielles prexistant. Le cur de cette approche est le composant,
et toute lingnierie logicielle base de composants (CBSE) est base autour. Nous avons
prsent quelques standards de composants logiciels, et on a mentionn quils sont tous
fonds sur les mmes concepts. Ils offrent et requirent des services dfinis par des
interfaces de leurs environnements externes.
Le deuxime chapitre a t le sujet de dtail de la logique de rcriture et les
ECATNets. Des exemples illustratifs montrant comment ces derniers sont utiliss pour la
modlisation de diffrents types de systmes ont t prsents. Le premier modlise une
cellule de production, et le deuxime modlise la fonction de dbut de transmission dune
station mettrice Ethernet.
Dans le troisime chapitre, nous avons prsent une approche formelle pour la
modlisation des logiciels base de composant qui est ralise en termes de spcifications
formelles des composants individuels et de leurs connexions. Nous avons propos pour
cette fin, une notation base sur le formalisme des ECATNets pour spcifier les diffrents
services dun composant logiciel et fournir une smantique plus riches pour les oprations
dfinissant les interfaces du composant. Nous avons vu que cette approche se divise en
103

Conclusion gnrale et perspectives


trois tapes ; la premire spcifie le systme en cours de conception en utilisant les
notations proposes, et vise fournir un modle ECATNet qui spcifie un assemblage
formel de composants. Le comportement interne de chaque composant est aussi dfinit
dans le modle. On a vu dans la deuxime tape comment gnrer les rgles de rcriture
dfinissant le comportement dynamique de lassemblage de composants, en appliquant les
mtargles des ECATNets. On a vu aussi dans la troisime tape comment vrifier les
proprits souhaites par le concepteur du systme tel que latteignabilit. On peut par
exemple vrifier aussi la proprit de vivacit, ou mme de traiter certains problmes tel
que le problme dincompatibilit dinterfaces. Ce dernier peut tre expliqu par exemple,
par une incompatibilit de paramtres o les paramtres peuvent avoir les mmes noms
mes avec diffrents types. Ou par une incompatibilit dopration o les noms doprations
dans les interfaces composes sont diffrents. La vrification a t ralise par le langage
Maude qui implmente la logique de rcriture. Nous avons montr lapplication de
lapproche sur deux exemples, le premier est du domaine des interfaces utilisateurs alors
que le second est du domaine des processus mtier.
Notre travail offre un modle de spcification formelle dun composant logiciel qui
permet de fournir une smantique plus facile comprendre du comportement. Il fourni
ventuellement plus de dtails sur les interfaces du composant ce qui permet de mieux les
inspecter, et les valuer et par consquent permet des constructions ou des assemblages
non ambigus.
Comme un travail futur et pour la concrtisation d lapproche propose, nous
prvoyons de construire un outil graphique pour la modlisation de logiciels base de
composants avec les ECATNets en utilisant la notation propose. Loutil doit intgrer un
module de translation qui partir du modle gnr, des rgles de rcriture crit en
langage Maude sont automatiquement gnrer pour la vrification formelle de
lassemblage des composants.

104

Rfrences

Rfrences
[1] I. Crnkovic, M. Larsson, Building Reliable Component-based Software Systems,
Artech House, 2002.
[2] M. ODocherty, Object-Oriented Analysis and Design: Understanding System
Development with UML 2.0, John Welly & sons, USA, 2005.
[3]

Nicolas Belloir, Composition conceptuelle base sur la relation Tout-Partie,


Doctorat de luniversit de Pau et des de lAdour, soutenue le 9 dcembre 2004.

[4] Boehm, B. 2000, Spiral Development: Experience, Principles, and Refinements.


Report No. CMU/SEI-2000-SR-008. Spiral Development Workshop, February 9,
2000.Software Engineering Institute, Carnegie-Mellon University, Pittsburgh. PA.
[5] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Process, IEEE Software, vol. 16,
no. 3, pp. 96-102, May/Jun, 1999.
[6] Alfred Strohmeier, CYCLE DE VIE DU LOGICIEL, Laboratoire de Gnie Logiciel Dpartement dInformatique Ecole Polytechnique Fdrale de Lausanne, 13 mars
2000.
[7] Robin Passama, Conception et dveloppement de contrleurs de robots, Une
mthodologie base sur les composants logiciels, Thse prpare au sein du
Laboratoire dInformatique, de Robotique et de Microlectronique de Montpellier,
soutenue le 30 Juin 2006.
[8] X. Cai, M.R. Lyu, K. Wong, Roy Ko, Component-Based Software Engineering:
Technologies, Development Frameworks and Quality Assurance Schemes, in
Proceedings APSEC 2000, Seventh Asia-Pacific Software Engineering Conference,
Singapore, December 2000, pp372-379.
[9] Alan W. Brown, Large-Scale, Component-Based Development, Prentice Hall PTR,
30 Mai 2000.
[10] Z .Stojanovi, A Method for Component-Based and Service-Oriented Software
Systems Engineering, Doctoral Dissertation, Delft University of Technology, The
Netherlands 2005.
[11] Jerry Zeyu Gao H.-S, Jacob Tsao Ye Wu, Testing and Quality Assurance for
Component-Based Software, Artech House, 2003.
[12] Peter Herzum, Oliver -Sims, Business component Factory, A Comprehensive
Overview of Component-Based Development for the Enterprise, Wiley Computer
Publishing 2000.

105

Rfrences
[13] Theo Dirk Meijler and Oscar Nierstrasz, Beyond Objects: Components, In
Cooperative Information Systems: Current Trends and Directions, M.P. Papazoglou,
G. Schlageter (Ed.), Academic Press, Nov., 1997.
[14] Ivica Crnkovic, Component-Based Software EngineeringNew Challenges in
Software Development, Journal of Computing and Information Technology - CIT
11, 2003, 3, 151161.
[15] Ouafa Hachani, Patrons de conception base daspects pour lingnierie des
systmes dinformation par rutilisation, thse de doctorat au sein de luniversit
JOSEPH FOURIER-Grenoble I, soutenue le 4 Juillet 2006.
[16] Hedley Apperly, Ralph Hofman, Steve Latchem, Barry Maybank, Barry McGibbon,
David Piper, Chris Simons, Service- and Component-based Development: Using
Select Perspective and UML, Addison Wesley January 24, 2003.
[17] Jan Bosch Charles Krueger (Eds.), Software Reuse: Methods, Techniques, and
Tools, 8th International Conference, ICSR 2004 Madrid, Spain, July 5-9, 2004,
Proceedings Springer.
[18] Danielle Ribot, Blandine Bongard, Claude Villermain, Development Life-cycle
WITH Reuse, Proceedings of the 1994 ACM symposium on Applied computing,
Arizona, United States, Pages: 70 76.
[19] Philippe RAMADOUR, Modles et langage pour la conception et la manipulation
de composants rutilisables de domaine, thse de doctorat au sein de luniversit
dAix-Marseille III, soutenue le 17 Dcembre 2001.
[20] Luiz Fernando Capretz, Y: A New Component-Based Software Life Cycle Model,
Journal of Computer Science 1 (1): 76-82, 2005.
[21] Kuljit Kaur, Parminder Kaur, Jaspreet Bedi, and Hardeep Singh, Towards a Suitable
and Systematic Approach for Component Based Software Development,
PROCEEDINGS OF WORLD ACADEMY OF SCIENCE, ENGINEERING AND
TECHNOLOGY VOLUME 21 MAY 2007.
[22] Ivica Crnkovic, Stig Larsson and Michel Chaudron, Component-based Development
Process and Component Lifecycle, Journal of Computing and Information
Technology - CIT 13, 2005, 4, 321-327.
[23] Ivica Crnkovic, Brahim Hnich, Torsten Jonsson, and Zeynep Kiziltan, Specification,
Implementation, and Deployment of COMPONENTS, Communications of the
ACM Volume 45 , Issue 10 (October 2002) Pages: 35 40.
[24] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software, Addison Wesley, Reading, MA, 1995.

106

Rfrences
[25] Felix Bachmann, Len Bass, Charles Buhman, Santiago Comella-Dorda,Fred Long,
John Robert, Robert Seacord, Kurt Wallnau, Volume II: Technical Concepts of
Component-Based Software Engineering, 2nd Edition TECHNICAL REPORT,
CMU/SEI-2000-TR-008, ESC-TR-2000-007 May 2000.
[26] Oualid KHAYATI, Modles formels et outils gnriques pour la gestion et la
recherche de composants, Thse de doctorat de linstitut national polytechnique de
Grenoble (INPG), Le 17 dcembre 2005.
[27] Abdelmadjid KETFI, Une approche gnrique pour la reconfiguration dynamique
des applications base de composants logiciels, Thse au sein de lUniversit
Joseph Fourier de Grenoble, soutenue le 10 dcembre 2004.
[28] Barbara PERNICI and al, Conceptual Modelling and Software Components Reuse:
Towards the Unification, In A. Slvberg, S. Brinkkemper, E. Lindencrona (eds.):
Information Systems Engineering: State of the Art and Research Themes. Springer
Verlag, London, 2000.
[29] Ambler S. W, An Introduction to Process Pattern, AmbySoft White paper, 1998.
http://www.Ambysoft.com.
[30] Bertrand Meyer: Applying "Design by Contract", in Computer (IEEE), vol. 25, no.
10, October 1992, pages 40-51.
[31]

Microsoft
Component
object
model
http://www.microsoft.com/com/resources/comdocs.asp.

(COM)

specification,

[32] Humberto CERVANTES, Vers un modle a composants orient services pour


supporter la disponibilit dynamique, Thse au sein de lUniversit Joseph Fourier
de Grenoble, soutenue Le 29 Mars 2004.
[33]

OMG
Business
Application
,http://jeffsutherland.com/oopsla/bowp2.html.

Architecture,

White

Paper

[34] Cory Casanave, Business-Object Architectures and Standards, in Workshop


Report: Business Object Design and Implementation. 10th Annual Conference on
Object-Oriented Programming Systems, Languages, and Applications, Addendum to
the Proceedings, OOPSLA: ACM/SIGPLAN October, 1995.
[35] TADAO MURATA, Petri Nets: Properties, Analysis, and Applications, in
Proceedings of the IEEE, Vol. 77, N80. 4, pages 541-580. April 1989.
[36] Jean Marie PROTH et Xiaolan XIE, Les rseaux de Petri pour la conception et la
gestion des systmes de production, Paris 1995, Edition Masson.
[37] G. Scorletti et G. Binet, Rseaux de Petri, Cours EL401T2, Grard Scorletti, France,
2006.
107

Rfrences
[38] Final Draft International Standard ISO/IEC 15909, High-level Petri Nets - Concepts,
Definitions and Graphical Notation, Version 4.7.1, October 28, 2000.
[39] Guy VIDAL-NAQUET, Annie CHOQUET-GENIET, Rseaux de Ptri et systmes
parallles, Edition ARMAND COLIN, Paris 1992.
[40] J. Padberg, M. Gajewsky and C. Ermel, Refinement versus Verification:
Compatibility of Net InVariants and Stepwise Development of High-Level Petri
Nets, 1997. http://citeseer.ist.psu.edu/cache/papers/cs/1596/http:zSzzSzw3.cs.tuberlin.dezSzcszSzifbzSzTeBerichtzSz97zSzTR97-22.pdf/padberg97refinement.pdf.
[41] Gajewsky, C. Ermel, Transition InVariants in Algebraic High-Level Nets,
http://citeseer.ist.psu.edu/cache/papers/cs/15875/http:zSzzSzuser.cs.tuberlin.dezSz~magdazSzPaperszSzIDPT99.pdf/gajewsky99transition.pdf
[42] C. Ermel, J. Padberg, Formalization of Variables in Algebraic High-Level Nets,
Comparison
of
Different
Approaches
(1998),
http://citeseer.ist.psu.edu/cache/papers/cs/1596/http:zSzzSzw3.cs.tuberlin.dezSzcszSzifbzSzTeBerichtzSz97zSzTR97-19.pdf/ermel98formalization.pdf
[43] Antoine Reilles, Rcriture dans un cadre concurrent, DEA de lInstitut National
Polytechnique de Lorraine, 9 juillet 2003.
[44] Horatiu Cirstea, Calcul de rcriture : fondements et applications, thse de
Doctorat au sein de luniversit Henri Poincar Nancy 1, soutenue le 25 octobre
2000.
[45] Nachum Dershowitz, Jean-Pierre Jouannaud, REWRITE SYSTEMS, chapter 6 of
handbook of theoretical computer science; volume B: Formal Methods and
Semantics, pages 243-320 North Holland Amsterdam, 1990.
[46] Kung-Kiu Lau, Mario Ornaghi, A Formal Approach to Software Component
Specification, In G.T. Leavens D. Giannakopoulou and M. Sitaraman, editors, Proc.
of Specification and Verification of Component-based Systems Workshop at
OOPSLA2001, pages 8896, 2001.
[47] M. Clavel, F. Durn, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer, and C. Talcott.
All About Maude -A High-Performance Logical Framework, volume 4350 of
Lecture Notes in Computer Science. Springer, 2007.
[48] M. Bettaz and M. Maouche, How to specify non determinism and true
concurrency with algebraic term nets, Lecture Notes in Computer Science, Vol.
655, Springer-Verlag, 1993, pp. 164180.
[49] Ian Sommerville, Le gnie logiciel et ses applications, Addison-Wesley, 1988.

108

Rfrences
[50] Michael Havey, Essential Business Process Modelling, OReilly Media, Inc., 2005.
[51] M. Bettaz, K. Djemame, C. Gilles, M. Mackenzie, Performance comparison of high
level algebraic nets distributed simulation protocols, Winter Simulation
Conference, 1996.
[52] N. Aoumeur, K. Barkaoui, and G. Saake, On the Benefits of Rewrite Logic as a
Semantics for Algebraic Petri Nets in Computing Siphons and Traps. In Proc of
the 10th International Conference on Computing and Information (ICCI 2000),
Kuweit, to appear in LNCS, Springer.
[53] Thomas Noll, On coherence properties in term rewriting models of concurrency.
In: Baeten, J.C.M., Mauw, S. (eds.) CONCUR 1999. LNCS, vol. 1664, pp. 478493.
Springer, Heidelberg (1999).
[54] Jos Meseguer, Research Direction in Rewriting Logic, In U. Berger and H.
Schwichtenberg, editor, Computational Logic, NATO, Advanced Study Institute,
Marktoberdorf, Germany, July 29 - August 6, 1997. Springer Verlag, 1998.
[55] Narciso Marti-Oliet and Jos Meseguer, Rewriting Logic as a Logical and Semantic
Framework, In J. Meseguer, editor, Proc. First Intl Workshop on Rewriting Logic
and its Applications, volume 4 in Electronics Notes in Theoretical Computer Science.
Elsevier, 1996.
[56] Jos Meseguer, Rewriting Logic as a semantic Framework for Concurrency: a
Progress Report, In U. Montanari and V. Sassone, editors, Proc. 7th Intern. Conf. on
Concurrency Theory: CONCUR 96, Pisa, August 1996, pages 331-372, 1996. LNCS
1119.
[57] M. Clavel, F. Durn, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer, and J.F.
Quesada, Maude: specification and programming in rewriting logic, SRI
International, June 2001, http://maude.cs.uiuc.edu/papers.
[58] M. Clavel, F. Durn, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer, and C. Talcott.
All About Maude - A High-Performance Logical Framework, volume 4350 of
Lecture Notes in Computer Science. Springer, 2007.
[59] Jos Meseguer, Software Specification and Verification in Rewriting Logic,
Lectures given at the NATO Advanced Study Institute International Summer School,
Marktoberdorf. Germany, 2002. Available from http://maude.cs.uiuc.edu, 2003.
[60] H. Sebih, K. Barkaoui, M. Bettaz, F. Belala et Z. Sahnoun, Towards a Temporal
Logic LTL for the Verification of Rewriting Theories Denoting ECATNets In
1st Intl Workshop on Automated Technology for Verification and Analysis
(ATVA03), Taiwan, 2003.

109

Rfrences
[61] Bettaz M., Maouche M., Soulami M. and Boukebeche M, Using ECATNets for
specifying communication software in the OS1 framework. In Proceedings of
ICCI92, pages -410-413. IEEE, 1992.
[62] M. Bettaz, M. Maouche, K. Barkaoui, Formal Specification of Communication
Protocols with Object-Based ECATNets, Proceedings of EUROMICRO-22,
Prague, Czech Republic, IEEE, pages 492-499,1996.
[63] N. Zeghib, K. Barkaoui, M. Bettaz, Contextual ECATNets Semantics in Terms of
Conditional Rewriting Logic, aiccsa,pp.936-943, IEEE International Conference on
Computer Systems and Applications, 2006.
[64] M. Maouche, M. Bettaz, G. Berthelot and L. Petrucci, Du vrai Paralllisme dans les
Rseaux Algbriques et de son Application dans les Systmes de Production,
Confrence Francophone de Modlisation et Simulation (MOSIM97), Hermes,
1997, pp. 417-424.
[65] M. Bettaz and A. Mehemmel, Modeling and proving of truly concurrent systems
with CATNets, In Proceedings of Euromicro Workshop on Parallel and Distributed
Processing, pages 265-272, IEEE, 1993.
[66] P .T. Cox, B .Song, A Formal Model for Component-Based Software, IEEE 2001
Symposium on Human Centric Computing Languages and Environments
(HCC01), 2001.
[67] R. Bastide and E. Barboni, Software Components: a Formal Semantics Based on
Coloured Petri Nets, Electronic Notes in Theoretical Computer Science 160 (2006)
5773, ScienceDirect.
[68] Ramamoorthy, C. V. and G. S. Ho, Performance Evaluation of Asynchronous
Concurrent systems Using Petri Nets, IEEE Trans. Software Eng., 1980, pp. 440449.
[69] N. Boudiaf, and A. Chaoui, Double Reduction of Ada-ECATNet Representation
using Rewriting Logic, proceedings of world academy of science, engineering and
technology volume 15 october 2006 pages 278/ 284.

110