1 Introduction 2 Présentation rapide du mod`ele - ResearchGate

¨
¢¡
Conférence Francophone de MOdélisation et SIMulation - MOSIM’06 - du £ au ¤ avril ¥§¦¢¦ - Rabat - Maroc
Modélisation, Optimisation et Simulation des Systèmes : Défis et Opportunités ©
Vérification d’assemblage de composants logiciels
Expérimentations avec MEC
Pascal André, Gilles Ardourel, Christian Attiogbé
LINA FRE CNRS 2729
2, rue de la Houssinière, B.P.92208
F-44322 Nantes Cedex 3, France
pascal.andre@univ-nantes.fr
RÉSUMÉ : Le développement à grande échelle de logiciel par assemblage de composants fait actuellement l’objet de
nombreux travaux. Une question cruciale qui se pose au développeur est celle de savoir si un assemblage est correct
ou non. Dans cet article, nous contribuons à répondre à cette question. Nous présentons succinctement un modèle
formel pour la définition de composants et leur composition, puis nous étudions les moyens de vérifier la conformité des
interactions entre composants en nous basant sur les systèmes de transitions qui décrivent les services des composants.
Des expérimentations pratiques sont menées en utilisant MEC.
MOTS-CLÉS : Composants, Services, Spécification formelle, Conformité d’interaction, MEC
1 Introduction
Le développement de logiciel par assemblage de composants
fait actuellement l’objet de nombreux travaux. Le
développement logiciel à base de composants (Szyperski
1997, Medvidovic & Taylor 2000, Bergner, Rausch,
Sihling, Vilbig & Broy 2000, Heineman & Councill
2001) consiste à assembler des composants logiciels existants
pour construire des systèmes logiciels complexes.
Cet assemblage peut être étudié à différents niveaux
d’abstraction, de la conception (les architectures logicielles
ADL (Shaw & Garlan 1996)) à l’implantation (architectures
CORBA, J2EE ou .NET). Alors que la plupart
des modèles à composants, notamment ceux précités,
se situent au niveau implantation et considèrent des
composants avec leur comportement, des connecteurs, et
des services réduits à des méthodes, nous considérons un
modèle abstrait, simple avec uniquement des composants
et des services. Les comportements sont associés aux services.
Cela confère une réutilisabilité plus grande aux
composants. De plus on ne contraint pas la prise en
compte des données dans les interactions.
Nos travaux se situent donc à un niveau abstrait, en
ce sens qu’aucun modèle d’implantation n’est privilégié.
Néanmoins, les descriptions de composants et de services
sont suffisamment précises et formelles pour établir des
critères de vérification de propriétés d’assemblage. La
question cruciale qui se pose au développeur est de savoir
si un assemblage est correct ou non. Autrement dit, peuton
détecter avant de développer concrètement le logiciel
en vue, des erreurs dans l’assemblage de composants proposé.
Dans cet article, nous apportons des réponses à cette
question en proposant un modèle formel qui nous sert à
décrire les composants, leurs services et les assemblages
et en étudiant principalement la conformité d’interaction
entre les services offerts et requis pour détecter des incompatibilités
comportementales. Afin d’étudier les propriétés
de notre modèle sans développer, pour l’instant,
d’outils d’analyse spécifiques, nous expérimentons la traduction
des services, plus précisément de leur description
comportementale, dans différents formalismes, outillés,
de modélisation dynamique des systèmes.
La présentation du modèle à composants est faite à travers
un exemple concret dans la section 2. Dans la section
3, nous étudions les moyens de vérifier la conformité
des interactions entre composants en nous basant sur les
systèmes de transitions qui décrivent les services des composants.
Une des voies consiste à utiliser un outil de
vérification de systèmes de transition. Nous avons choisi
MEC, un model-checker simple, pour expérimenter cette
voie. Les services à vérifier sont traduits en MEC (section
4) puis vérifiés dans la section 5. La section 6 est
consacrée aux extensions de la traduction en MEC. Enfin,
nous positionnons nos travaux dans la section 7.
2 Présentation rapide du modèle
Kmelia est un modèle à composants basés sur des descriptions
de services. Sommairement, un composant est
défini par un espace d’états, des services et une interface.
L’espace d’état est un ensemble de constantes et de vari-

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
ComponentInterface
0..*
1
Service
0..*
name : String
originalservice : String
parameters : ArrayList
returnType : String
pre : String
post : String
0..*
-services
-owner
1
1
Component
name : HashMap
properties : HashMap
types : HashMap
variables : HashMap
+components
0..*
provided
-required
0..*
RequiredService
0..*
+intrequired
0..*
0..*
-extrequired
-calrequired
0..*
-serviceInterface
1
-provided
0..*
ProvidedService
-owner
0..*
1..1
-subprovided
0..1
Composition
owner
links
-behavior
LTS
-composition
0..*
0..*
ServiceInterface
0..*
0..*
Figure 1 : Méta-Modèle simplifié
ables typées, contraintes par un invariant. Les services
modélisent des fonctionalités (offertes ou requises) et sont
eux-mêmes constitués d’une interface (qui peut inclure
des sous-services), d’une description d’état et d’assertions
(pre-post conditions). Le comportement (dynamique)
d’un service offert est caractérisé par un automate, qui
précise les enchaînements d’actions autorisés. L’interface
d’un composant indique les services qu’il propose et ceux
qu’il requiert. Les composants peuvent être assemblés ou
composés. Une composition est un assemblage encapsulé
dans un composant. Dans un assemblage, les services des
composants communiquent par échanges de messages sur
des canaux. Les canaux sont point-à-point (dans la version
actuelle du modèle) mais bidirectionnels. La description
détaillée du modèle est présentée dans (André, Ardourel,
Attiogbé, Habrias & Stoquer 2005). Nous donnons dans
la figure 1, un métamodèle très simplifié en utilisant la
notation UML.
Nous illustrons le formalisme Kmelia par l’exemple du
guichet automatique bancaire (GAB), qui a pour avantage
de ne pas nécessiter une longue description informelle
pour sa compréhension. Le GAB propose ici deux services
aux utilisateurs : retrait et consultation.
Dans ces deux cas, le GAB a besoin d’informations de
la part de l’utilisateur, par exemple son code de carte.
L’utilisation d’un modèle à composants nous permet de
séparer la réception et le traitement de ces informations
de la manière dont ces dernières sont obtenues. On décide
ici que des composants dédiés à l’interface homme machine
se chargent d’invoquer les services de base du GAB
et de leur fournir les informations nécessaires.
La figure 2 illustre un assemblage pour le GAB.
On y distingue le composant central BASEGAB
dont la spécification nécessite la spécification de
deux autres composants GROUPEMENT BANCAIRE
et BANQUE LOCALE. Deux autres composants
IHM CLIENTR et IHM CLIENTC utilisent ses services
offerts. Dans la définition du composant BASEGAB,
aucune hypothèse n’est posée sur les composants qui
offriront les services requis, un composant qui offre
les quatre services convient. De même, aucune hypothèse
n’est faite sur les ”clients” des services offerts.
Nous avons volontairement réduit les interfaces des
composants.
Nous nous appuyons sur le composant central BASEGAB
qui offre les services correspondants aux deux fonctionnalités
principales de l’application.
COMPONENT BASEGAB
INTERFACE
provides : {retrait, consultation}
requires : {verifAut, modifCpte, lireCpte}
TYPES
CB : {code:Integer, id:Integer, limit:Integer}
VARIABLES
dispo : Integer,
caisse : Integer,
cartesConservees : Set
INITIALISATION
dispo = 100 ; caisse = 1000 ;
cartesConservees = {}
PROPERTIES
caisse >= 0 && size(cartesConservees) < 100
La description de l’espace d’états du GAB inclut : une
variable caisse, qui indique le montant disponible en

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
GROUPEMENT
BANCAIRE
autorisation
BASEGAB
verifAut
retrait
IHM_CLIENTR
retirer
requete
miseajour
modifCpte
dem_montant
montant
code
dem_code
BANQUE
LOCALE
IHM_CLIENTC
code
requete
solde
lireCpte
consultation
consulter
service offert service requis lien (canal) appel de service
Figure 2 : Assemblage global du GAB
caisse ; une variable dispo, qui indique le montant
minimum disponible en caisse pour que le service soit
disponible ; et une variable carteConservées, qui est
une collection des cartes retenues. Un invariant indique
que le montant en caisse doit être positif et que le nombre
de cartes conservées ne dépasse pas une certaine limite
pour que le GAB soit en service.
Nous centrons notre présentation sur le service retrait
offert par le composant BASEGAB. Ce service requiert
trois services dem code pour demander le code de la
carte, dem montant pour demander le montant du retrait
et verifAut pour vérifier l’autorisation de retrait
de la part du groupement bancaire.
provided retrait (cb : CB)
Interface
calrequires : {dem_code, dem_montant}
extrequires : {verifAut}
Pre
caisse >= dispo
# le service est disponible si
# la caisse contient assez d’argent
Variables # locales au service
nbe : Integer,
# nombre d’essais pour entrer le code
c : Integer,
# code entre par l’utilisateur
a : Integer,
# montant entre par l’utilisateur
rep : Boolean
# reponse de la demande d’autorisation
Behavior
init i # i est l’etat initial
final f # f est un etat final
{ i -- nbe := 3 --> e0 ,
e0 -- __CALLER!!dem_code() --> e1 ,
# appel du service requis code chez l’appelant
e1 -- {__CALLER??dem_code(c) ;
nbe := nbe-1 }--> e2 ,
# reception du mot de passe (:=)
e2 -- [c=cb.code] rep:=
_verifAut!!verifAut(cb.id, c) --> e3,
# appel synchrone (:=) du service verifAut
e2 -- [ccb.code && nbe > 0]
msg("redonnez votre code svp") --> e0 ,
e2 -- [ccb.code && nbe = 0] {
msg("carte conservee") ;
avalerCarte() } --> e4 ,
e3 -- [rep] msg("montant ?") --> e5,
# le groupement autorise,
# on demande le montant
e3 -- [not rep] { msg("refuse") ;
restituerCarte() }--> e4 ,
#==> voir la figure 3

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
IHM_CLIENTR.requete() =
BASEGAB.retrait(cb : CB) =
msg(...)
i
lire(maCarte)
e0
retirer!!retirer(maCarte)
e1
retirer??retirer(res)
e2
IHM_CLIENTR.code () =
e0
msg(...) ; lire(monCode)
e1
CALLER!!code(monCode)
f
[ccb.code
&& nbe >0]
msg(...)
[c=cb.code]
rep:= verifAut!!
verifAut(cb.id, c)
[rep] msg(...)
i
e0
e1
e2
e3
e5
nbe := 3
CALLER!!dem_code()
CALLER??dem_code(c)
; nbe := nbe - 1
[not rep] msg(...) ;
restituerCarte()
[ccb.code && nbe = 0]
msg(...) ; avalerCarte()
[m > cb.limit]
msg(...)
e4
IHM_CLIENTR.montant () =
e0
e1
e2
msg(...) ; lire(m)
CALLER!!montant(m)
CALLER!!dem_montant()
CALLER??dem_montant(m)
[m i,
i -- lire(maCarte) --> e0 ,
#==> voir la figure 3 e1,
e1 -- __CALLER!!code(monCode) --> f
}
end
provided montant () : Integer
# rend le montant demande par l’utilisateur
Variables # locale au service
m : Integer # montant demande
Behavior
init e0 final e2
{ e0 -- {msg("Entrer le montant");
lire(m) } --> e1,
e1 -- __CALLER!!montant(m) --> e2
}
end
Une représentation graphique facilite la lecture des
systèmes de transitions. La figure 3 en présente
un extrait. A chaque état du système de transitions
étiquetées, on peut associer un ensemble de services offerts,
ou de sous-services invocables. La notation e1
, indique que les services code et
montant sont invocables dans l’état e1 ; la suite du
traitement est poursuivie dans le service appelé. Pratiquement,
cette notation permet de simplifier la description
du système de transitions d’un service. Un sous-service
est un service offert qui ne figure pas dans l’interface
du composant, les services code et montant sont des
sous-services de IHM CLIENTR. L’usage du service requete
est flexible : il peut fonctionner avec un service
requis retirer qui demande facultativement un code et
un montant et ce dans n’importe quel ordre.

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
3 Vérification de conformité des interactions
entre composants
La correction d’un modèle à composants comprend la
correction individuelle des composants et la correction
des assemblages. La correction individuelle des composants
est liée à leur cohérence interne (préservation
de l’invariant dans les services, pas de blocage) mais
aussi à la correction des compositions, s’ils sont structurés
hiérarchiquement. La correction des assemblages atteste
que, mis ensemble, les composants restent corrects. Elle
se base sur des propriétés structurelles et comportementales
: pas de circuit dans les dépendances entre composants
et services, pas de besoins non satisfaits, sûreté,
vivacité, conformité des interactions, etc.
Nous nous intéressons ici à la conformité des interactions
sur un canal (typage et assertions sont supposés résolus).
La propriété de sûreté à prouver est : pour toute interaction,
il n’y a pas d’incompatibilité de comportement.
Autrement dit, les services sont corrects deux à deux (correction
locale). La correction globale des interactions
est l’union des corrections locales d’interaction (Attie &
Lorenz 2003). Une interaction est la donnée de trois services
(un contexte) : un service offert (à vérifier) lié à
un autre service offert (l’appelant) via un service requis
dans l’assemblage. Pour prouver la conformité des interactions,
nous procédons par la traduction des composants
en MEC. Nous avons choisi MEC pour sa simplicité (notation
et concepts, produits) qui nous permet de l’utiliser à
la fois comme langage d’encodage et d’échange entre les
formalismes/systèmes plus évolués tel que SPIN et Lotos.
MEC (Arnold, Crubillé & Bégay 1994) est un modelchecker.
La technique de model-checking consiste à
décrire l’espace d’états d’un système et à l’explorer par
différents algorithmes afin de déterminer les propriétés
dynamiques du système étudié (dans quels états elles sont
vraies). En MEC les propriétés sont exprimées par des
calculs sur les automates, ces calculs sont exprimés sous
forme ensembliste ; ils sont interprétés dans l’algèbre de
Dicky et implantés par des parcours de graphes.
Dans la section 4 nous décrivons les bases la transformation
de spécifications Kmelia en MEC (version 4) pour
un contexte donné. Puis nous étudions les propriétés du
modèle issu de la traduction de l’exemple GAB dans la
section 5. Enfin, la section 6 est consacrée aux concepts
de Kmelia qui n’existent pas dans MEC.
4 Traduction des composants en
MEC
MEC et Kmelia utilisent tous deux des systèmes de
transitions étiquetés pour représenter la dynamique des
systèmes. Néanmoins, l’expression des étiquettes est
plus riche dans Kmelia, qui possède de plus une
structuration hiérarchique d’état. De ce fait, certains
concepts non traduisibles directement (gardes,
paramètres sous-services, etc.) sont ignorés. Rappelons
que le contexte d’une interaction est défini par
un triplet . Le
service offert est lié au service requis dans l’assemblage.
Détermination de la cible La cible est l’ensemble
des services participant à une interaction sur la liaison
requis-offert. Sur la base du triplet de contexte,
on filtre l’ensemble des invocations de services pour
déterminer la cible. Les invocations de services et
communications qui se font sur d’autres liaisons (d’autres
canaux) sont assimilées à des actions internes vis-à-vis de
l’interaction considérée. De fait, l’espace combinatoire
est réduit et limité aux interactions entre deux composants
(vérification locale). Dans notre exemple, le contexte
est le triplet .
La cible comprend l’ensemble BASEGAB.retrait,
IHM ClientR.requete, IHM ClientR.code,
ClientR.montant¡ IHM .
Aplatissement des automates Kmelia autorise le rattachement
de services à des états (sous-services optionnels)
et la composition d’actions dans les transitions
(séquentiel, collatéral, parallèle). MEC ne supportant pas
les automates hiérarchiques, un traitement préliminaire
s’impose pour aplatir les automates des services de la
cible. L’automate d’un service attaché à un état e est expansé
de telle sorte que son état initial et final soient rattachés
à e (formant ainsi une boucle). Les noms des états
intermédiaires du sous-automate sont préfixés par le nom
de l’état de rattachement. Par exemple, l’automate du service
code est expansé sur l’état e1 du service requete.
Les transitions composées sont aussi aplaties en faisant
apparaître de nouveaux états intermédiaires. Par exemple,
la séquence e3 -- [not rep] msg("refuse")
; restituerCarte() --> e4 se traduit en 2 transitions
e3 -- [not rep] msg("refuse") --> e3 1
et e3 1 -- restituerCarte() --> e4.
Traduction des services Le principe général est le suivant
: un service est un processus, décrit en MEC par
un automate ayant pour nom la concaténation du nom
du composant et du nom du service. Ainsi le service
BASEGAB.retrait(cb:CB) donne lieu à l’automate
BASEGAB retrait. On considère que chaque service
n’est instancié qu’une fois (un seul exemplaire, un seul
processus). Dans notre exemple, l’état e2 du service
retirer du composant IHM ClientR est final ; ceci
facilite le calcul des propriétés de terminaison. MEC
n’autorise pas les caractères tels que les parenthèses, les
espaces, les ’, les ? et !, :=, les chiffres, ..., certaines trans-

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
formations sont nécessaires ; par exemple, les caractères
ignorés sont transformés par ’ ’ et les paramètres sont ignorés.
1. Chaque état du service est traduit par un état MEC de
même nom (à un renommage près). L’état initial et les
états finaux sont annotés (pour les enlever du calcul des
états bloquants).
2. Chaque transition est traduite par une transition MEC.
Le traitement varie en fonction de l’étiquette. Les appels
de services correspondent aux transitions d’initialisation.
On les préfixe par call. On adopte les conventions
suivantes : une communication canal!msg est traduite
en emit canal msg, une communication canal?msg
est traduite en rcv canal msg.
3. Une transition d’initialisation est ajoutée pour la synchronisation
de l’appel de service, son étiquette est celle
du service préfixée par start . Le nouvel état initial est
noté init. Les transitions de fin de service sont considérées
comme des transitions ordinaires. Sur chaque état
on ajoute une transition e (action vide) car les automates
peuvent évoluer indépendamment les uns des autres en dehors
des communications.
Vecteur de synchronisation Le vecteur de synchronisation
précise les actions globales du système et notamment
les synchronisations entre actions de plusieurs automates.
On retrouve un mécanisme similaire dans les communications
des algèbres de processus. Les actions globales
sont les invocations de services et les communications
dans Kmelia. L’algorithme tient compte de la possibilité
de renommage dans les liaisons. Considérons deux situations
: système séquentiel, système parallèle. Dans un
système séquentiel, une seule action a lieu à chaque instant,
dans un système parallèle plusieurs actions peuvent
se dérouler en même temps si elles sont indépendantes.
Par exemple, une action interne sur deux composants peut
se faire en parallèle, de même qu’un échange sur deux
canaux différents. Cette distinction n’influe pas sur les
propriétés de sûreté (seules des transitions sont ajoutées).
Cas d’un système séquentiel.
On trouve deux types d’actions : action interne à un
service, échange sur un canal. Si un service n’est pas
concerné par une action, cela se note explicitement par
l’étiquette ’e’ dans le vecteur de synchronisation. Le
vecteur est rempli par parcours des automates des services,
compte tenu des liaisons autour du contexte de
l’interaction.
1. Chaque action interne i d’un automate A donne lieu à
une ligne dans le vecteur de synchronisation, telle que la
cellule de la colonne de A soit étiquetée par l’action i.
2. Chaque appel de service call S d’un automate A est
synchronisé avec le démarrage de service start S de
l’automate S. Chaque résultat de service res S d’un automate
A est synchronisé avec le retour de service ret S
de l’automate S. Le démarrage du service qui invoque le
service de référence est considéré comme une action interne
(IHM ClientR.requete).
3. Chaque réception de message rcv S msg d’un automate
A est synchronisée avec une émission emit S msg
d’un automate A’.
La spécification du système séquentiel est la suivante :
transition_system IHM_CLIENTR_DemRetrait < width
= 0 >;
init |- e -> init,
start_requete -> i;
i |- e -> i,
msg -> i;
lire -> e0;
e0 |- e -> e0,
call_retirer -> e1;
e1 |- e -> e1,
start_code -> e1_1,
start_montant -> e1_2,
ret_retirer_retirer -> e2;
...
e2 |- e -> e2;
< initial = { init } ; final = {e2} >.
transition_system BASEGAB_retrait < width = 0 >;
init |- e -> init,
start_retrait -> i;
i |- e -> i,
nbe3 -> e0;
e0 |- e -> e0,
call_dem_code -> e1;
e1 |- e -> e1,
ret_retrait_dem_code -> e1_1;
e1_1 |- nbe_nbe_1 -> e2;
e2 |- e -> e2,
msg -> e0,
msg -> e2_1,
ext_verifAut -> e3;
e2_1 |- e -> e2_1,
avalerCarte -> e4;
e3 |- e -> e3,
msg -> e5,
msg -> e3_1;
e3_1 |- restituerCarte -> e4;
e4 |- e -> e4,
res_retrait_retrait-> f;
e5 |- e -> e5,
call_dem_montant -> e6;
e6 |- e -> e6,
ret_retrait_dem_montant-> e7;
e7 |- e -> e7,
msg -> e3,
debiter -> e7_1;
e7_1 |- restituerCarte -> e8;
e8 |- e -> e7,
res_retrait_retrait -> f;
< initial = { init } ; final = {f} >.
synchronization_system Verif_BASEGAB_retrait <
width = 2 ;
list = (IHM_CLIENTR_retirer, BASEGAB_retrait)>;
\* lancement du service appelant *\
( start_retirer . e );
\* actions interne de IHM_CLIENTR_retirer *\
( msg . e );
( lire . e );
\* actions interne de BASEGAB_retrait *\
( e . nbe3 );
( e . nbe_nbe_1);
( e . msg );
( e . ext_verifAut );

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
( e . avalerCarte );
( e . restituerCarte );
( e . debiter);
\* invocations de services *\
( call_retirer . start_retrait );
( ret_retirer_retirer . res_retrait_retrait );
( start_code . call_dem_code );
( res_retirer_code . ret_retrait_dem_code );
( start_montant . call_dem_montant );
( res_retirer_montant .
ret_retrait_dem_montant).
Cas d’un système parallèle.
La version parallèle est obtenue par enrichissant du
vecteur de synchronisation de la version séquentielle; on
combine deux à deux les lignes du vecteur de synchronisation
: s’il y a conflit pour un automate (une seule action
à la fois), la combinaison n’est pas possible, sinon
on fusionne les lignes en écrasant les actions e. On
procède de même pour trois actions en comparant les
lignes à deux actions avec celles à une action, et ainsi de
suite. Dans notre exemple, seules les actions internes peuvent
être fusionnées, toute autre combinaison engendre un
conflit. La spécification du système parallèle est la version
séquentielle avec des lignes supplémentaires dans le
vecteur de synchronisation.
( msg . nbe3 );
( msg . nbe_nbe_1);
( msg . msg );
( msg . ext_verifAut );
( msg . avalerCarte );
( msg . restituerCarte );
( msg . debiter);
( lire . nbe3 );
... idem msg
A partir des composants (et services) traduits en MEC
nous pouvons effectuer les vérifications de correction.
5 Vérifications avec MEC
Nous étudions les propriétés du système via MEC et
nous montrons que des interactions non conformes sont
détectées par notre méthode : incohérence de protocole
pour le service retrait. Le problème du nondéterminisme
dans les communications est soulevé.
L’étude des propriétés dynamiques inclut l’étude des propriétés
structurelles (non-déterminisme, blocage, ...) et
celle des propriétés comportementales (traces, famine...).
L’étude est faite ici par interprétation des expressions
MEC. Soit à évaluer les expressions suivantes :
function inevitable(Y:trans ; X:state)
return Z:state;
begin
Z = X \/ (src(Y /\ rtgt(Z))
- src(Y /\ rtgt(*-Z)))
end.
sync(Verif_BASEGAB_retrait, sys);
dts(sys);
finaux := final[1] /\ final[2];
dead := (* - src(*)) - finaux;
deadlock:=inevitable(*,dead);
La fonction inevitable calcule l’ensemble Z des
états atteignant (que) ceux de X avec les transitions
de Y. L’opérateur sync calcule le produit synchronisé
(l’automate global du système). Le produit synchronisé
calcule un automate global par produit libre d’automate,
en ne conservant que les transitions qui figurent dans le
vecteur de synchronisation. La variable finaux donne
l’ensemble des états finaux (tous les services sont finis).
La variable dead donne les états bloquants (qui
n’ont pas de transitions sortantes). La variable deadlock
indique si les états bloquants sont inévitables ou
pas. Dans notre exemple, nous prouvons qu’il n’y a pas de
blocage pour la version séquentielle. Nous l’interprétons
comme une compatibilité des échanges dans l’interaction.
Pour autant, le système n’est pas vivace car il n’est pas
réinitialisable. Le résultat de l’analyse de la spécification
du système parallèle est identique à celui de la version
séquentielle ; seul le nombre de transitions change. En effet
il n’y a aucune interaction entre la demande du montant
et le retour du montant.
Incohérence de comportement Le modèle de la figure
3 est enrichi avec une communication relative à
l’échange de carte. Le service requete du composant
IHM CLIENTR de la figure 3 est modifié à partir de l’état
e1 pour inclure la récupération de carte :
e1 -- _retirer?recupCarte(c) --> e1_1 ,
// reception de la carte modifiee
e1_1 -- _retirer??retirer(res) --> e2
Le service offert retrait du composant BASEGAB de
la figure 3 est modifié pour renvoyer la carte dans une
communication et non plus par une action interne. La
récupération de la carte (côté client) est synchronisée avec
la restitution de la carte (côté GAB).
e3 -- [not rep] { msg("refuse") ;
__CALLER!recupCarte(c) }--> e4 ,
...
e7 -- [m e8 ,
La traduction modifie les automates en conséquence et
ajoute une ligne dans le vecteur de synchronisation :
\* communications sur retirer-retrait *\
( rcv_retirer_recupCarte . emit_retrait_recupCarte );
Le résultat fait apparaître un blocage. L’état (e1,e4) est
bloquant ; nous l’interprétons par : le client attend sa carte
qui a été avalée. En effet, nous avions omis de restituer la
carte en cas d’échec (transition e3 -> e4).

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
Non-déterminisme et incohérence Dans cette section,
on met en évidence une incohérence due au nondéterminisme
local. Soit les automates partiels de services
de la figure 4 :
e1
ProcA() =
c?a()
e0
f
i
c?b()
i
e2
e1
ProcB() =
c!a()
Figure 4 : Automates partiels de deux services
Voici un extrait de la traduction en MEC.
transition_system ProcA < width = 0 >;
e0 |- e -> e0,
rcv_c_a -> e1,
rcv_c_b -> e2;
e1 |- e -> e1,
i -> f; \* f est suppose final *\
e2 |- e -> e2,
i -> f; \* f est suppose final *\
f |- e -> f;
< initial = { e0 } ; final = {f} >.
transition_system ProcB < width = 0 >;
e0 |- e -> e0,
emit_c_a -> e1,
emit_c_b -> e2;
e1 |- e -> e1,
i -> f; \* f est suppose final *\
e2 |- e -> e2,
i -> f; \* f est suppose final *\
f |- e -> f;
< initial = { e0 } ; final = {f} >.
e0
f
i
i
c!b()
synchronization_system testChoix < width = 2 ;
list = ( ProcA, ProcB ) >;
\* actions interne de l’automate ProcA *\
( i . e );
\* actions interne de l’automate ProcB *\
( e . i );
\* communications sur c *\
( rcv_c_a . emit_c_a );
( rcv_c_b . emit_c_b ).
Seules les communications cohérentes sont acceptées,
l’automate global comporte 8 états. Il n’y a pas
de blocage, car les communications incohérentes (e.g.
émission du message a sur le service c et réception du
message b sur le service c) sont refusées par le vecteur
de synchronisation. Pour enrichir la détection des cas
d’incohérences, on peut affiner la description de la communication.
Par exemple, on distingue la sélection du service
(canal) de l’envoi de message. Les erreurs détectées
sont celles d’un message incohérent sur le même canal.
Cela revient, dans notre méthode de traduction, à interpréter
la communication par une transition séquentielle
e2
: sélection en lecture ou écriture d’un canal, puis envoi/réception
du message. Par exemple e0 |- rcv c a
-> e1 s’écrit e0 |- rcv c -> e0 1 et e0 1 |- a -> e1.
L’évaluation du cas asynchrone produit le résultat suivant
: 12 états, 14 transitions, un état initial, un état final,
2 blocages. MEC détecte deux cas d’erreur (deux
”deadlocks”) : émission du message a sur le service c et
réception du message b sur le service c, émission du message
b sur le service c et réception du message a sur le
service c. On détecte plus d’incohérences, mais la traduction
est plus lourde. Enfin, on peut encore enrichir la description
en considérant un niveau supplémentaire : choix
du canal, choix du mode d’émission et choix du message.
Cela permet de détecter les émissions des deux côtés ou
les réceptions des deux côtés.
6 Extensions de la traduction
Nous évoquons dans cette section des extensions à la traduction
en MEC du formalisme Kmelia ; il s’agit notamment
de la prise en compte des gardes, des paramètres
des messages et des instances multiples de services impliquées
dans une interaction.
Prise en compte des gardes MEC ne permet pas de
modéliser les gardes. Il n’est pas imaginable de faire
de l’évaluation dynamique. Pour explorer les traces
d’exécution, une première solution consiste à ajouter des
transitions pour les évaluations de gardes (étiquetées par
guardIsTrue et guardIsFalse par exemple). On
suppose que les gardes sont disjointes et complémentaires.
Lorsque plus de deux alternatives existent (une garde est
une combinaison d’expressions), une solution consiste à
décomposer chaque expression en gardes élémentaires.
Chaque alternative est ainsi étiquetée par une combinaison
des gardes élémentaires. On suppose que les alternatives
de gardes sont disjointes et complémentaires. Par
exemple, les gardes des transitions de l’état e2 du service
Retrait de la figure 3 se traduisent en
g_e2_1 == (c = carte.code)
g_e2_2 == (nbe > 0)
...
e2 -- [not g_e2_1 & g_e2_2]
msg("redonnez votre code svp") --> e0 ,
L’analyse statique des gardes (au même titre que
la vérification de l’invariant) permet d’en vérifer la
cohérence. La traduction en MEC des gardes peut se faire
de deux manières : soit on ajoute des transitions explicites
pour l’évaluation des gardes, soit on ajoute un préfixe aux
étiquettes des transitions. L’inconvénient de la première
solution est qu’on ne sait pas ce qui se passe lorsque
la garde n’est pas vérifiée (état bloquant, attente) ou jamais
vérifiée (état bloquant). Une autre manière de traiter

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
les gardes est d’invalider certains états : après traduction,
pendant l’analyse des états bloquants, l’utilisateur
peut détecter que certains états bloquants sont inaccessibles
compte-tenu de l’évaluation des gardes. Dans ce
cas, l’utilisateur demande à filtrer ces états (ou une extension
de ces états) lorsque la condition est locale, pour
les éliminer de l’analyse MEC. Il peut alors relancer la
vérification itérativement. Le filtrage peut se faire par exemple
par marquage d’états MEC : si un couple d’états de
service est invalide, tous les états du produit cartésien qui
contiennent ce couple, i.e. quelque soit l’état des autres
services concernés, sont invalides.
Prise en compte des communications et des paramètres
En MEC il n’est pas facile de traiter simplement les
paramètres des communications. Il se pose en effet le
problème des types de données et des plages des valeurs
potentielles pour les données. Une solution est d’associer
un processus MEC à chaque variable (sur la base de la
modélisation d’algorithmes en MEC) et en s’inspirant de
LOTOS, on crée une transition par valeur possible des
paramètres. Cette mise en œuvre est complexe et nécessite
une concordance avec la traduction des actions en MEC.
Elle va de pair avec le traitement symbolique des gardes.
Prise en compte d’instances de services Un service
offert comporte obligatoirement un état final. Pour implanter
plusieurs occurrences d’un service, une transition
de réinitialisation est ajoutée à l’état final. Le résultat
est un ensemble de processus réinitialisables de telle
sorte qu’un service peut être invoqué plusieurs fois, mais
séquentiellement. L’invocation parallèle de services ne
pose pas de problèmes de définition en MEC car on peut
ajouter autant de colonnes qu’on souhaite dans le vecteur
de synchronisation. Le problème qui reste à traiter concerne
l’identification des services (ajout d’un numéro aux
noms de service) et leur dénombrement. Néanmoins il
n’est pas possible de définir des services récursifs ni de
créer dynamiquement des services.
7 Travaux connexes
Le modèle Kmelia est caractérisé d’une part par son
fondement sur les services, décrits à l’aide de systèmes
de transitions étendus et qui apparaissent dans l’interface
des composants, et d’autre part par la souplesse du formalisme
support de description des interactions. Le formalisme
kmelia est relativement simple, compte-tenu du
petit nombre de concepts qui y sont utilisés. Néanmoins
il est suffisamment riche pour pouvoir exprimer des contraintes
sur les interfaces des composants. Sa flexibilité
est mesurable à travers les possibilités offertes pour la description
et l’utilisation des composants et des services :
sous-services optionnels, utilisation partielle de composants,
actions internes, liaisons explicites, renommage
des liens, interfaces à différents niveaux de précision.
Notre modèle est aussi moins restrictif que celui proposé
dans (Bordeaux, Salaün, Berardi & Mecella 2004, Bracciali,
Brogi & Canal 2002); en effet ces travaux imposent
des limitations comme : l’étude de compatibilité
comportementale entre deux services uniquement, les
systèmes de transitions décrivant les services sont moins
expressifs, ils ne décrivent que des comportements purs et
les données ne sont pas prises en compte.
Ces caractéristiques distinguent nos travaux de la plupart
des travaux sur les comportements dynamiques de
composants (Behavior Protocols) tels (Plasil & Visnovsky
2002, Giannakopoulou, Kramer & Cheung 1999, Pavel,
Noye, Poizat & Royer 2005) qui se basent sur la description
du comportement des composants (son protocole)
et non des services. Ces travaux se distinguent
aussi par la qualité du formalisme associé aux protocoles
(expressivité, flexibilité, lisibilité) : (Plasil &
Visnovsky 2002) utilise des expressions régulières, les
autres utilisent des automates relativement simples. Sans
atteindre l’expressivité des Statecharts, notre formalisme
permet une structuration plus flexible des automates.
La plupart des travaux intègrent aussi des connecteurs
de composants (Mehta, Medvidovic & Phadke 2000) et
la composition s’en trouve affectée. Nous n’avons pas
de connecteurs, nous avons privilégié l’homogénéité qui
nous procure la simplicité dans la composition des composants.
En effet un seul opérateur de composition est
nécessaire et il est basé sur l’interaction entre les services.
De cette façon, la correction des interactions et
par conséquent la composabilité est basée en partie sur
l’interaction entre les comportements des services. Nous
avons élaboré une solution qui implique localement les
(systèmes de transition des) services pris deux à deux.
Cette solution limite le problème de l’explosion combinatoire
qui est la principale limitation de la plupart des
travaux sur les interactions (De Alfaro & Henzinger 2001,
Yellin & Strom 1997). Ces derniers utilisent des variantes
du modèle des automates à états et leurs composition.
La correction des compositions de composants avec
limitation de l’explosion combinatoire est aussi étudiée
dans (Attie & Lorenz 2003). L’approche les auteurs est
différente de la nôtre; plusieurs automates sont utilisés
pour un même composant : un automate par interaction du
composant avec un autre composant de l’environnement.
8 Discussions et perspectives
Les travaux présentés dans cet article contribuent à la
définition et à la vérification de la compatibilité des composants
dans un assemblage. Nous avons particulièrement
insisté sur la compatibilité des comportements. Le formalisme
Kmelia permet de spécifier des services, des
composants et d’enrichir les interfaces de composants

MOSIM’06 – du au ¡ avril ¢¤£¥£¥¦ - Rabat - Maroc
avec des informations sur les comportements dynamiques
des services. Ces comportements sont à la base de la
vérification des interactions entre services. Concrètement
la vérification se fait par traduction dans un formalisme
outillé. Dans cet article, nous avons présenté la traduction
dans MEC et les résultats obtenus. MEC a permis
de vérifier la conformité comportementale, lorsque les
contraintes portant sur les parties ”symboliques” (gardes
et paramètres) sont assouplies. Il s’agit d’un premier
niveau de vérification. En parallèle, nous avons mené des
expérimentations avec LOTOS ; on s’aperçoit qu’on peut
pallier en partie à certaines restrictions imposées par MEC
(par exemple on peut utiliser des types réduits pour les
paramètres et un traitement non symbolique des gardes).
La version MEC 5, couplée à Altarica permet elle aussi de
traiter des paramètres et des gardes (lorsqu’elles portent
sur des valeurs associées aux états). Cependant la notion
d’état dans Altarica est plus proche de celle de formalismes
tels que Z ou B, que de celui des automates.
Nous avons développé en Java un prototype (nommé
COSTO : Component Study Toolkit) qui permet
d’expérimenter nos travaux sur les composants et en particulier
la vérification d’interactions. COSTO permet de
compiler des spécifications Kmelia et de les représenter
dans une structure abstraite sous forme d’objets. Les outils
de traduction vers LOTOS et MEC parcourent la structure
abstraite et génèrent des spécifications dans les langages
correspondants.
Les perspectives à court terme sont de poursuivre nos
expérimentations sur les aspects dynamiques avec Altarica,
SPIN ou PVS, pour établir des comparaisons entre
formalismes et stabiliser notre méthode de vérification
formelle de composants. Concernant les aspects structurels
et fonctionnels des composants, nous nous proposons
de définir des transformations vers des formalismes
adaptés (nous envisageons B et les spécifications
algébriques).
References
André, P., Ardourel, G., Attiogbé, C., Habrias, H. &
Stoquer, C. (2005). A Service-Based Component
Model: Description Formalism, Formal Analysis
and Mechanization, Technical Report RR05.08,
LINA - FRE CNRS 2729 - Nantes. (70 p.).
Arnold, A., Crubillé, P. & Bégay, D. (1994). Construction
and Analysis of Transition Systems with MEC,
AMAST Series in Computing: Vol. 3, World Scientific.
ISBN 981-02-1922-9.
Attie, P. & Lorenz, D. H. (2003). Correctness of Modelbased
Component Composition without State Explosion,
ECOOP 2003 Workshop on Correctness of
Model-based Software Composition.
Bergner, K., Rausch, A., Sihling, M., Vilbig, A. & Broy,
M. (2000). A formal model for componentware, in
G. T. Leavens & M. Sitaraman (eds), Foundations
of Component-Based Systems, Cambridge University
Press, New York, chapter 9, pp. 189–210.
Bordeaux, L., Salaün, G., Berardi, D. & Mecella, M.
(2004). When are two web services compatible?,
TES, pp. 15–28.
Bracciali, A., Brogi, A. & Canal, C. (2002). Dynamically
adapting the behaviour of software components, CO-
ORDINATION ’02: Proceedings of the 5th International
Conference on Coordination Models and Languages,
Springer-Verlag, London, UK, pp. 88–95.
De Alfaro, L. & Henzinger, Thomas, A. (2001). Interface
Automata, Proceedings of the Ninth Annual Symposium
on Foundations of Software Engineering (FSE),
ACM Press, pp. 109–120.
Giannakopoulou, D., Kramer, J. & Cheung, S.-C. (1999).
Behaviour Analysis of Distributed Systems Using
the Tracta Approach., Autom. Softw. Eng. 6(1): 7–
35.
Heineman, G. T. & Councill, W. T. (eds) (2001).
Component-based software engineering: putting the
pieces together, Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, USA.
Medvidovic, N. & Taylor, R. N. (2000). A Classification
and Comparison Framework for Software Architecture
Description Languages, IEEE Transactions on
Software Engineering 26(1): 70–93.
Mehta, N. R., Medvidovic, N. & Phadke, S. (2000). Towards
a taxonomy of software connectors, ICSE ’00:
Proceedings of the 22nd international conference on
Software engineering, ACM Press, pp. 178–187.
Pavel, S., Noye, J., Poizat, P. & Royer, J.-C. (2005). Java
Implementation of a Component Model with Explicit
Symbolic Protocols, SC’2005 - Software Composition,
LNCS, Springer Verlag.
Plasil, F. & Visnovsky, S. (2002). Behavior protocols for
software components. IEEE Transactions on SW Engineering,
28 (9), 2002.
Shaw, M. & Garlan, D. (1996). Software Architecture:
Perspective on an Emerging Discipline, Prentice
Hall.
Szyperski, C. (1997). Component Software: Beyond
Object-Oriented Programming, AddisonWesley
Publishing Company.
Yellin, D. M. & Strom, R. E. (1997). Protocol Specifications
and Component Adaptors, ACM Transactions
on Programming Languages and Systems
19(2): 292–333.