Contributions à la conception rigoureuse des systèmes à base de composants exploitant des modèles SysML et des approches formelles

(1)

HAL Id: tel-03126592

https://hal.archives-ouvertes.fr/tel-03126592

Submitted on 31 Jan 2021

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

des approches formelles

Samir Chouali

To cite this version:

Samir Chouali. Contributions à la conception rigoureuse des systèmes à base de composants exploitant des modèles SysML et des approches formelles. Génie logiciel [cs.SE]. Université Bourgogne Franche-Comté, 2020. �tel-03126592�

(2)

Contributions `a la conception

rigoureuse des syst `emes `a base de

composants exploitant des mod `eles

SysML et des approches formelles

(3)

(4)

H

ABILITATION A DIRIGER DES RECHERCHES

`

de l’Universit ´e de Franche-Comt ´e

pr épar ée au sein de l’Universit é Bourgogne Franche-Comt é Sp écialit é :Informatique

pr ´esent ´ee par

S

AMIR

C

HOUALI

Contributions `a la conception rigoureuse des

syst `emes `a base de composants exploitant des

mod `eles SysML et des approches formelles

Soutenue publiquement le 10 juillet 2020 devant le Jury compos ´e de :

YAMINEAIT-AMEUR Rapporteur Professeur `a l’INPT-ENSEEIHT de Toulouse

CHRISTIANATTIOGBE´ Rapporteur Professeur `a l’Universit ´e de Nantes

GWEN SALAUN¨ Rapporteur Professeur `a l’Universit ´e Grenoble Alpes

PIERRE-CYRILLE HEAM Examinateur Professeur `a l’Universit ´e de Bourgougne

Franche-Comt ´e

OLGAKOUCHNARENKO Examinatrice Professeur à l’Universit é de Bourgogne Franche-Comt é

HASSAN MOUNTASSIR Examinateur Professeur `a l’Universit ´e de Bourgogne

(5)

(6)

R

EMERCIEMENTS

Tout d’abord, je remercie chaleureusement les trois rapporteurs de cette HDR, les profes-seurs Yamine AIT-AMEUR, Christian ATTIOGBE´ et Gwen SALAUN¨ , pour le temps consacr ´e

à la relecture et à l’ évaluation de ce manuscrit.

Je tiens également à remercier tous mes coll ègues du DISC qui m’ont soutenu et encou-rag é dans mes activit és scientifiques. Je remercie particuli èrement Hassan Moutassir qui m’a donn é l’opportunit é pour co-encadrer avec lui des travaux de th èse. Mes remercie-ments vont également à Pierre-Cyrille H éam qui m’a accompagn é et soutenu pour la pr éparation de cette habilitation. Je tiens à remercier Olga Kouchnarenko qui m’a en-courag é, ces derni ères ann ées, pour soutenir l’HDR. Aussi, je remercie les coll ègues avec qui j’ai eu des collaborations enrichissantes sur des th ématiques vari ées : Ahmed hammad (d éveloppement de syst èmes complexes en exploitant des mod èles SysML) et Ahmed Mostefaoui (validation des protocoles d’interaction dans les v éhicules connect és). Merci à Julien Bourgeois, directeur du DISC, qui m’a soutenu et encourag é, ces derni ères ann ées, pour effectuer des s éjours scientifiques à l’ étranger et initier des collaborations. Je voudrais aussi remercier les doctorants que j’ai co-encadr és, qui ont eu une place centrale dans ce travail.

Je remercie enfin ma famille pour son soutien permanent et pour avoir accept ´e, ces derniers mois, le partage du temps familial avec mes activit ´es professionnelles.

(7)

(8)

T

ABLE DES MATI

ERES

`

Table des mati `eres vii

I Introduction 1

1 Introduction 3

1.1 Contexte scientifique : d éveloppement des syst èmes à base de

compo-sants critiques . . . 3

1.2 Probl ´ematiques scientifiques . . . 4

1.3 Contributions . . . 8

1.4 Mes publications . . . 11

II Conception incr émentale des syst èmes à base de composants guid ée par SysML 13 2 M éthodologie pour l’assemblage de composants guid ée par SysML 15 2.1 Introduction . . . 15

2.2 Etat de l’art et contributions . . . 16´

2.3 Formalisme des automates d’interface . . . 17

2.3.1 L’approche optimiste pour la v ´erification de la compatibilit ´e . . . 17

2.3.2 Composabilit ´e, compatibilit ´e et composition . . . 18

2.4 Sp ´ecification de l’architecture d’un SBC avec SysML . . . 19

2.5 D ´erivation automatique des automates d’interface `a partir de SysML . . . . 21

2.6 V érification de l’assemblage dans un SBC mod élis é avec SysML . . . 23

2.6.1 Mod `eles formels des diagrammes SysML sp ´ecifiant l’architecture d’un SBC . . . 24

2.6.2 Algorithme de v ´erification . . . 25

2.7 Conception incr ´ementale d’un SBC par des raffinements successifs . . . . 27

2.8 Conclusion . . . 30

2.9 Bilan . . . 30

(9)

3 Adaptation des composants SysML lors du d ´eveloppement d’un SBC 31

3.1 Introduction . . . 31

3.2 Aperc¸u de l’approche . . . 31

3.4 L’approche d’adaptation des blocs SysML . . . 34

3.4.1 Sp écification SysML de la partie à d évelopper . . . 34

3.4.2 S ´election des blocs r ´eutilisables_{Bi} . . . 35

3.4.3 V ´erification de la validit ´e du contrat d’adaptation . . . 37

3.4.4 G ´en ´eration de l’adaptateur . . . 38

3.5 Conclusion et perspectives . . . 42

3.6 Bilan . . . 44

4 Sp ´ecification incr ´ementale d’un SBC en exploitant les exigences 45 4.1 Introduction . . . 45

4.2 Aperc¸u de l’approche . . . 46

4.4 Etude de cas . . . 49´

4.5 Analyse du diagramme des exigences SysML . . . 50

4.6 V ´erification formelle des exigences SysML sur des composants . . . 51

4.6.1 V ´erification avec SPIN . . . 52

4.6.2 Sp ´ecification des exigences avec la LTL . . . 52

4.7 Assemblage des composants et pr ´eservation des exigences SysML . . . . 54

4.7.1 Les exigences fonctionnelles et les actions d’entr ´ee/sortie . . . 54

4.7.2 Pr ´eservation des actions d’entr ´ee/sortie par la composition des au-tomates d’interface . . . 55

4.7.3 V ´erification de la pr ´eservation des exigences atomiques . . . 55

4.8 Sp ´ecification de l’architecture du syst `eme . . . 56

4.9 Illustration sur l’ ´etude de cas . . . 57

4.10 Conclusion et perspectives . . . 59

4.11 Bilan . . . 59

III Assemblage des composants bas é sur leurs contrats comportemen-taux 61 5 Conception à base de composants orient és objet 63 5.1 Introduction . . . 63

(10)

TABLE DES MATI `ERES ix

5.3 Contrats comportementaux . . . 65

5.3.1 Formalisation des protocoles des composants orient ´es objet . . . . 65

5.3.2 S ´emantique des m ´ethodes . . . 67

5.4 Etude de cas d’un syst `eme ferroviaire . . . 68´

5.4.1 Conception de l’ ´etude de cas ferroviaire . . . 69

5.5 Compatibilit ´e des composants . . . 71

5.5.1 Synchronisation des automates d’interface et compatibilit ´e s ´emantique . . . 72

5.5.2 L’approche optimiste pour l’assemblage de composants . . . 73

5.6 Raffinement . . . 74

5.6.1 Simulation d’expansion . . . 75

5.6.2 Substituabilit ´e s ´emantique . . . 76

5.6.3 Propri ´et ´es du raffinement . . . 77

5.7 Adaptation des composants . . . 78

5.7.1 Aperc¸u de l’approche . . . 79

5.7.2 Etat de l’art et contributions . . . 80´

5.7.3 Contrat d’adaptation . . . 81

5.7.4 Adaptabilit ´e s ´emantique . . . 81

5.7.5 Sp ´ecification de l’adaptateur . . . 83

5.8 G ´en ´eration automatique de l’adaptateur . . . 84

5.10 Bilan . . . 86

6 V érification de l’interop érabilit é des composants avec B 87 6.1 Introduction . . . 87

6.3 Sp ´ecification des interfaces de composants avec B . . . 90

6.3.1 D ´efinition . . . 90

6.3.2 Etude de cas . . . 90´

6.4 V érification de l’interop érabilit é avec le raffinement B . . . 94

6.4.1 D ´efinitions . . . 95

6.4.2 Etude de cas . . . 99´

(11)

7 V ´erification des protocoles de coordination Reo avec SPIN 101

7.1 Introduction . . . 101

7.3 Reo . . . 103

7.3.1 Connecteurs synchrones et asynchrones . . . 103

7.3.2 Expression logique du comportement d’un connecteur Reo . . . 104

7.4 Formalisation des contraintes Reo sous forme de commandes gard ´ees . . 106

7.5 Formalisation des connecteurs Reo avec Promela . . . 108

7.5.1 Formalisation des Ports . . . 108

7.5.2 Formalisation du protocole d ´efini par un connecteur . . . 109

7.5.3 Formalisation des propri ´et ´es LTL . . . 110

7.6 Conclusion et perspectives . . . 111 7.7 Bilan . . . 111 IV Conclusion et Perspectives 113 8 Conclusion et perspectives 115 8.1 Conclusion . . . 115 8.2 Perspectives de recherche . . . 115

8.2.1 Conception des CPS, correct-par-construction, en exploitant les langages Sysml/Marte/pccsl et les contrats comportementaux des composants . . . 116

8.2.2 Assemblage et adaptation des composants interagissant d’une mani `ere asynchrone . . . 116

8.2.3 Analyse et v ´erification des protocoles de communication dans les v ´ehicules communicants . . . 117

Bibliographie 119

Table des figures 135

(12)

I

NTRODUCTION

(13)

(14)

1

I

NTRODUCTION

1.1/

C

ONTEXTE SCIENTIFIQUE

:

DEVELOPPEMENT DES SYST

´

EMES

`

A BASE DE COMPOSANTS CRITIQUES

Ce document pr ésente mes travaux de recherche men és apr ès l’obtention de mon doc-torat. Ceux-ci concernent principalement l’utilisation des notations semi-formelles et des approches formelles pour la conception rigoureuse des syst èmes à base de composants (SBC) critiques.

J’ai commenc é à travailler sur la th ématique du d éveloppement des SBC lors de mon ann ée de post-doctorat au laboratoire LORIA ( équipe DEDALE), en 2004. Au cours de cette ann ée, je me suis int éress é à l’utilisation de la m éthode B [Abr96b] pour la v érification de l’assemblage des composants. Apr ès mon recrutement à l’universit é de Franche-Comt é en tant que maˆıtre de conf érences (en 2005), j’ai poursuivi mes travaux sur les SBC lors de ma participation au projet ANR TACOS (Trustworthy Assembling of Components : frOm requirements to Specifications ) (2007-2010). L’objectif de ce dernier était de proposer une approche de conception par composants pour le d éveloppement de syst èmes fiables, de l’expression des besoins jusqu’ à une sp écification formelle. Le domaine d’application choisi était celui d’un v éhicule en libre service, appel é CyCab, des-tin é a être utilis é dans les villes du futur pour le transport des personnes d’une mani ère autonome. La nature complexe du CyCab (compos é de composants électroniques, m écaniques, informatiques), nous a motiv é pour le consid érer comme étude cas pour illustrer notre de d émarche de conception à base de composants.

En effet, la conception à base de composants [HC01, Szy02] a montr é son efficacit é pour r épondre à la complexit é croissante des syst èmes informatiques et pour s’adapter à leur évolution rapide. Ainsi, en s’inspirant du concept des composants utilis és dans plusieurs domaines ( électronique, m écanique,...), un logiciel peut aussi être construit par l’assemblage de briques logiciels r éutilisables appel ées composants logiciels. D’apr ès la d éfinition de Clemens Szyperski [Szy02], un composant logiciel est une unit é de com-position avec des interfaces d éfinies contractuellement et des d épendances au contexte explicites. Un composant est donc sp écifi é par ses interfaces, qui exhibent g én éralement ses services fournis et requis. Elles servent, d’une part à exprimer ce que l’on attend de l’environnement pour le bon fonctionnement d’un composant, et d’autre part à d écrire ce qui est offert par un composant. Elles d éfinissent donc une sorte de contrat entre le composant et son environnement.

La d émarche à base de composants vise donc à concevoir et à d évelopper des syst èmes

(15)

par l’assemblage de composants pr éfabriqu és h ét érog ènes (d évelopp és éventuellement par des tierces parties), en se basant uniquement sur leurs interfaces, au lieu de faire un d éveloppement à partir de z éro. L’objectif est d’ établir une sorte de march é commun de composants logiciels, appel és COTS (Commercial-Off-The-Shelf), permettant ainsi aux d éveloppeurs de trouver les composants à int égrer dans leurs syst èmes. Cette d émarche offre principalement deux avantages :

— R éduire les co ûts de d éveloppement d’une application par la r éutilisation et l’assem-blage de composants pr éfabriqu és. En effet, il suffit de r éutiliser des composants d évelopp és par des tiers pour construire de nouveaux syst èmes complexes. — Garantir une maintenabilit é à long terme des logiciels, car une propri ét é intrins èque

aux SBC, c’est leur capacit é d’ évolution et d’adaptation aux nouveaux environne-ments. En effet, il suffit de connecter un nouveau composant à un syst ème existant pour lui rajouter une nouvelle fonctionnalit é ou un nouveau service. Et il suffit de changer un composant d éfaillant pour assurer la maintenance du syst ème existant. Par ailleurs, nous assistons ces derni ères ann ées à une demande de logiciels fiables, de plus en plus complexes et capables de supporter de nouvelles fonctionnalit és, pour une utilisation dans divers domaines : transport, militaire, m édical, domotique, business.... La solution pour concevoir ces syst èmes complexes reste la r éutilisation des compo-sants et l’exploitation de l’approche de conception par compocompo-sants. En effet, c’est une approche qui est applicable à divers domaines : il existe de nombreux mod èles de com-posants [CSVC11, LW07], ciblant des domaines d’applications vari és. De plus, c’est une approche qui a montr é son efficacit é au niveau industriel. Nous citons par exemple, le mod èle à composants Robus [HMN+08, MMTL+16], d évelopp é dans le cadre d’une col-laboration entre industriels (Arcticus Systems, Volvo Construction Equipment and BAE Systems H ägglunds) et l’universit é de M älardalen (Su ède), est utilis é avec succ ès dans l’industrie automobile pour le d éveloppement des logiciels embarqu és. N éanmoins, le mod èle de composants id éal n’existe pas [LW07], et les techniques de conception à base de composants continuent de soulever de nouvelles probl ématiques.

Dans la section suivante, nous pr ésentons les principales probl ématiques que nous avons abord ées dans nos travaux. Elles sont li ées à l’exploitation de SysML [sys] et les contrats des composants, bas és sur le formalisme des automates d’interface [dAH01, AH05], pour le conception rigoureuse des SBC. Les r éponses à ces probl ématiques, sont pr ésent ées dans la section contributions.

1.2/

P

ROBLEMATIQUES SCIENTIFIQUES

´

MODELISATION SEMI´ -FORMELLE DESSBC AVECSYSML

Certes, comme évoqu é ci-dessus, l’approche à composants pr ésente plusieurs avan-tages, n éanmoins concevoir un SBC r épondant aux exigences de l’utilisateur reste une t âche difficile. Cette difficult é est inh érente à la nature complexe de ces syst èmes, constitu és d’un ensemble de composants r éutilisables, donc par d éfinition, destin és à être utilis és dans diff érentes applications, dont certaines peuvent encore être inconnues et dont les exigences ne peuvent pas être pr évues. Ainsi, pour comprendre ces syst èmes en vue de leur conception, il est n écessaire d’utiliser un langage de mod élisation permet-tant d’avoir une vue g én érale du syst ème, tout en d écrivant les niveaux li és à sa

(16)

struc-1.2. PROBL ´EMATIQUES SCIENTIFIQUES 5

ture, son comportement, et ses exigences. Pour cela, le langage SysML (Systems Mo-deling Language) [sys], qui est un profil UML [uml] pour l’ing énierie des syst èmes, nous semble le plus appropri é pour mod éliser les syst èmes complexes. En effet, en plus de la mod élisation structurelle et comportementale d’un syst ème, SysML offre la possibilit é de d écrire ses exigences, ainsi que ses composants physiques et logiciels.

Et comme les SBC, sont de plus en plus exploit és dans des domaines critiques, leur s ûret é de fonctionnement exige l’emploi de m éthodes formelles pour v érifier l’assem-blage de leurs composants lors de la conception. Dans ce contexte, l’utilisation de SysML comme langage de mod élisation, pose les probl ématiques suivantes :

(M1) Quels mod èles SysML utiliser pour sp écifier, sans ambigu¨ıt é, l’architec-ture, le comportement, et les exigences d’un SBC, et comment prendre en consid ération ces mod èles lors du passage au niveau formel pour v érifier l’assemblage des composants ?

(M2) Comment garantir la satisfaction des exigences SysML lors de la conception d’un SBC ?

INTEROPERABILIT´ E DES COMPOSANTS ET LEURS INTERFACES´

Un SBC, comme tout syst ème informatique, n’ échappe pas également aux probl èmes de dysfonctionnements. N éanmoins, dans le domaine des composants, ces dysfonc-tionnements sont principalement la cause des probl èmes d’interop érabilit é des compo-sants (appel ée aussi compatibilit é des compocompo-sants). L’interop érabilit é est d éfinie par la capacit é de deux (ou plusieurs) composants à communiquer et à coop érer malgr é les diff érences dans leurs langages d’impl émentation, leurs environnements d’ex écution, ou leurs mod èles d’abstraction [Weg96, Kon95]. La v érification de l’interop érabilit é des com-posants est donc cruciale pour le d éveloppement des SBC, car cela permet aux concep-teurs de d éterminer si des composants peuvent interagir malgr é leur h ét érog én éit é. Cette v érification repose sur la compatibilit é des interfaces des composants. Celles-ci sp écifient g én éralement des informations aux niveaux signature (profil des op érations), s émantique (des op érations), protocole (ordre d’appel des op érations d’un composants), et qualit é de services (temps de r éponse, co ûts,...). Et g én éralement, plus les interfaces sont expres-sives, plus fiable est le r ésultat de la v érification de l’interop érabilit é.

En plus de l’interop érabilit é, la substituabilit é des composants est également importante lors du d éveloppement des SBC. Sa v érification, en se basant sur une relation de raffi-nement entre les interfaces des composants, permet de d écider si un composant peut être remplac é par un autre plus évolu é, sans corrompre le fonctionnement du syst ème global. Cela permet aussi de construire des SBC, progressivement, par des raffinements successifs.

Dans la litt érature, plusieurs formalismes ont ét é propos és pour sp écifier les interfaces des composants. Par exemple dans [CFTV00], un formalisme bas é sur le π-calcul est utilis é pour enrichir les langages de description d’interfaces (IDL) classiques (limit és au niveau signature), avec la prise en compte des protocoles des composants. Par ailleurs, plusieurs travaux proposent de sp écifier les interfaces des composants avec des automates, comme ceux propos és dans [dAH01, AH05] bas és sur le formalisme des automates d’interface, ainsi que ceux proposant les automates d’interface modales [RBB+09, LNW07]. Ces travaux se focalisent principalement sur la sp écification des

(17)

pro-tocoles des composants et la v ´erification de la compatibilit ´e et du raffinement des inter-faces.

Le concept de contrat est également utilis é pour compl éter les sp écifications de com-posants, pour y introduire principalement la s émantique des op érations. Il a ét é introduit par B. Meyer dans [Mey92], pour d éfinir la s émantique des m éthodes sous forme de pr é et post-conditions, et d’un invariant. Par exemple, la s émantique des m éthodes a ét é prise en compte dans l’approche propos ée dans [CD01], bas ée sur UML et OCL, pour la mod élisation des composants. Dans le mod èle à composants Kmelia [AAA06, AAA08], la s émantique des services des composants est également prise en compte dans la sp écification de leurs interfaces. Dans [BJPW99], une classification des contrats a ét é propos ée : contrat syntaxique (donne la signature des op érations) ; contrat comporte-mental (sp écifie les pr é- et post-conditions des op érations, ainsi qu’un invariant) ; contrat de synchronisation (l’ordre d’invocation des op érations) ; contrat de qualit é de service (permet de quantifier le service fourni).

Au d ébut de nos travaux, nous nous sommes int éress és à l’utilisation de la m éthode B [Abr96a] pour v érifier l’interop érabilit é des composants. L’objectif était d’exploiter les outils de cette m éthode pour v érifier formellement l’interop érabilit é des composants. D’o ù la probl ématique suivante :(I1) comment utiliser B pour sp écifier les interfaces des composants et ensuite comment v érifier leur compatibilit é avec la m éthode B ? Ensuite, nous nous sommes focalis és sur l’utilisation du formalisme des automates d’in-terface [dAH01] pour sp écifier les ind’in-terfaces des composants et v érifier leur assem-blage. Notre choix a ét é motiv é par l’approche optimiste des automates d’interface pour v érifier l’assemblage des composants, particuli èrement adapt ée aux syst èmes ouverts (approche pr ésent ée dans le chapitre 2 ). Un automate d’interface permet d’exhiber les informations des composants aux niveaux signature et protocole. Donc la probl ématique qui s’est pos ée par rapport à notre choix de SysML comme langage de mod élisation est : (I2) comment prendre en consid ération les mod èles SysML sp écifiant un SBC, lors de la v érification de l’interop érabilit é de ses composants en se basant sur leurs automates d’interface ?

Par ailleurs, dans nos travaux, nous avons principalement trait é des études de cas de syst èmes à composants dans le domaine des transports (v éhicules autonomes, trans-port ferroviaire,...). Et pour les interfaces des composants de ces syst èmes, nous avons besoin d’exhiber des informations aux niveaux signature, s émantique, et protocole. Or, le formalisme des automates d’interface ne prend pas en compte le niveau s émantique, donc son expressivit é est insuffisante pour v érifier correctement l’interop érabilit é des composants. D’o ù la probl ématique suivante : (I3) comment prendre en consid ération le niveau s émantique dans le formalisme des automates d’interface pour v érifier l’interop érabilit é et la substituabilit é des composants ?

ADAPTATION DES COMPOSANTS

L’assemblage de composants r éutilisables est souvent contraint par des probl èmes d’inad équations (mismatches) aux niveaux des noms (ou signatures) de leurs services échang és (par exemple, lors de l’association de noms diff érents au m ême service fourni et requis dans deux composants devant interagir), ou de leurs protocoles d’interaction (par exemple, lorsque l’ordre des messages échang és entre les composants n’est pas ad équat). Ce qui provoque des blocages lors de leur assemblage. Ces

(18)

incompatibi-1.3. CONTRIBUTIONS 7

lit és r ésultent g én éralement de la r éutilisation des composants, qu’il faut donc adapter à chaque fois qu’il y a un besoin de les int égrer dans un nouveau syst ème. Pour y rem édier, une solution existe, c’est l’introduction d’un composant interm édiaire, appel é adaptateur [YS97, CMP06, CPS06a], qui joue le r ôle de m édiateur entre les composants r éutilis és. Ce faisant, toutes les interactions transitent par cet adaptateur, qui prend le r ôle d’or-chestrateur en r ésolvant les inad équations, et permet ainsi aux composants concern és d’interagir correctement. Dans notre contexte, les probl ématiques qui se sont pos ées sont les suivantes :

(A1) Comment g én érer automatiquement un adaptateur en partant des mod èles SysML d’un SBC pr ésentant des inad équations entre ses composants ? (A2) Et concernant le formalisme des automates d’interface, une autre probl ématique

s’est pos ée : comment g én érer automatiquement un adaptateur pour des composants sp écifi és par des contrats comportementaux, bas és sur le for-malisme des automates d’interface, en consid érant les niveaux signature, s émantique, et protocole des composants ? En effet, dans l’approche des au-tomates d’interface, l’adaptation des composants n’est pas trait ée, ce qui justifie cette probl ématique.

COORDINATION

L’une des solutions contribuant à r ésoudre les probl èmes d’assemblage des composants dans les syst èmes concurrents et distribu és, est l’exploitation des mod èles et des lan-gages de coordinations [PA98, BCGZ01]. Ces derniers offrent principalement des pri-mitives pour sp écifier les interactions synchronis ées entre les composants. Ainsi, étant donn é un ensemble d’entit és en interaction, le mod èle de coordination a pour but de les faire interagir correctement. Donc, cela permet de d éfinir une entit é, impl émentant un protocole de coordination, pour coordonner les interactions des composants d’une mani ère exog ène. Autrement dit, en faisant abstraction de leurs comportements internes. Ce protocole d éfinit une sorte de contrat d’interaction entre l’ensemble des composants du syst ème.

Dans ce contexte, nous nous sommes int éress és à l’utilisation du langage de coordination Reo [Arb04], d évelopp é par le Professeur F. Arbab et son équipe du centre de recherche CWI d’Amsterdam. Reo, offre un ensemble de primitives de synchronisation, bas ées sur les canaux de communication, pour construire d’une mani ère compositionnelle des pro-tocoles de coordination. Et comme ces propro-tocoles d éfinissent l’ensemble des interactions des composants dans un SBC, leur s ûret é de fonctionnement doit donc être garantie afin de garantir celle du syst ème global. Ainsi, pour v érifier des propri ét és sur les protocoles Reo, nous avons choisi d’exploiter le Model-Checker SPIN [Hol03], pour ses qualit és pour faire face au probl ème d’explosion combinatoire de l’espace d’ états lors de la v érification et aussi pour sa popularit é. La probl ématique suivante s’est alors pos ée : (C1) com-ment traduire les protocoles Reo et leurs propri ét és à v érifier, vers, respective-ment, le langage Promela, de SPIN, et la logique LTL (Linear Temporal Logic), tout en pr éservant les propri ét és de synchronisation des primitives Reo ?

(19)

FIGURE1.1 – Conception incr ´ementale d’un SBC guid ´ee par SysML

1.3/

C

ONTRIBUTIONS

Conception incr émentale des SBC fiables guid ée par des mod èles SysML : Nous avons obtenu plusieurs r ésultats concernant la conception rigoureuse des SBC guid ée par des mod èles SysML, sp écifiant la structure, le comportement, et les exigences du syst ème à d évelopper.

— Mod élisation des SBC avec SysML : Pour r éponde à la probl ématique (M1), nous avons propos é une d émarche pour d écrire l’architecture (avec un diagramme de d éfinition de blocs SysML BDD, avec la d éfinition des ports proxy et des blocs d’in-terface pour mod éliser les ind’in-terfaces des composants, et un diagramme de blocs internes IBD), le comportement (avec un diagramme de s équence SD), et les exi-gences (avec un diagramme des exiexi-gences), des SBC (voir les diagrammes utilis és dans la figure 1.11). Ces diagrammes sont ensuite transform és automatiquement au niveau formel pour les prendre en consid ération dans la v érification de l’as-semblage des composants en exploitant le formalisme des automates d’interface (travaux pr ésent és dans le chapitre 2). Ces travaux concernent certaines parties des th èses encadr ées [Roz15, Bou16] et les publications [CH11a, BCHM19]. — Assemblage des composants guid é par SysML : Pour r épondre à la

probl ématique(I2), nous avons propos é une approche incr émentale pour construire un SBC en partant d’une sp écification abstraite du syst ème global, d écrit par des diagrammes SysML. Le syst ème est construit progressivement en s électionnant des composants ad équats tels que leur composition respecte les contraintes d éfinies dans la sp écification abstraite. La v érification de ces contraintes est ef-fectu ée en sp écifiant et v érifiant une relation de raffinement entre les interfaces des composants. Les outils Ptolemy [LX04] et MIO Workbench [BMSH10] sont utilis és

(20)

1.3. CONTRIBUTIONS 9

pour v érifier respectivement la compatibilit é et le raffinement des interfaces (voir dans la figure 1.1 (1)). Cette contribution exploite les r ésultats de la contribution pr éc édente, elle est également en lien avec la probl ématique (M1). Ces travaux sont r ésum és dans le chapitre 2. Ils concernent une partie de la th èse encadr ée [Roz15] et la publication [CCM12a].

— Construction incr émentale de l’architecture d’un SBC guid ée par les exi-gences SysML : Pour r épondre à la probl ématique (M2), nous avons propos é une approche pour construire l’architecture d’un SBC d’une mani ère incr émentale en analysant son diagramme des exigences SysML (fonctionnelles). Ces derni ères sont v érifi ées une par une, sur le comportement des composants él émentaires, en utilisant le Model-Checker SPIN (voir la figure 1.1 (2)). Les composants v érifi és sont ensuite int égr és dans l’architecture partielle du syst ème apr ès avoir v érifi é leur compatibilit é gr âce à leurs automates d’interface (voir la figure 1.1 (3)). Ces travaux rentrent dans le cadre de la th èse [Roz15] et sont synth étis és dans le chapitre 4. Ils sont publi és dans [CCM13a, CCM13b]. Dans [CCM13b], nous avons également propos é une approche pour v érifier l’assemblage des composants en consid érant des exigences non-fonctionnelles sp écifi ées avec SysML.

— G én ération automatique des adaptateurs lors de la conception des SBC mod élis és avec SysML : Pour r épondre à la probl ématique (A1), nous avons propos é une approche pour g én érer automatiquement un adaptateur permettant aux composants, mod élis és avec SysML, d’interagir malgr é l’incoh érence exis-tante entre les noms de leurs services échang és. La g én ération de l’adaptateur est guid ée par les sp écifications SysML du composite à d évelopper (sp écification initiale du syst ème, sous forme d’un composite), initialement d éfini par le concep-teur. Notre approche se distingue par rapport aux travaux existants par son exploitation des mod èles semi-formels (SysML) et formels (automates d’inter-face), pour traiter les incoh érences entre les composants et corriger leur incom-patibilit é gr âce à l’adaptation. Ces travaux concernent une partie de la th èse [Bou16] et sont pr ésent és dans le chapitre 3. Ils sont publi és principalement dans [BCZ15, BCHM16b].

Conception rigoureuse de syst èmes critiques à base de composants orient és ob-jet : Pour r épondre à la probl ématique (I3), nous avons propos é une d émarche pour d évelopper des SBC corrects par la conception en exploitant leurs interfaces sp écifi ées par des contrats comportementaux. Ce formalisme est bas é sur les automates d’inter-face enrichis avec la s émantique des m éthodes (voir la figure 1.22_{). Nous avons donc}

propos é un cadre formel pour d éfinir et v érifier l’interop érabilit é des composants orient és objet (utilis és dans le domaine des transports). Nous avons également d éfini la rela-tion de raffinement des composants, pour v érifier leur impl émentabilit é ind épendante (ou leur substituabilit é). Autrement dit, v érifier si les interfaces des composants compatibles peuvent être raffin ées s épar ément tout en maintenant leur compatibilit é. Les études de cas trait ées dans ces travaux concernent le domaine des transports, en particulier celui du ferroviaire. Et enfin, pour r épondre à la probl ématique(A2), nous avons propos é une approche d’adaptation des composants, d écrits par leurs contrats comportementaux et pr ésentant des inad équations entre leurs services échang és. Ces travaux concernent, en partie, la th èse [Mou11] et sont pr ésent és dans le chapitre 5. Ils sont principalement publi és dans [CMM10e, MCM09, MACM15b, CMM12a, CMM10b].

(21)

Composant 1 Composant 2 IA1 IA2 Compatibilité ? Adaptation ? Composant 2 raffiné IA’2 Substitution Intégration de la sémantique des opérations

FIGURE1.2 – Assemblage des composants bas ´e sur les Automates d’interfaces

Exploitation de la m éthode B pour sp écifier les interfaces des composants et v érifier leur assemblage : Pour r épondre à la probl ématique(I1), nous avons propos é, dans [CHS06], une approche pour sp écifier formellement les interfaces des composants en utilisant le formalisme de la m éthode B. En se basant sur les sp écifications des inter-faces, nous avons montr é qu’il est possible d’utiliser la m éthode B, et particuli èrement, son raffinement pour prouver formellement la compatibilit é des composants aux niveaux signature et s émantique de leurs op érations. Dans [Cho06], nous avons étendu ce travail pour consid érer, en plus, les protocoles des composants dans la v érification de l’assem-blage. Le chapitre 6 pr ésente ces travaux.

Transformation automatique des protocoles de coordination Reo vers Promela pour v érifier leurs propri ét és : Depuis fin 2017, je travaille sur la sp écification et la v érification des protocoles de coordination dans les syst èmes à base de composants/ser-vices, en collaboration avec le groupe m éthodes formelles (avec le Professeur F.Arbab) du centre de recherche en informatique d’Amsterdam CWI. Ainsi, pour r épondre à la probl ématique (C1), nous avons propos é une approche permettant de traduire automa-tiquement les protocoles de coordination sp écifi és avec le langage Reo (d évelopp é au CWI), en Promela, afin de v érifier des propri ét és temporelles avec le Model-Checker SPIN. Ce travail rentre dans le cadre de la th èse de Benjamin Lion du CWI. Il est pr ésent é dans le chapitre 7.

V érification de protocoles de communication dans le domaine des v éhicules au-tonomes/communicants : Depuis 2017, je collabore avec des coll ègues de l’ équipe AND (Algorithmique Num érique Distribu ée) du DISC (FEMTO-ST) et le Professeur A.Boukerche de l’universit é d’Ottawa (Canada), sur l’utilisation des approches formelles pour la validation des protocoles de communication dans les v éhicules autonomes et/ou communicants (et aussi dans le domaine des r éseaux de capteurs). Ce qui repr ésente pour moi une ouverture vers de nouvelles th ématiques de recherche. Dans ce cadre, nous avons obtenu des premiers r ésultats prometteurs (qui ne sont pas d étaill és dans ce manuscrit mais accessibles par les articles r éf érenc és ci-dessous) :

(22)

1.4. MES PUBLICATIONS 11

MQTT (Message Queuing Telemetry Transport), utilis é dans les applications IOT (internet des objets) pour les v éhicules communicants, et propos é une approche pour le v érifier formellement [CBM17b].

— V érification de l’interaction des composants en consid érant leur consommation de l’ énergie dans les v éhicules autonomes : nous avons adapt é le formalisme des automates d’interface pour mod éliser et v érifier le protocole d’interaction entre les diff érents composants dans un v éhicule autonome en consid érant les contraintes de la consommation de l’ énergie [CBM17a] (papier, best short paper de la conf érence MSWIM, class ée A).

— Proposition d’une nouvelle approche d’agr égation de donn ées en s érie, dans les r éseaux de capteurs, permettant d’optimiser les chemins parcourus et aussi de r éduire les communications entre les capteurs [MBMC19].

1.4/

M

ES PUBLICATIONS

La liste ci-dessous synth étise les publications auxquelles j’ai particip é depuis 2005, ann ée de mon recrutement en tant qu’enseignant chercheur.

— Journaux internationaux (8) : [BCHM19, MBMC19, CHM13, CCM12a, CH11b, CMM10e, CHS06, CJMB05]

— Journaux nationaux (3) : [BCHM16a, CMM12a, CDH+10]

— Conf ´erences internationales (22) : [FMCB19, LCA18, CMM18, DBMC17, CBM17b, CBM17a, MMC17, BCHM16b, BCZ15, MACM15b, BCHM15a, CCM13a, CCM13b, HMC13b, HMC13a, CMM10b, MCM11, MCM09, CMM10c, SC05, BCJ05, Cho06]

— Conf ´erences nationales (5) : [BCHM15b, CCM14b, CCM12b, CMM10a, CMM10d]

(23)

(24)

II

C

ONCEPTION INCR

EMENTALE DES SYST

´

EMES

`

A BASE DE COMPOSANTS GUID

EE PAR

´

S

YS

ML

(25)

(26)

2

M ´

ETHODOLOGIE POUR L

’

ASSEMBLAGE

DE COMPOSANTS GUID

EE PAR

´

S

YS

ML

2.1/

I

NTRODUCTION

Ce chapitre pr ésente notre m éthodologie permettant à l’architecte d’un SBC de le mod éliser avec SysML et de v érifier formellement l’assemblage de ses composants. Ainsi, nous proposons de combiner des mod èles SysML et le formalisme des automates d’interface afin de v érifier formellement l’assemblage des composants sp écifi és avec des diagrammes SysML. Pour cela, nous proposons, tout d’abord, de mod éliser l’architecture d’un SBC avec un ensemble de mod èles SysML, qui sont ensuite traduits automatique-ment vers des mod èles formels, qui sont à leur tour exploit és pour v érifier l’assemblage des composants constituant le syst ème global. Ce qui nous permet de valider ou de corriger l’architecture propos ée. Par ailleurs, nous proposons également une approche pour construire un SBC en se basant sur sa sp écification abstraite. C’est à dire, nous commençons la conception du syst ème, à d évelopper, par sa sp écification SysML abs-traite, d écrivant sa structure et son comportement, et nous proposons ensuite un en-semble de composants r éutilisables, telles que leur composition v érifie les contraintes impos ées par la sp écification de d épart. Nous exploitons une relation de raffinement entre les interfaces des composants pour v érifier la coh érence entre le niveau abstrait et le niveau concret du syst ème.

Dans les approches propos ées, la conception du syst ème se fait d’une mani ère incr émentale : nous proposons d’assembler les composants d’un syst ème progressi-vement, et gr âce à l’approche des automates d’interface, nous avons la possibilit é de v érifier l’assemblage des composants pour une vue partielle du syst ème sans connaˆıtre les interfaces de tous les composants.

Ce chapitre est structur é de la mani ère suivante. La section 2.2 porte sur les travaux connexes et nos contributions. Dans la section 2.3, nous pr ésentons le formalisme des automates d’interface. Dans la section 2.4, nous montrons comment mod éliser l’archi-tecture d’un SBC avec SysML. Dans la section 2.5, nous pr ésentons nos travaux pour le passage des mod èles SysML sp écifiant les protocoles des composants vers les auto-mates interfaces. La section 2.6 est d édi ée à la v érification de l’assemblage de l’ensemble des composants constituant le SBC d écrit avec SysML, en exploitant le formalisme des automates d’interface. Notre approche pour construire un SBC par raffinement est d écrite dans la section 2.7. Nous terminons ce chapitre par une conclusion et un bilan pr ésent és respectivement dans les sections 2.8 et 2.9.

(27)

2.2/

E

´

TAT DE L

’

ART ET CONTRIBUTIONS

Plusieurs travaux existent dans la d érivation des mod èles formels à partir des mod èles semi-formels comme UML et SysML. Par exemple, les auteurs dans [KBSB10, RF06, Wan08, ES09, Mer14] se sont focalis és sur la transformation des diagrammes de s équence vers des r éseaux de Petri ou des r éseaux de Petri color és, en adoptant di-verses m éthodes. Une approche permettant de v érifier des diagrammes de s équence avec le Model-Checker SPIN, a également ét é propos ée dans [LTM+09]. Contrairement à ces travaux, dans notre cas, nous proposons de g én érer des automates d’interface à partir des diagrammes de s équence en vue de v érifier l’assemblage des composants. Il existe également quelques travaux exploitant d’autres diagrammes SysML dans le but de v érifier formellement des propri ét és. Par exemple, dans [JDB09], les auteurs pro-posent une syntaxe et une s émantique formelle pour les diagrammes d’activit é SysML. Leur contribution principale est la d éfinition du langage appel é Activity Calculus, avec une s émantique op érationnelle formelle. Ce qui permet de d étecter des erreurs de conception d és le d ébut du processus de d éveloppement. Les diagrammes d’activit é ont également ét é consid ér és dans [OMD13, OMD14], o ù les auteurs proposent une approche permet-tant de v érifier formellement ces diagrammes avec le Model-Checker PRISM [KNP11]. Cet outil a ét é également exploit é dans [Ali18] pour v érifier des syst èmes embarqu és, mod élis és principalement avec le diagramme de blocs SysML . Dans [CMC+08], les au-teurs proposent une solution pour la mod élisation et la v érification de syst èmes em-barqu és en temps r éel avec des contraintes d’ énergie. Pour cela, ils combinent les fonctionnalit és des mod èles SysML et des annotations du profil MARTE avec les avan-tages d’utiliser l’outil Time Petri Net. Ce formalisme permet l’analyse et la v érification des exigences fonctionnels, temporels et énerg étiques dans les premi ères phases du d éveloppement. Dans [KAdSS11], les auteurs pr ésentent TEPE (TEmporal Property Ex-pression), un langage graphique, bas é sur des diagrammes param étriques SysML, pour l’expression des propri ét és. Ces derni ères sont construites sur des relations logiques et temporelles entre les attributs et les signaux des blocs. TEPE peut être int égr é à un profil temps r éel de SysML comme AVATAR. Ce dernier est un profil orient é v érification, per-mettant d’exprimer et de v érifier des propri ét és temporelles. Il est support é par la boˆıte à outils open source TTool. Elle comprend un éditeur de diagramme, un g én érateur de code UPPAAL et une interface de bouton-poussoir pour la v érification formelle. Contrairement à notre approche, ces travaux ne se situent pas dans le contexte du d éveloppement des SBC, donc les questions li ées à l’interop érabilit é des composants ne sont pas trait ées.

Contributions : L’originalit é de notre approche par rapport aux travaux pr ésent és, est la connexion formelle entre des mod èles SysML, sp écifiant l’architecture des SBC, et le for-malisme des automates d’interface, pour v érifier l’interop érabilit é des sous-composants dans le syst ème complet. Notre proposition est, à notre connaissance, la seule contribu-tion proposant de concevoir des SBC en exploitant les notacontribu-tions SysML et le formalisme des automates d’interface. Ainsi, nous proposons des moyens aux concepteurs de SBC, pour exploiter SysML afin de concevoir rigoureusement leurs syst èmes. En outre, nous proposons deux d émarches de conception : l’une permet l’assemblage des composants selon une architecture SysML d éfinie, pour construire le syst ème global, l’autre repose sur une sp écification abstraite du syst ème à construire, et propose de s électionner, en v érifiant une relation de raffinement, un ensemble de composants tels que leur

(28)

composi-2.3. FORMALISME DES AUTOMATES D’INTERFACE 17

tion respecte les contraintes impos ´ees par la sp ´ecification abstraite.

2.3/

F

ORMALISME DES AUTOMATES D

’

INTERFACE

Les automates d’interface (IAs) ont ét é introduits par Luca de Alfaro et Thomas Hen-zinger [dAH01, AH05, AH01] pour sp écifier les interfaces des composants, dans le but de v érifier leur compatibilit é en consid érant leurs protocoles d’interaction. Ces protocoles sont d écrits par des s équences d’actions, d écompos ées en trois sous ensembles : les actions d’entr ée (identifi ées par ’ ?’), de sortie (identifi ées par ’ !’), et internes (identifi ées par ’ !’).

D éfinition 2.1 (Automate d’interface). Un automate d’interface A est repr ésent é par le tuple h SA, ıA,ΣI_A,ΣO_A,ΣH_A, δA itel que :

— SAest l’ensemble fini d’ ´etats. A est dit ”vide” si SA = ∅.

— ıA∈ SA est l’ ´etat initial.

— ΣI A, Σ

O A etΣ

H

A repr ´esentent, respectivement, les ensembles des actions d’entr ´ee, de

sortie, et internes. L’ensemble des actions de A est not ´e parΣA = ΣI_A∪ΣO_A∪ΣH_A. Ces

ensemble sont mutuellement disjoints.

— δA⊆ SA×ΣA× SA est l’ensemble des transitions.

2.3.1/ L’APPROCHE OPTIMISTE POUR LA VERIFICATION DE LA COMPATIBILIT´ E´

Pour assembler correctement deux composants, C1et C2, sp ´ecifi ´es respectivement avec

leurs automates d’interface, A1 et A2, il est n écessaire de v érifier leur compatibilit é en

calculant leur composition. Elle est r éalis ée en synchronisant leurs actions partag ées d’entr ée/sortie (calcul de leur produit synchrone). Cette composition peut contenir des états bloquants, dans lesquels l’un des deux automates sollicite une action d’entr ée qui n’est pas accept ée par l’autre (concr ètement, un composant qui demande un service qui n’est pas disponible dans l’autre). Dans l’approche des automates d’interface la compati-bilit é est établie s’il existe au moins un environnement avec lequel C1et C2 interagissent

sans blocage. Donc la pr ésence d’un état bloquant n’est pas une preuve suffisante pour d écider de leur incompatibilit é. En effet, il suffit de trouver un environnement, appel é l égal, donc un troisi ème composant C3, sp écifi é avec l’automate A3 tel que ce dernier

active uniquement certaines actions d’entr ´ee dans la composition de A1et A2, permettant

d’ éviter leurs états bloquants. Cependant, les deux automates sont dits incompatibles s’il n’y a aucun environnement permettant d’ éviter que leur composition atteigne des états bloquants. Cette approche est consid ér ée optimiste contrairement à certaines approches, comme celle pr ésent ée dans [BMSH10], dites pessimistes, qui d écide de l’incompatibilit é de deux composants, si au moins un état bloquant est d étect é dans leur produit syn-chrone. Lors de la conception des SBC, la vision optimiste est plus naturelle, car plus adapt ée à la construction incr émentale des syst èmes, ce qui justifie notre choix pour le formalisme des automates d’interface.

La v érification de la compatibilit é de A1 et A2 dans l’approche optimiste est effectu ée en

(29)

1. v ´erifier que A₁ et A2sont composables ;

2. calculer le produit synchrone A1⊗ A2;

3. calculer l’ensemble des ´etats bloquants dans A1⊗ A2;

4. calculer l’ensemble des états incompatibles dans A1 ⊗ A2 : les états à partir

des-quels l’environnement ne peut pas éviter d’atteindre les états bloquants en une ou plusieurs étapes ;

5. calculer A1k A2 en enlevant de A1⊗ A2, les ´etats bloquants, les ´etats incompatibles

et les états non atteignables à partir de l’ état initial ;

6. si A1k A2n’est pas vide alors A1et A2sont compatibles, sinon ils sont incompatibles.

L’algorithme pour calculer la composition de deux automates d’interface A1 et A2 (dont

les étapes sont d écrites ci-dessus), est d’une complexit é lin éaire par rapport à la taille du produit des deux automates [dAH01]. Cet algorithme est impl ément é dans l’outil Ptolemy [LX04], d évelopp é à l’universit é de Berkeley.

Les étapes de cet algorithmes sont d étaill ées dans la section suivante.

2.3.2/ COMPOSABILITE´, COMPATIBILITE ET COMPOSITION´

Avant de calculer le produit synchrone de deux automates d’interface, il faut v ´erifier leur composabilit ´e.

D ´efinition2.2(Composabilit ´e). Deux automates d’interface A1et A2sont composables si

ΣI A1 ∩Σ I A2 = Σ O A1 ∩Σ O A2 = Σ H A1∩ΣA2 = ΣA1 ∩Σ H A2 = ∅.

Nous notons par S hared(A1, A2) = (ΣIA1∩Σ

O A2)∪(Σ

I A2∩Σ

O

A1) l’ensemble des actions partag ´ees

par A1et A2.

D ´efinition2.3(Produit synchrone ⊗). Soient A1et A2deux automates d’interface

compo-sables, le produit synchrone de A₁et A₂ est l’automate d’interface A₁⊗ A2d ´efini par

— SA1⊗A2 = SA1× SA2 et ıA1⊗A2 = (ıA1, ıA2) ; — ΣI A1⊗A2 = (Σ I A1∪Σ I A2) \ S hared(A1, A2) ; — ΣO_A 1⊗A2 = (Σ O A1∪Σ O A2) \ S hared(A1, A2) ; — ΣH_A 1⊗A2 = Σ H A1 ∪Σ H A2 ∪ S hared(A1, A2) ; — ((s1, s2), a, (s0₁, s0₂)) ∈ δA1⊗A2 si — a < S hared(A1, A2) ∧ (s1, a, s0₁) ∈ δA1 ∧s2= s 0 2ou — a < S hared(A1, A2) ∧ (s2, a, s0₂) ∈ δA2 ∧s1= s 0 1ou — a ∈ S hared(A1, A2) ∧ (s1, a, s0₁) ∈ δA1 ∧ (s2, a, s 0 2) ∈ δA2.

L’incompatibilit ´e entre deux automates d’interface A1 et A2 pourrait se produire `a cause

de l’existence des ´etats (s1, s2) dans le produit A1⊗ A2tels qu’il existe au moins une action

a dans S hared(A1,A2) activable `a partir de s1 et elle ne l’est pas `a partir de s2 ou vice

(30)

2.4. SP ´ECIFICATION DE L’ARCHITECTURE D’UN SBC AVEC SYSML 19

D ´efinition2.4_{( ´}_{Etats bloquants)}_{. L’ensemble des ´etats bloquants Dead(A}

1, A2) ⊆ SA1× SA2

dans A1⊗ A2 est d ´efini par {(s1, s2) ∈ SA1 × SA2 | ∃ a ∈ S hared(A1, A2) telle que la condition

suivante est satisfaite : (a ∈ΣO

A1(s1) ∧ a < Σ I A2(s2)) ∨(a ∈Σ O A2(s2) ∧ a < Σ I A1(s1)) }

Pour d ´ecider de la compatibilit ´e de A1 et A2, il faut pour prouver l’existence d’un

environ-nement l égal, sans pour autant le d éfinir. Pour cela, il suffit de calculer la composition de A1 et A2 [AH05] et de montrer qu’elle n’est pas vide. Cette composition est calcul ée en

enlevant de l’ensemble des transitions du produit toutes les transitions étiquet ées avec une action d’entr ée, qui ont un état cible incompatible ( état permettant d’atteindre les états bloquants) [AH05]. Autrement dit, on obtient la composition en limitant le produit A₁⊗ A2, à l’ensemble des états compatibles et atteignables, not é Cmp(A1, A2), apr ès la

suppression des états incompatibles. Cet ensemble contient les états dans lesquels les états bloquants ne sont pas atteignables en activant des actions de sortie ou internes (parce qu’elles sont localement contr ôlables par le composant).

D ´efinition2.5_{(Composition k)}_{. La composition A}

1k A2est l’automate d’interface tel que :

— SA1kA2 = Cmp(A1, A2) ; — ıA1kA2 = (ıA1, ıA2), ıA1kA2 ∈ SA1kA2; — ΣI A1kA2 = Σ I A1⊗A2,Σ O A1kA2 = Σ O A1⊗A2, etΣ H A1kA2 = Σ H A1⊗A2;

— δA1kA2 = δA1⊗A2 ∩ (Cmp(A1, A2) ×ΣA1kA2 × Cmp(A1, A2)).

D ´efinition 2.6 _{(Compatibilit ´e)}_{. A}

1 et A2 sont compatibles s’ils sont composables et si

A1k A2, ∅

2.4/

S

PECIFICATION DE L

´

’

ARCHITECTURE D

’

UN

SBC

AVEC

S

YS

ML

Dans cette section, nous pr ésentons nos mod èles SysML pour sp écifier l’architecture d’un SBC. Cette proposition tient compte de la d éfinition du langage SysML à partir de la version 1.3, et des caract éristiques d’un SBC.

Pour illustrer notre proposition, nous pr ésentons l’ étude de cas d’une voiture CyCab, qui est un syst ème à base de composants ([BGMPG99]), d évelopp é par l’INRIA1, et consid ér é comme étude de cas dans le projet ANR TACOS. Le CyCab est un petit v éhicule, électrique et automatique, utilis é comme moyen de transport conçus essen-tiellement pour le transport autonome. Il permet aux utilisateurs de se d éplacer via un ensemble de stations pr éinstall ées. Il est totalement contr ôl é par un syst ème informa-tique et peut être pilot é automainforma-tiquement selon de nombreux modes. Pour illustrer notre approche, nous consid érons les contraintes suivantes :

— Un CyCab a une route d édi ée o ù les stations sont équip ées de capteurs et d’unit és de calcul. Il n’y a pas d’obstacle sur la route.

— Nous proposons que la conduite du CyCab soit guid ´ee par les informations rec¸ues des stations, ce qui permet de localiser le CyCab par rapport aux stations.

— Le v éhicule est activ é par le composant de d émarrage (Starter ). Le v éhicule est également dot é d’un bouton d’arr êt d’urgence, associ é au composant d’arr êt d’ur-gence (Emergency Halt (EH)). Le bouton d’arr êt d’urd’ur-gence peut être activ é à tout moment pendant les mouvements du CyCab.

(31)

Le CyCab est un syst ème compos é de deux composants composites : le v éhicule et la station. Le v éhicule est, à son tour, compos é des composants él émentaires : Vehicle Core, Starter et EH. La station est compos ée des composants : Sensors (capteurs) et CU (unit é de calcul).

Donc pour sp écifier l’architecture d’un SBC, en l’occurrence ici le CyCab, nous proposons d’utiliser les diagrammes SysML suivants : le bloc, le diagramme de d éfinition de blocs (BDD), le diagramme de blocs internes (IBD), et le diagramme de s équence.

Le bloc : Permet de d éfinir un composant en d écrivant, ses op érations internes, comme op érations priv ées du bloc, et aussi ses services requis et offerts (sous forme d’op érations également), de la façon suivante. Chaque bloc est d écor é par deux ports proxy : un port d’entr ée pour d écrire les services offerts qui sont list és dans un bloc d’in-terface qui d éfini le type du port, et un port de sortie pour d écrire de la m ême mani ère les services requis. Par ailleurs, nous distinguons deux types de blocs : les composites et les él émentaires. Par exemple dans la figure2.1, est pr ésent é le bloc composite Station et ses sous-blocs él émentaires Sensors et CU. Dans la m ême figure, nous constatons également que le bloc Sensors reçoit des informations de la position du v éhicule via l’op ération spos() sur son port d’entr ée ps in, comme indiqu é dans le bloc d’interface IinSensors, et renvoie la position g éographique calcul ée via un appel à l’op ération pos() d écrite dans le bloc d’interface IoutSensors

Le BDD : Permet de d écrire la structure du syst ème ou d’un bloc composite, en exhi-bant les relations de hi érarchie entre ses blocs (relation de composition). Par exemple, la figure 2.1 repr ésente le BDD du bloc composite Station, qui est reli é par des relations de composition avec ses sous-blocs. Le BDD complet du CyCab est pr ésent é dans notre papier [CH11b].

FIGURE2.1 – Le BDD du bloc composite Station

IBD : Permet au concepteur d’affiner l’architecture du syst ème en d étaillant les in-teractions entre les sous-blocs dans un bloc composite. Dans l’IBD, les parties (parts) correspondent aux sous-blocs. L’interaction entre les sous-blocs est mod élis ée par des connecteurs entre leurs ports. Par exemple dans la figure 2.2, nous sp écifions la com-position interne du bloc Station en montrant l’interaction entre les sous-blocs Sensors et CU. Ils sont li és via un connecteur entre le port ps out du bloc Sensors et le port pcu in du bloc CU.

(32)

2.5. D ´ERIVATION AUTOMATIQUE DES AUTOMATES D’INTERFACE `A PARTIR DE SYSML21

FIGURE2.2 – Le IBD du bloc Station

Le diagramme de s équence : Permet de repr ésenter les protocoles d’interaction entre chaque composant et son environnement (les autres composants), sous forme d’une s équence d’ échanges de messages. Nos diagrammes de s équence doivent être com-pos és de deux lignes. Une repr ésentant le comcom-posant, et une autre pour l’environnement. Par exemple, dans la figure 2.3, est mod élis é le diagramme de s équence du composant Sensors mod élisant son protocole d’interaction. Ce composant reçoit le message spos() de l’environnement, repr ésentant les informations de la position du v éhicule, et renvoie ensuite le message pos(), indiquant les coordonn ées g éographiques, à l’unit é de calcul (CU), repr ésent ée par l’environnement.

FIGURE2.3 – Le diagramme de s ´equence du bloc Sensors

2.5/

D ´

ERIVATION AUTOMATIQUE DES AUTOMATES D

’

INTERFACE A

`

PARTIR DE

S

YS

ML

Dans cette section, nous pr ésentons notre d émarche pour la d érivation des automates d’interface à partir des diagrammes de s équence sp écifiant les protocoles des compo-sants. Nous proposons une approche de transformation de mod èles exploitant Atlas Transformation Language (ATL) [atl], qui repose principalement sur la m éta-mod élisation [dLVA04] et les transformations de m mod èles [CH03]. Elle consiste à d éfinir les m éta-mod èles des éta-mod èles source et cible, puis à sp écifier les correspondances entre eux dans le m éta-niveau. Pour automatiser la transformation, nous avons d éfini un ensemble de r ègles ATL permettant d’effectuer cette transformation.

(33)

FIGURE2.4 – Illustration de notre approche.

s équence des composants, et gr âce à un ensemble de r ègles ATL, d éfinies sur les m éta-mod èles des diagrammes de s équence et des automates d’interface, nous obtenons les automates d’interface correspondant aux diagrammes de s équence. Ensuite pour v érifier la compatibilit é des composants, nous proposons de g én érer automatiquement, gr âce à un ensemble de mod èles Acceleo [acc], les sp écifications d’entr ée pour l’outil Ptolemy pour la v érification de la compatibilit é.

M éta-mod èle : Dans la figure 2.5, est pr ésent é le m éta mod èle des automates d’inter-face. Ainsi, chaque automate d’interface est compos é d’un ensemble d’ état et transitions. Les ports Inport et outport sont associ és respectivement aux actions d’entr ée et de sor-tie. Le m éta mod èle des diagramme de s équence n’est pas pr ésent é ici (disponible dans [BCHM19]). Interface Automaton name Transition action State name type Inport name Outport name states 0..* transitions 0..* inports 0..* outports 0..* StateType Initial NotInitial source target

FIGURE2.5 – Le m ´eta mod `ele d’un automate d’interface.

R ègles ATL : Pour traduire le mod èle source correspondant à un diagramme de s équence vers le mod èle cible correspondant à un automate d’interface, nous avons d éfini un ensemble de r ègles ATL permettant l’automatisation de cette transformation. Ces r ègles permettent de d éfinir l’ensemble des états, de transitions, et des actions d’un automate d’interface, en transformant les él éments constitutifs d’un diagramme de

(34)

2.6. V ÉRIFICATION DE L’ASSEMBLAGE DANS UN SBC MOD ÉLIS É AVEC SYSML 23

s équence. Par exemple, ci-dessous est pr ésent ée une des r ègles ATL (l’ensemble des r ègles est pr ésent é dans [BCHM19]) :

— Rule : Message2Transition

Cette r ègle permet de cr éer une transition pour chaque message échang é entre un bloc et son environnement, d écrit dans le diagramme de s équence. Cette transition sera étiquet ée avec l’action mes, correspondant au nom du message. Et, en fonc-tion de la posifonc-tion du message, la transifonc-tion sera typ ée en tant qu’acfonc-tion d’entr ée, de sortie ou interne.

rule message2Transition{

from mes : SD!Message, mos : SD!MessageOccurrenceSpecification . (mos.getCovered().name <> ’ENV’ )

to t : IA!Transition ( action <- mes.name.concat(

if(mes.sendEvent.getCovered()=mes.receiveEvent.getCovered())then ’;’ else if (mes.sendEvent=mos)then ’!’ else ’?’endif endif), source <- thisModule.resolveTemp(mos, ’s’),

target <- thisModule.resolveTemp(

thisModule.NextMsgOcSpec(mos.getCovered(), mos), ’s’) )}

Templates Acceleo pour Ptolemy : Apr ès avoir d ériv é les automates d’interface du diagramme de s équence, nous proposons un ensemble de templates Acceleo pour g én érer automatiquement la sp écification d’entr ée Ptolemy, afin de v érifier la compatibi-lit é des composants. En analysant un fichier d’entr ée de Ptolemy sp écifiant un automate d’interface, nous avons d éfini six templates Acceleo permettant de cr éer automatique-ment le fichier de la sp écification Ptolemy. Ces derniers sont d étaill és dans notre papier [BCHM19] et la th èse [Bou16].

En appliquant notre approche sur les diagrammes de s ´equence des bloc Sensors et CU, on obtient leurs automates d’interfaces respectifs illustr ´es dans la figure 2.6.

FIGURE2.6 – Les automates d’interface des sous-composants Sensors et CU

2.6/

V ´

ERIFICATION DE L

’

ASSEMBLAGE DANS UN

SBC

MODELIS

´

E

´

AVEC

S

YS

ML

Dans cette section, nous pr ésentons notre approche pour v érifier la compatibilit é d’un ensemble de composants qui forment un SBC dont l’architecture est d écrite avec SysML. Cette approche exploite les travaux pr ésent és pr éc édemment, et prend donc en consid ération les protocoles d’interaction sp écifi és avec des diagrammes de s équence et

(35)

traduits en automates d’interface. Elle exploite également les mod èles formels des BDD et IBD, que nous pr ésentons dans la section suivante.

2.6.1/ MODELES FORMELS DES DIAGRAMMES` SYSMLSPECIFIANT L´ ’ARCHITEC

-TURE D’UNSBC

Pour pouvoir analyser automatiquement l’architecture d’un SBC, sp écifi ée avec SysML, afin de v érifier l’assemblage de l’ensemble de ses composants, nous proposons les mod èles formels pour sp écifier l’ensemble des diagrammes SysML utilis és pour sp écifier l’architecture. Nous allons ainsi d éfinir formellement le bloc, le diagramme de d éfinition de blocs, le bloc d’interface, et le diagramme de blocs internes. Ces mod èles sont ex-ploit és par notre algorithme de v érification de l’assemblage des composants, d écrit dans la section 2.6.2.

D éfinition 2.7 (BDD). Un mod èle formel pour le BDD d’un syst ème S est : BDDS =

hIBS, S BS, S ubBSio `u :

— IBS : est le bloc initial du syst `eme ;

— S BS : est l’ensemble de blocs ;

— la fonction S ubBS : S BS → 2S BS qui associe `a chaque bloc son ensemble de

sous-blocs.

D ´efinition 2.8 (Port d’un bloc). Un port d’un bloc SysML, P, est d ´efini par le tuple hnameP, typeP, directionPi, tel que :

— nameP est le nom du port,

— typeP est le nom du bloc d’interface qui type le port,

— directionP indique la nature du port : in pour un port d’entr ´ee et out pour un port de

sortie. Nous notons par P.direction la direction du port.

Pour la d éfinition suivante, nous avons besoin de consid érer l’ensemble IntB qui repr ésente les blocs d’interface.

D ´efinition 2.9 (Bloc SysML). Un bloc SysML B est un tuple hnameB, OpB, PinB, PoutB, T ypePortBi, tel que :

— nameB est le nom du bloc,

— OpBest l’ensemble fini des op ´erations priv ´ees dans B,

— PinBle port proxy d’entr ´ee de B,

— PoutBle port proxy de sortie de B.

— La fonction T ypePortB : {PinB, PoutB} → IntB, qui d ´etermine l’interface qui d ´efinit le

type de chaque port.

Nous notons par B.name, B.Op, B.Pin, et B.Pout, respectivement, le nom du bloc B, son

(36)

2.6. V ÉRIFICATION DE L’ASSEMBLAGE DANS UN SBC MOD ÉLIS É AVEC SYSML 25

D ´efinition2.10 _{(Bloc d’interface)}_{. Soit B un bloc SysML et P}

x un port de B, o `u x prend la

valeur de in pour un port d’entr ée, et out pour un port de sortie. Un bloc d’interface de B, tel que B d éfinit le type du port Px, et repr ésente l’interface requise ou fournie de B, est

d ´efini par I xB = hnamexB, OpxBi, tel que namexB est le nom de l’interface, et OpxB d ´efinit

l’ensemble des services requis par B quand x = out, et dans le cas contraire (x = in) il d ´efinit l’ensemble des services fournis.

Soit I un bloc d’interface, nous notons par I.Op l’ensemble des op ´erations d ´efinies dans I.

Par exemple, dans la figure 2.1,l’interface requise du bloc CU est IoutCU, telle que IoutCU.Op = { f ar(), halt()}. Son interface offerte est IinCU, telle que IinCU.Op = {pos()}. D ´efinition 2.11 _(IBD)_{. Soit S etB}

B = S ubBB(B) l’ensemble des sous-blocs du bloc B. Le

diagramme de blocs internes de B, est le tuple

IBDB =h PartsB, BlockPartB, PortsB, PextinB,PextoutB, PinPartB, PoutPartB, ConnectorsinB,

ConnectorsoutB itel que :

— PartsB est l’ensemble des parties (Parts), tel que chaque partie repr ´esente une

instance d’un sous-bloc dans B.

— La fonction BlockPartB : PartsB → S etBB d ´etermine pour chaque Part dans l’IBD

son bloc.

— PortsBest l’ensemble des ports associ ´es aux parties dans l’IBD.

— PextinBet PextoutBsont respectivement le port ext érieur d’entr ée et le port ext érieur

de sortie.

— La fonction PinPartB : PartsB→ PortsB d ´etermine le port d’entr ´ee pour chaque Part

dans l’IBD. Et la fonction PoutPartB : PartsB → PortsB d ´etermine le port de sortie

pour chaque Part dans l’IBD.

— ConnectorsinB= {(pi, pj) tel que (pi, pj) ∈ PortsB× PortsB∧ pi.direction , pj.direction},

l’ensemble des connecteurs internes qui relient les sous-blocs. Ils sont ´egalement appel ´es connecteurs d’assemblage.

— ConnectorsoutB = {(pi, pj) tel que (pi, pj) ∈ Ports × Ports ∧ pi.direction = pj.direction},

l’ensemble des connecteurs qui relient les ports des sous-blocs (parties) avec les ports du bloc composite. Ils sont appel és connecteurs de d él égation.

Les d éfinitions du BDD et de l’IBD sont exploit ées dans l’algorithme de la section sui-vante, pour identifier et assembler les sous-composants connect és dans le syst ème glo-bal ou dans un composant composite. Les autres d éfinitions sont exploit ées dans la sec-tion 2.7 et les chapitres suivants.

2.6.2/ ALGORITHME DE VERIFICATION´

L’algorithme 1, S ysCompos, exploite les mod èles formels d écrits dans la section pr éc édente et l’approche des automates d’interface pour v érifier l’assemblage de l’en-semble des composants d’un SBC d écrit avec SysML. Nous notons par Compos(A1, A2),

l’algorithme permettant de v érifier la comptabilit é de deux automates d’interface, dont les étapes sont d écrites dans la section 2.3.1. Cet algorithme est d étaill é dans [dAH01].

(37)

L’algorithme 1 accepte en entr ée le mod èle formel du BDD du SBC (il exploite aussi le IBD de chaque bloc composite et l’automate d’interface de chaque bloc él émentaire), et pro-duit en sortie l’automate d’interface de bloc composite du syst ème d écrit par son BDD si les composants sont compatibles, ou un automate vide dans la cas contraire. L’algorithme analyse r écursivement l’architecture du syst ème en exploitant les liens hi érarchiques entre les blocs (dans le BDD) et leurs liens internes (connecteurs) dans les IBD, et v érifie au fur et à mesure, de son avanc ée, la compatibilit é des blocs SysML.

Algorithme 1 : SysCompos(BDDB)

ENTREES :

BDDB le BDD du syst`eme ou du bloc composite B

SORTIES :

l’automate d’interface du composant composite si l’assemblage est correct, ou un automate d’interface vide sinon

DEBUT

Soit bc, le bloc courant, tel que bc= IBB

Si S uBB(bc)= ∅ Alors// le bloc courant n’a pas de sous-blocs

Soit IAbc, l’automate d’interface obtenu `a partir du diagramme de s´equence

S Dbc

Retourner IAbc;

SINON

//analyse de l’IBD du bloc courant pour calculer la composition des sous-blocs du bloc courant

Soit IBDbc= hPartsbc, BlockPartbc, Portsbc, Pextinbc, Pextoutbc, PinPartbc, PoutPartbc,

Connectorsinbc, Connectorsoutbci le IBD de bc

et setBlocs= {bi | ∃pi∈ Partsbc∧ (pi, bi) ∈ BlockPartbc}; setCon= Connectorsinbc;

R´EP´ETER

Soit bi∈ setBlocs,

SI (S uBB(bi) , ∅) ALORS

IAbi = S ysCompos(BDDbi);

SINON

Soit IAbi, l’automate d’interface obtenu `a partir du diagramme de

s´equence S Dbi

FIN SI

TANT QUE ∃{pi, p0i} ∈ S etCon tel que (p 0 i, b 0 i) ∈ BlockPartbc FAIRE SI (S uB(b0 i) , ∅) ALORS IAb0 i = S ysCompos(BDDb 0 i) SINON Soit IAb0

i, l’automate d’interface obtenus

du diagramme de s´equence S Db0 i FIN SI IAbi = Compos(IAbi, IAb0i) IAb0 i = IAbi // l’automate de b 0

i devient ´egalement celui de la composition

SI (IAbi = ∅) ALORS Exit();FIN SI// incompatibilit´e des sous-blocs

S etCon= S etCon − {(pi, p0_i)};

FIN TANT QUE;

setBlocs= setBlocs − bi;

JUSQU’A setBlocs= ∅; Retourner IAbi;

Fin Si FIN