Maîtrise de la cohérence des modèles UML d'applications critiques, approche par l'analyse des risques liés au langage UML.

HAL Id: tel-00137009

https://tel.archives-ouvertes.fr/tel-00137009

Submitted on 16 Mar 2007

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.

d’applications critiques, approche par l’analyse des risques liés au langage UML.

Jean-Pierre Seuma Vidal

To cite this version:

Jean-Pierre Seuma Vidal. Maîtrise de la cohérence des modèles UML d’applications critiques, approche par l’analyse des risques liés au langage UML.. Génie logiciel [cs.SE]. INSA de Toulouse, 2006.

Français. �tel-00137009�

TH` ESE

pr´ esent´ ee ` a

l’Institut National des Sciences Appliqu´ ees de Toulouse

pour l’obtention du titre de DOCTEUR

de l’Institut National des Sciences Appliqu´ ees de Toulouse Sp´ ecialit´ e : Informatique

par

Jean-Pierre SEUMA VIDAL

Laboratoire d’ ´ Etude des Syst` emes Informatiques et Automatiques Ecole Doctorale Syst` ´ emes

Titre de la th` ese :

MAˆ ITRISE DE LA COH´ ERENCE

DES MOD` ELES UML D’APPLICATIONS CRITIQUES Approche par l’analyse des risques

li´ es au langage UML

Soutenue le 19 Juin 2006, devant le jury :

Pr´ esident : M. Christian Percebois Professeur, UPS Toulouse Rapporteurs : M. Franck Barbier Professeur, Universit´ e de Pau

M. Jean-Louis Sourrouille Professeur, INSA de Lyon Examinateurs : M. Gilles Motet Professeur, INSA Toulouse

M. Pierre De Saqui-Sannes Professeur, ENSICA

M. Christian Percebois Professeur, UPS Toulouse

Membre invit´ e : M. Thierry Le Saux Thales Avionics

TH` ESE

pr´ esent´ ee ` a

l’Institut National des Sciences Appliqu´ ees de Toulouse

pour l’obtention du titre de DOCTEUR

de l’Institut National des Sciences Appliqu´ ees de Toulouse Sp´ ecialit´ e : Informatique

par

Jean-Pierre SEUMA VIDAL

Laboratoire d’ ´ Etude des Syst` emes Informatiques et Automatiques Ecole Doctorale Syst` ´ emes

Titre de la th` ese :

MAˆ ITRISE DE LA COH´ ERENCE

DES MOD` ELES UML D’APPLICATIONS CRITIQUES Approche par l’analyse des risques

li´ es au langage UML

Soutenue le 19 Juin 2006, devant le jury :

Pr´ esident : M. Christian Percebois Professeur, UPS Toulouse Rapporteurs : M. Franck Barbier Professeur, Universit´ e de Pau

M. Jean-Louis Sourrouille Professeur, INSA de Lyon Examinateurs : M. Gilles Motet Professeur, INSA Toulouse

M. Pierre De Saqui-Sannes Professeur, ENSICA

M. Christian Percebois Professeur, UPS Toulouse

Membre invit´ e : M. Thierry Le Saux Thales Avionics

lumi` ere, au-dessus des nuages » Professeur Th´ eodore MONOD

« Il est vrai que la mis` ere d´ etruit, mais si nous partageons et si nous voulons vivre en

d´ emocratie, aussi bien politiquement que philosophiquement, la pauvret´ e seule nous

sauvera, et l’esprit de pauvret´ e est peut ˆ etre aujourd’hui le fondement de la morale »

Michel SERRES

Le travail pr´ esent´ e dans ce manuscrit r´ esulte d’´ echanges et de collaborations avec des personnes qui ont su apporter leur ´ eclairage sur ce chemin. Sans leur aide, ce travail n’aurait tout simplement pu ˆ etre r´ ealis´ e.

Tout d’abord, je remercie M. Franck Barbier et M. Jean-Louis Sourrouille pour l’in- t´ erˆ et qu’ils ont port´ e ` a ma th` ese en acceptant d’ˆ etre rapporteurs. C’est ` a double titre que j’adresse mes remerciements ` a M. Franck Barbier, d’une part pour ses remarques qui ont permis de pr´ eciser certains aspects techniques et de donner plus de coh´ erence

`

a l’ensemble de ce m´ emoire et d’autre part pour avoir particip´ e ` a nos interviews. Je remercie ´ egalement M. Jean-Louis Sourrouille pour avoir accept´ e d’ˆ etre rapporteur de ma th` ese et pour m’avoir donn´ e l’occasion de pr´ esenter nos travaux dans le cadre de journ´ ees de travail.

Je tiens ` a t´ emoigner ma sinc` ere reconnaissance ` a M. Gilles Motet, mon directeur de recherche, pour m’avoir fait confiance d` es le d´ ebut de la th` ese, pour sa disponibilit´ e, le s´ erieux de ses relectures, et son ind´ efectible soutien lors du “travail de b´ en´ edictin”

dans lequel nous nous ´ etions lanc´ es. J’ai beaucoup appr´ eci´ e la grande libert´ e qui m’a ´ et´ e donn´ ee notamment lors de l’exploration de la th´ ematique des probl` emes de coh´ erence, dans un domaine qui n’´ etait pas initialement notre domaine de pr´ edilection.

Je tiens ` a remercier M. Christian Percebois pour avoir accept´ e de participer et de pr´ esider au jury de th` ese. J’adresse aussi mes remerciements ` a M. Pierre de Saqui-Sannes pour avoir accept´ e d’ˆ etre membre de mon jury. Leurs remarques furent grandement appr´ eci´ ees.

Je remercie M. Thierry Le Saux, industriel ` a Thal` es Avionics pour nous avoir accueilli

`

a maintes reprises pour participer ` a nos interviews et pour nous avoir permis d’acc´ eder

`

a des mod` eles UML industriels.

Je voudrais remercier M. J´ er´ emie Guiochet dont les pr´ ec´ edents travaux de recherche ont ´ et´ e une base solide sur laquelle repose le travail pr´ esent´ e dans ce manuscrit.

J’adresse un remerciement sp´ ecial ` a mes coll` egues directs de travail Hugues et Ro- berto, avec lesquels nous avons partag´ e de nombreuses heures de travail et transpir´ e ensemble sur le m´ etamod` ele d’UML et pour les corrections qu’ils ont apport´ e suite aux relectures de certaines parties de ce manuscrit. Que les stagiaires qui ont aussi apport´ e leur pierre ` a l’´ edifice soient ici remerci´ es.

Je remercie M ^me Dani` ele Fournier-Prunaret, directrice du LESIA pour son accueil

mexicains et leurs initiatives culinaires. Comment omettre de remercier M. Pascal Acco pour ses pr´ ecieux conseils de grand fr` ere des th´ esards du LESIA et l’aide sur de nombreux soucis “latex-iques”. Je garderai en m´ emoire ses entr´ ees dans le bureau pour le moins communicatives.

Je remercie ´ egalement les coll` egues du DGEI pour la qualit´ e des ´ echanges profession- nels ou personnels, et notamment le travail de secr´ etariat et de maintenance informatique toujours accompli avec bienveillance et professionalisme. J’attends cette rando avec mes ain´ es du DGEI, Christophe, Fofo et Terlys pour faire vivre ces lieux dont nous avons tant parl´ e. Tant pis pour les genoux.

Je demande pardon aux personnes que j’aurais oubli´ e et dont la gentillesse discr` ete m’aurait ´ echapp´ e. Qu’elles aient au moins l’honnˆ etet´ e de se reconnaitre maintenant et de recevoir mes discrets remerciements, l’essentiel restant invisible pour les yeux.

Enfin, je voudrais traduire ici avec ´ emotion la reconnaissance ` a celles et ceux qui m’ont accompagn´ e durant tout ce temps, qui m’ont montr´ e combien chaque personne a de la valeur, et qui me font grandir jour apr` es jour : ma famille, mes amis, les personnes de la rue et Alice.

Je d´ edie ce travail ` a mes parents qui m’ont donn´ e ce cadeau d’ˆ etre en vie.

1 Risques d’incoh´ erences UML 17

1.1 Cadre de l’´ etude . . . . 17

1.1.1 Concept de risque . . . . 17

1.1.2 Risques logiciels . . . . 18

1.1.3 Langage UML . . . . 19

1.2 Types de risques des mod` eles UML . . . . 21

1.2.1 Ev´ ´ enements dommageables et coh´ erence . . . . 21

1.2.2 Incoh´ erence et UML . . . . 22

1.3 Vue d’ensemble des travaux . . . . 24

2 Etat de l’art relatif aux incoh´ ´ erences 27 2.1 D´ etection d’incoh´ erences des mod` eles UML . . . . 27

2.2 Etudes actuelles . . . . ´ 28

2.2.1 Type de mod` ele ´ etudi´ e . . . . 28

2.2.2 El´ ´ ements du mod` ele consid´ er´ es . . . . 29

2.2.3 Type de propri´ et´ e utilis´ ee . . . . 30

2.2.4 Technique de d´ etection . . . . 33

2.3 N´ ecessit´ e d’une ´ etude syst´ ematique . . . . 36

3 Identification des r` egles de coh´ erence UML 37 3.1 M´ ethode d’identification . . . . 37

3.1.1 Objectifs . . . . 37

3.1.2 Informations associ´ ees ` a chaque r` egle . . . . 38

3.1.3 Structure du document . . . . 40

3.2 R´ esultats et analyse . . . . 42

3.2.1 Illustration de chaque type de r` egle . . . . 42

3.2.1.1 El´ ´ ement . . . . 42

3.2.1.2 Relation . . . . 45

3.2.1.3 Diagramme . . . . 47

3.2.1.4 Inter-diagramme . . . . 48

3.2.2 Commentaires sur les r´ esultats . . . . 50

3.2.2.1 Organisation du document . . . . 50

3.2.2.2 Bilan quantitatif . . . . 51

3.2.2.3 Liens des r` egles entre elles . . . . 51

3.2.2.4 Commentaires concernant la capacit´ e de d´ etection . . . 52

3.2.3 Limites de l’´ etude . . . . 52

3.2.4 Conclusion . . . . 54

4 Estimation des risques d’incoh´ erences UML 57 4.1 Besoins, interˆ ets et moyens . . . . 57

4.1.1 Pr´ esence d’incoh´ erences . . . . 58

4.1.2 Insuffisance des outils de d´ etection . . . . 58

4.1.3 Moyens d’estimation . . . . 60

4.1.3.1 Deux param` etres . . . . 60

4.1.3.2 Crit` eres et m´ etriques . . . . 60

4.1.3.3 M´ ethodes d’estimation . . . . 61

4.1.4 Application ` a l’estimation des risques de chaque construction . . . 62

4.2 Estimation des risques par interview d’experts . . . . 63

4.2.1 Principes . . . . 63

4.2.2 Crit` eres et m´ etriques . . . . 65

4.2.2.1 Gravit´ e . . . . 65

4.2.2.2 Degr´ e de vraisemblance . . . . 66

4.2.3 Processus d’estimation . . . . 67

4.2.3.1 Rˆ oles . . . . 67

4.2.3.2 Port´ ee de l’interview . . . . 67

4.2.4 R´ esultats . . . . 68

4.2.4.1 R´ esultats sp´ ecifiques ` a la m´ etarelation Association . . 68

4.2.4.2 R´ esultats sp´ ecifiques au m´ eta´ el´ ement Property . . . . . 69

4.2.4.3 Estimation globale pour les diagrammes de classes . . . 70

4.2.5 Commentaires . . . . 71

4.3 Estimation quantitative par analyse de mod` eles . . . . 72

4.3.1 Crit` eres et m´ etriques . . . . 73

4.3.2 Processus d’estimation . . . . 74

4.3.3 R´ esultats . . . . 75

4.4 Conclusion . . . . 76

5 Traitement des risques d’incoh´ erences UML 77 5.1 Traitement du risque . . . . 77

5.1.1 Besoins . . . . 77

5.1.2 Classes de moyens . . . . 79

5.1.2.1 Quatre grandes approches de traitement . . . . 79

5.1.2.2 L’´ evitement des risques . . . . 80

5.1.2.3 L’optimisation des risques . . . . 81

5.2 Application ` a UML . . . . 82

5.2.1 Approches de traitement des incoh´ erences UML par optimisation 82 5.2.1.1 Des guides de mod´ elisation . . . . 83

5.2.1.2 Des guides li´ es au processus de d´ eveloppement . . . . 84

5.2.1.3 Des patrons de conception . . . . 85

5.2.1.4 Un cadre de gestion des incoh´ erences . . . . 86

5.2.2 Approche propos´ ee . . . . 87

5.3 Pr´ evention . . . . 88

5.3.1 Principes . . . . 88

5.3.2 Ne pas utiliser une notation . . . . 89

5.3.2.1 Exemple des pins . . . . 89

5.3.2.2 Exemple de la fusion des nœuds de d´ ecision et de fusion 89 5.3.3 Forcer l’expression d’une information suppl´ ementaire . . . . 90

5.3.4 Adopter des conventions de nommage . . . . 95

5.3.4.1 Exemple de l’alias optionnel de la relation d’importation d’´ el´ ement . . . . 96

5.3.4.2 Exemple des portes . . . . 96

5.3.5 Veiller ` a l’agencement graphique des ´ el´ ements dans un diagramme 97 5.3.6 Appliquer des guides de mod´ elisation . . . . 98

5.3.6.1 Nœud final d’activit´ e ou nœud final de flot . . . . 98

5.3.6.2 De l’usage des conditions de garde dans les diagrammes d’activit´ es . . . . 99

5.4 Protection . . . 100

5.4.1 Principes . . . 100

5.4.2 Rajouter une information . . . 101

5.4.3 Appliquer des guides de mod´ elisation . . . 103

5.5 Conclusion . . . 105

6 Synth` ese, contributions majeures et perspectives 107 6.1 Synth` ese . . . 107

6.2 Contributions majeures et perspectives . . . 108

A Interviews 111 A.1 Feuille-type d’estimation d’une r` egle par interview . . . 111

A.2 R` egles utilis´ ees pour l’interview . . . 113

A.2.1 Liste des concepts de niveau m´ eta-mod` ele consid´ er´ es . . . 113

A.2.2 Enonc´ e textuel des r` egles . . . 113

A.2.2.1 El´ ´ ements . . . 113

A.2.2.2 Relations . . . 115

Lexique Anglais Fran¸ cais 118

Index 120

Bibliographie 122

1.1 Architecture en quatre couches . . . . 20

1.2 Exemple de la hi´ erarchie de m´ eta-mod´ elisation en 4 couches . . . . 20

2.1 Mod` ele de faute et incoh´ erence . . . . 32

2.2 Approche transformationnelle . . . . 34

3.1 Tableau synth´ etique de l’origine des r` egles . . . . 39

3.2 Relation entre les m´ etaclasses Package and PackageableElement . . . . 43

3.3 Arbre de sp´ ecialisation de la m´ etaclasse PackageableElement . . . . 43

3.4 Composant candidat pour en substituer un autre . . . . 44

3.5 Incoh´ erence dans la d´ efinition des multiplicit´ es dans un diagramme de classes . . . . 45

3.6 Exemple de manifestation . . . . 45

3.7 M´ etamod` ele impliquant la relation de manifestation . . . . 46

3.8 Incoh´ erence dans les arcs d’activit´ es avec des connecteurs labellis´ es . . . 46

3.9 Exemple d’une importation d’´ el´ ement avec alias incoh´ erente . . . . 47

3.10 Diagramme d’activit´ e avec ´ ev´ enement activateur sur le premier arc . . . 48

3.11 Incoh´ erence dans un diagramme d’activit´ es . . . . 48

3.12 Incoh´ erence entre diagramme d’activit´ es et diagramme de classes . . . . . 49

3.13 Coh´ erence entre diagramme de classes et diagramme de structures com- posites . . . . 50

3.14 Tableau de r´ epartition des r` egles par niveau d’abstraction . . . . 51

3.15 Types de dommages . . . . 55

4.1 R´ esultats synth´ etiques des taux de d´ etection d’erreur . . . . 59

4.2 Pourcentage de d´ etection par moyen de d´ etection . . . . 60

4.3 Estimation du risque de la pr´ esence d’incoh´ erences associ´ ees ` a une construction UML . . . . 62

4.4 Acceptabilit´ e du risque . . . . 62

4.5 Estimation du risque pour la construction Association - Un point de vue industriel . . . . 68

4.6 Estimation du risque pour la construction Association - Un point de

vue universitaire . . . . 68

4.7 Estimation du risque pour la construction Property - Un point de vue

industriel . . . . 69

4.8 Estimation du risque pour la construction Property - Un point de vue universitaire . . . . 69

4.9 Estimation globale du risque pour les diagrammes de classes selon le cri- t` ere de la difficult´ e de d´ etection - Un point de vue industriel . . . . 70

4.10 Estimation globale du risque pour les diagrammes de classes selon le cri- t` ere de la difficult´ e de d´ etection - Un point de vue universitaire . . . . 70

4.11 Estimation globale du risque pour les diagrammes de classes selon le cri- t` ere de l’impact sur le code - Un point de vue industriel . . . . 71

4.12 Estimation globale du risque pour les diagrammes de classes selon le cri- t` ere de l’impact sur le code - Un point de vue universitaire . . . . 71

4.13 Crit` eres et m´ etriques pour la gravit´ e et le degr´ e de vraisemblance . . . . 73

4.14 Informations quantitatives relatives aux mod` eles consid´ er´ es . . . . 75

4.15 Graphe d’acceptabilit´ e du risque pour les contraintes d’interaction . . . . 75

5.1 Les deux fa¸cons de r´ eduire le niveau de risque . . . . 78

5.2 Risque et niveaux de criticit´ e . . . . 78

5.3 Message dans le diagramme de s´ equence . . . . 82

5.4 Op´ eration dans le diagramme de classes . . . . 82

5.5 Association repr´ esent´ ee plutˆ ot que le type d’un attribut . . . . 83

5.6 Attribut de classe typ´ e par une classe en association . . . . 83

5.7 Repr´ esentations ´ equivalentes de flux d’objets . . . . 89

5.8 Noeud de fusion, de d´ ecision, et les 2 combin´ es . . . . 90

5.9 Un composant avec une interface requise, sp´ ecifi´ ee par d´ ependance d’usage 91 5.10 Un composant avec ses interfaces sp´ ecifi´ ees par l’interm´ ediaire de ports . 91 5.11 La collaboration Sale . . . . 92

5.12 La collaboration BrokeredSale . . . . 92

5.13 La collaboration Sale utilis´ ee par le classificateur BrokeredSale . . . . . 93

5.14 Une utilisation de collaboration reli´ ee ` a un classificateur avec le mot cl´ e « represents » . . . . 93

5.15 ´ El´ ements empaquetables sans visibilit´ e . . . . 94

5.16 ´ El´ ements empaquetables avec visibilit´ e . . . . 94

5.17 Classe abstraite non explicite . . . . 94

5.18 Classe abstraite explicite . . . . 94

5.19 Fragment optionnel vide . . . . 95

5.20 Fragment optionnel non vide . . . . 95

5.21 Importation d’´ el´ ement sans alias . . . . 96

5.22 Importation d’´ el´ ement avec alias . . . . 96

5.23 Porte nomm´ ee d’une sp´ ecification d’occurrence . . . . 97

5.24 Arbre de g´ en´ eralisation non agenc´ e . . . . 98

5.25 Arbre de g´ en´ eralisation r´ eagenc´ e par ensemble de g´ en´ eralisation . . . . . 98 5.26 Diagramme d’activit´ es avec deux nœuds finaux de flots . . . . 99 5.27 Arc d’activit´ e avec condition de garde sortant d’un nœud de bifurcation

(fork node), non prot´ eg´ e . . . . 99 5.28 Arc d’activit´ e avec condition de garde sortant d’un nœud de bifurcation

(fork node), prot´ eg´ e par un nœud de d´ ecision et un nœud de fusion . . . 100

5.29 Classe Alert et sa machine ` a ´ etats . . . 102

5.30 D´ ependance d’abstraction de st´ er´ eotype « derive » . . . 103

5.31 Repr´ esentation d’un port comportemental . . . 104

Il est des activit´ es humaines qui procurent ` a la personne une certaine conscience de sa finitude, de sa petitesse, mais en mˆ eme temps de faire partie d’un tout, coh´ erent, qui nous d´ epasse. La randonn´ ee en montagne en est une. Si les ´ equipements de protection contre les intemp´ eries et de guidage tels que GPS ne cessent d’´ evoluer, si les bulletins de pr´ evision m´ et´ eorologiques ne cessent de s’affiner, la pratique de la randonn´ ee n’en reste pas moins une activit´ e ` a risque dans un milieu, qui peut se montrer aussi bien accueillant qu’hostile. Bien souvent, certaines habitudes comme celles de rester chez soi un jour pr´ evu d’orage, ou de se fier plutˆ ot qu’` a un GPS mal calibr´ e ` a une vieille carte r´ esultant de l’ajout continuel d’informations au gr´ e des randonn´ ees pass´ ees, permettent d’´ eviter bien des d´ esagr´ ements et la prise de risques inutiles.

Certains mod` eles humains permettent de pr´ eparer avec un certain degr´ e de confiance une sortie. Les cartes, qui mettent sur papier une repr´ esentation de la topographie, ainsi que les mod` eles d’´ evolution du temps fournis par les m´ et´ eorologues donnent ` a tout can- didat ` a une petite ´ echapp´ ee montagnarde des donn´ ees pour prendre la d´ ecision de sortir ou de rester chez soi. La d´ ecision ´ etant prise de rejoindre le pied de montagne pour la gravir, un certain nombre de mesures de pr´ evention doivent ˆ etre suivies avant d’entamer la marche, comme celle d’´ eviter de partir seul, ou celle de pr´ evenir une personne restant en bas de l’itin´ eraire pr´ evu, etc. Mais, une fois le sac sur le dos, qui n’est pas rest´ e per- plexe au moins une fois devant une carte avec des indications manquantes ou erron´ ees par rapport au terrain ? La carte n’est pas le territoire, r´ epondront certains. Cependant la carte est indispensable pour qui veut s’aventurer hors des sentiers battus et qui veut revenir au point de d´ epart, par un chemin qui “marche”.

Tout(e) montagnard(e) a au moins temporairement remis(e) en cause la pratique de

son activit´ e ` a l’occasion d’une mauvaise d´ ecision, qu’elle soit au moment de partir, au

cours de la marche, ou au moment de revenir. La balance entre les conditions m´ et´ eo-

rologiques, sa condition physique, son d´ esir de d´ epassement et la prise de risque, n’est

pas chose ais´ ee. Elle l’est encore moins lorsqu’il s’agit d’une activit´ e men´ ee en groupe o` u

chaque participant aspire ` a diff´ erents degr´ es de prise de risque. Cependant le risque de la

perte d’une vie humaine restant inacceptable, il est de la responsabilit´ e de chacun d’ˆ etre

capable d’identifier et d’estimer les risques impliqu´ es par un parcours et de pr´ evoir des

mesures de repli et d’itin´ eraires bis pour pallier ` a un ´ ev´ enement impr´ evu comme une

cheville foul´ ee.

alors est : comment rendre la carte aussi pr´ ecise que possible et g´ erer les incompl´ etudes et les erreurs qu’elle comporte ? Mais avant tout, quel est le propos de cet avant-propos ? L’´ evocation de cette activit´ e ` a risque n’a pour autre but que d’introduire par analogie le sujet de l’´ etude pr´ esent´ ee dans ce manuscrit. Nous avons emprunt´ e le long sentier qui permet ` a un informaticien d’avoir une vue d’ensemble de cette montagne qui est le langage UML, dans la vari´ et´ e de ses diagrammes et de ses vues. Nous voulons juste en avant-propos ` a ce manuscrit faire un parall` ele entre cette activit´ e et l’activit´ e de d´ eveloppement de logiciels, qui a priori, n’auraient que peu de similitudes.

Nous allons dans cette th` ese nous situer dans le cadre d’applications logicielles qui sont d´ evelopp´ ees ` a l’aide du langage de mod´ elisation informatique UML. Ce langage offre des constructions graphiques pouvant ˆ etre assembl´ ees afin de constituer des dia- grammes, dont l’assemblage constitue un mod` ele complet. Le langage UML permet la description de syst` emes informatiques complexes dont la s´ ecurit´ e est parfois essentielle et dont l’assurance d’un bon fonctionnement est une priorit´ e vitale. Afin de maˆıtriser la complexit´ e des choses ` a repr´ esenter, et d’arriver ` a trouver une solution informatique qui en d´ ecoule et qui soit correcte, la conception de telles applications n´ ecessite l’emploi de mod` eles tout le long d’un processus de d´ eveloppement.

Mais les risques encourus dans l’activit´ e de d´ eveloppement de mod` eles de logiciels

´

ecrits avec UML ne sont pas nuls. En particulier nous nous sommes int´ eress´ es au risque de la pr´ esence d’incoh´ erences dans un mod` ele. En effet les diagrammes peuvent comporter des fautes pouvant mener ` a des incoh´ erences entre diagrammes ou au sein mˆ eme d’un seul diagramme. Un des principaux probl` emes qui se pose alors est la gestion ou la maˆıtrise de la coh´ erence des mod` eles. Nous traitons la question de la gestion des risques li´ es ` a l’utilisation d’UML, en ayant comme objectif et comme “boussole” la maˆıtrise de cette coh´ erence.

Ce manuscrit va pr´ esenter la d´ emarche g´ en´ erale suivie de management des risques en abordant d’abord les concepts introductifs aux notions de risque et d’incoh´ erence.

L’identification, puis l’estimation des risques d’incoh´ erences UML seront pr´ esent´ ees ainsi qu’un aper¸cu des techniques de pr´ evention et de protection ` a mettre en œuvre pour r´ eduire les risques.

Un lexique Anglais/Fran¸cais regroupe en fin de document l’ensemble des termes UML

employ´ es. Les notes de bas de page pr´ esentes dans le texte correspondent ` a des termes

anglais ou ` a des phrases en anglais tir´ ees de la sp´ ecification d’UML.

Risques d’incoh´ erences UML

1.1 Cadre de l’´ etude

1.1.1 Concept de risque

Les syst` emes naturels ou technologiques avec lesquels nous interagissons sont ` a l’ori- gine de nombreux risques : risques vis-` a-vis de l’´ equilibre environnemental, risques vis-

`

a-vis de l’homme, risques vis-` a-vis de l’´ economie, etc. Concernant les syst` emes technolo- giques, la « prise de risque » est souvent volontaire car en g´ en´ eral associ´ ee ` a l’esp´ erance d’un b´ en´ efice suffisamment important pour la justifier : c’est dans l’objectif de tirer pro- fit d’un syst` eme particulier que l’on choisit de prendre certains risques et que l’on doit donc les g´ erer afin de conserver les b´ en´ efices escompt´ es tout en r´ eduisant au maximum les occurrences des dommages potentiels. La gestion des risques est donc une activit´ e in- h´ erente et commune ` a un grand nombre de domaines d’activit´ es g´ en´ erales (par exemple le domaine industriel) ou sp´ ecifiques (a´ eronautique) ou de domaines technologiques (chi- mie, informatique, etc.).

Ainsi, dans le domaine informatique en particulier, les technologies logicielles com- portent chacune des caract´ eristiques conduisant ` a des gains et ` a des pertes potentielles (voir section 1.1.2).

La s´ ecurit´ e ¹ d’un syst` eme peut se d´ efinir par l’absence de dommages inacceptables.

Un dommage peut ˆ etre qualifi´ e par sa nature (par exemple brˆ ulure, ´ ecrasement, coupure, etc. s’il affecte l’ˆ etre humain) et mesur´ e par sa gravit´ e et sa probabilit´ e d’occurrence.

Afin de rendre compte de l’interaction entre la gravit´ e et l’occurrence d’un dommage, la notion de risque a ´ et´ e introduite. La d´ efinition donn´ ee par l’ISO/CEI Guide 51 (1999)[1]

du risque est la suivante :

Risque Combinaison de la probabilit´ e d’un dommage et de sa gravit´ e

1 au sens safety ; il s’agit d’un des attributs de la sˆ uret´ e de fonctionnement. A ne pas confondre avec

la s´ ecurit´ e-confidentialit´ e (security en anglais)

1.1.2 Risques logiciels

Le risque dans les applications logicielles peut tout d’abord ˆ etre vu en consid´ erant les ´ ev´ enements dommageables que sont les d´ efaillances ` a l’ex´ ecution. Les travaux de recherche actuels, tout comme les activit´ es de d´ eveloppement, relatives aux risques inh´ erents aux applications logicielles, traitent essentiellement des ´ ev´ enements redout´ es que sont les d´ efaillances potentielles de ces applications. Ces d´ efaillances sont consi- d´ er´ ees comme issues de la pr´ esence de fautes de conception dans les programmes. Ces risques sont trait´ es en agissant sur le processus de d´ eveloppement ou sur les r´ esultats de chaque ´ etape de ce processus (documents, mod` eles ou programmes). Selon le niveau de criticit´ e de l’application d´ evelopp´ ee, c’est-` a-dire selon le niveau acceptable de gravit´ e des cons´ equences induites par l’occurrence d’une d´ efaillance de cette application, des exigences plus ou moins importantes sont impos´ ees aux concepteurs. Les ´ etapes du processus de d´ eveloppement peuvent ainsi ˆ etre contraintes par l’application de guides par exemple. Ces exigences peuvent aussi contraindre les actions qui doivent ˆ etre men´ ees sur les r´ esultats des ´ etapes : ´ evaluation des risques de d´ efaillance, techniques de v´ erification pour signaler la pr´ esence de fautes, mise en œuvre de redondance pour inhiber ou r´ eduire les effets des d´ efaillances de composants, etc.

Si les fautes pr´ esentes dans les logiciels peuvent certainement ˆ etre induites par des erreurs survenant lors du processus de conception, elles peuvent ˆ etre ´ egalement attach´ ees

`

a la technologie logicielle employ´ ee. Or, cet aspect est assez peu ´ etudi´ e alors que les autres technologies sont fr´ equemement l’objet d’´ etudes : composants chimiques, mat´ eriaux de construction, etc. [56]. Les risques li´ es aux technologies logicielles qui nous int´ eressent sont les risques dont les dommages sont les fautes dans les programmes et dans les mod` eles.

La notion de risque a ´ et´ e pr´ ecis´ ee plus r´ ecemment en la sortant du seul contexte de la s´ ecurit´ e exprim´ ee dans le guide 51 [1] de l’ISO. Ainsi le guide 73 de l’ISO [2] d´ efinit le risque comme comportant deux ´ el´ ements :

– un ´ ev´ enement qui identifie l’occurrence potentielle d’un ensemble particulier de circonstances,

– une cons´ equence qui qualifie son impact sur une cible.

La cible peut ˆ etre une personne, un bien, l’environnement, mais aussi un mod` ele informatique, etc. Il est important de noter que la cons´ equence (qui g´ en´ eralise la notion de dommages caus´ es) sur la cible n’est pas toujours grave et que l’occurrence de l’´ ev´ ene- ment n’est que potentielle et non induite assur´ ement par des causes (source du risque).

Les ´ ev´ enements dits “dommageables“ sont alors particuli` erement int´ eressants ` a ´ etudier lorsqu’on est concern´ e par le domaine de la s´ ecurit´ e.

Pour g´ erer les risques, il convient en premier lieu de chercher ` a ´ enum´ erer et ` a d´ ecrire

les risques possibles ainsi que leurs sources.

1.1.3 Langage UML

Les langages graphiques fournissent un moyen prometteur pour maˆıtriser la com- plexit´ e des logiciels. De ce fait, leur utilisation r´ eduit la pr´ esence de fautes dans les ap- plications mod´ elis´ ees et constitue donc un moyen appr´ eciable pour augmenter la s´ ecurit´ e des logiciels d´ evelopp´ es. Le langage UML 2.0 [60] lui-mˆ eme repose sur un formalisme bien d´ efini. Nous allons rappeler ici bri` evement l’architecture du langage et le contexte dans lequel nous pla¸cons nos ´ etudes.

L’architecture du langage Le langage UML s’inscrit dans une architecture ` a quatre couches ou niveaux de m´ eta-mod´ elisation qui sont : objets utilisateurs (ou instances ex´ ecutables, run-time instances en anglais, niveau dit M0), mod` ele (niveau M1), m´ etamod` ele (niveau M2) et m´ eta-m´ etamod` ele (niveau M3). Nous allons d´ etailler ce d´ ecoupage avec des notions volontairement simplifi´ ees reposant sur les diff´ erents niveaux.

. La couche m´ eta-m´ etamod` ele a pour rˆ ole de d´ efinir le langage pour sp´ ecifier un m´ etamod` ele. Pour le langage UML (langage de niveau M2), son m´ etamod` ele est le langage MOF [57](niveau M3). Il fournit par exemple le concept de classe. Il permet de g´ en´ eraliser les constructions d’UML que sont les attributs, classes et instances grˆ ace ` a la notion de classe du niveau M3.

. Un m´ etamod` ele est une instance d’un m´ eta-m´ etamod` ele. Le rˆ ole de la couche

“m´ etamod` ele” est de d´ efinir le langage pour sp´ ecifier un mod` ele et c’est ` a ce ni- veau l` a que les notions comme celles de classe, attribut, op´ eration, sont pr´ esent´ ees dans la superstructure de la sp´ ecification d’UML [59]. Ces notions sont des ins- tances du concept de classe de niveau M3, comme pr´ esent´ e ` a la figure 1.2 tir´ ee de l’infrastructure de la version 2.0 de la sp´ ecification d’UML [58] ² .

. La couche mod` ele est une instance du m´ etamod` ele. Le principal rˆ ole du niveau

“mod` ele” est de d´ efinir un langage qui d´ ecrit un domaine d’information. C’est ` a ce niveau que seront d´ efinis les noms des classes ou d’instances de classes, attributs et op´ erations propres au syst` eme mod´ elis´ e. Des exemples d’objets du niveau mod` ele sont : Fenˆ etre, couleurFenˆ etre (ou bleu pour une instance de l’attribut couleur de la classe Fenˆ etre) et afficherFenˆ etre().

. Les objets utilisateurs sont des instances ex´ ecutables d’un mod` ele. Le rˆ ole du niveau “donn´ ees utilisateurs” est de d´ ecrire un domaine d’information sp´ ecifique.

Des exemples d’objets du niveau objets utilisateurs sont : <Fenˆ etre3> (instance de Fenˆ etre), un appel de l’op´ eration instance d’afficherFenˆ etre().

2 Signalons que la figure comporte une erreur, car le m´ etatype Instance n’existe plus et a ´ et´ e remplac´ e

par le m´ etatype InstanceSpecification ; Cependant la derni` ere version disponible de l’infrastructure

[63] pr´ esente la mˆ eme erreur, ce qui illustre les erreurs qui peuvent se propager d’une version ` a une

autre.

Le tableau 1.1 reprend synth´ etiquement les quatre couches et la figure 1.2 repr´ esente cette mˆ eme architecture avec des classes UML.

Niveau Couche Exemples Usage pour UML

M3 M´ eta-M´ etamod` ele Classe Langage de sp´ ecification du m´ eta- mod` ele

M2 M´ etamod` ele Classe, Attribut, Op´ eration D´ efinition d’UML M1 Mod` ele Fenˆ etre, couleurFenˆ etre,

bleu, afficherFenˆ etre()

Mod´ elisation de l’information avec UML

M0 Instances Ex´ ecutables <Fenˆ etre3> R´ ealisation informatique de tous les ´ el´ ements du mod` ele

Fig. 1.1: Architecture en quatre couches

Fig. 1.2: Exemple de la hi´ erarchie de m´ eta-mod´ elisation en 4 couches

Nos ´ etudes se situent au niveau m´ etamod` ele (M2) et mod` ele (M1). Nous cherchons ` a

´

etablir les propri´ et´ es exprimables au niveau m´ etamod` ele, qui contraignent la bonne for-

mation de tout mod` ele de niveau (M1). Chaque diagrammme d’UML peut ˆ etre vu comme

l’assemblage d’´ el´ ements graphiques reli´ es entre eux par des relations, par exemple deux

boˆıtes reli´ ees par un trait plein. Au niveau m´ etamod` ele, ces repr´ esentations graphiques

et concr` etes ont une correspondance sous forme d’une primitive abstraite, comme par exemple la classe (qui est repr´ esent´ ee par la boˆıte), et la relation d’association (qui est repr´ esent´ ee par le trait plein). Nous d´ efinirons le terme “construction de base” pour d´ esi- gner cet ensemble des ´ el´ ements et des relations, ces primitives abstraites, qui constituent la notion d’´ el´ ement UML au niveau m´ etamod` ele.

1.2 Types de risques des mod` eles UML

Quels types de risques, et tout d’abord d’´ ev´ enements dommageables sont rencontr´ es et probables dans les mod` eles UML ? Pour r´ epondre ` a cette question, il faut d’abord pr´ esenter quelques notions concernant la mod´ elisation cognitive en nous r´ ef´ erant ` a [68]

et [24].

Un mod` ele est une repr´ esentation d’un syst` eme dans un formalisme et toute repr´ e- sentation licite dans ce formalisme poss` ede une interpr´ etation bas´ ee sur la s´ emantique de ce formalisme. Le formalisme consid´ er´ e ici est le langage UML, dont la s´ emantique n’est pas enti` erement traduite en des contraintes formelles et il n’existe pas de v´ erificateur automatique qui d´ etecterait si toutes les “briques de base” d’un mod` ele sont conformes ` a la s´ emantique du langage. De plus, certaines contraintes sont induites par la s´ emantique d’autres domaines (contraintes du processus de mod´ elisation, contraintes du domaine applicatif, contraintes sp´ ecifiques ` a la plate-forme ou ` a l’implantation).

Un mod` ele n’est coh´ erent que lorsqu’il est conforme ` a la s´ emantique de tous les domaines impliqu´ es dans le processus de d´ eveloppement. Une affirmation commun´ ement admise est que, sauf ` a la fin du processus, les mod` eles sont incomplets et de ce fait, souvent incoh´ erents.

1.2.1 Ev´ ´ enements dommageables et coh´ erence

Dans notre cadre de gestion des risques li´ es ` a la technologie UML, on peut alors distinguer deux classes principales d’´ ev´ enements dommageables :

– l’incompl´ etude qui est l’absence de l’information attendue, et – l’incoh´ erence qui concerne les conflits entre des informations.

[45] signale que l’affectation d’un de ces qualificatifs est souvent due ` a une inter- pr´ etation de l’origine de la faute. Par exemple, si une classe A appelle une m´ ethode M d’une classe B, et si B ne contient pas de d´ eclaration de cette m´ ethode, la cause peut ˆ etre une omission de cette d´ eclaration (incompl´ etude) ou une faute ` a l’appel de la m´ ethode (incoh´ erence). En pratique, selon [68], la nature de l’´ ev´ enement dommageable (incompl´ etude ou incoh´ erence) est une d´ ecision prise par l’utilisateur.

L’incompl´ etude dans un mod` ele est r´ ev´ el´ ee lorsqu’une information est manquante

dans le mod` ele, et des donn´ ees, par exemple des multiplicit´ es sur des fins d’association,

devraient ˆ etre rajout´ ees dans le mod` ele.

On peut mentionner une taxonomie plus g´ en´ erale, donn´ ee par [8] qui distingue 5 types de fautes dans les produits logiciels d´ etect´ es lors d’inspections de documents de sp´ ecification et de d´ efinition d’exigences. Dans [75], ces mˆ emes fautes sont pr´ esent´ ees dans le cadre plus pr´ ecis de la conception orient´ ee objet et elles peuvent ˆ etre r´ ev´ el´ ees par un exercice de d´ etection manuelle de fautes que l’on qualifie alors par l’une de ces cat´ egories pr´ ecises :

– l’omission : un ou plusieurs diagrammes de conception qui devraient contenir un concept issu des exigences g´ en´ erales ou du cahier des charges ne contiennent pas la repr´ esentation de ce concept.

– un fait incorrect : un diagramme de conception contient une mauvaise repr´ esenta- tion d’un concept d´ ecrit dans les exigences g´ en´ erales ou dans le cahier des charges.

– une incoh´ erence : la repr´ esentation d’un concept dans un diagramme de conception est en d´ esaccord avec la repr´ esentation du mˆ eme concept dans le mˆ eme ou un autre diagramme.

– une ambigu¨ıt´ e : la repr´ esentation d’un concept dans une conception n’est pas claire, et pourrait causer une mauvaise interpr´ etation ou compr´ ehension du sens de ce concept par un utilisateur du document (d´ eveloppeur, concepteur, etc.).

– une information ´ etrang` ere : la conception inclut une information qui, bien que peut-ˆ etre vraie, ne s’applique pas ` a ce domaine et ne devrait pas ˆ etre incluse dans la conception.

[65] reprend cette classification pour regrouper les fautes de type “omission” et “in- formation ´ etrang` ere” dans la cat´ egorie des fautes syntaxiques, puis les fautes de type

“faits incorrects” et “ambigu¨ıt´e” dans les fautes s´emantiques.

La notion d’incoh´ erence ` a laquelle nous nous int´ eressons plus particuli` erement cor- respond toujours ` a un d´ esaccord entre une repr´ esentation X d’un concept et une repr´ e- sentation Y du mˆ eme concept. On parle alors d’incoh´ erence entre 2 repr´ esentations.

Le concept affect´ e par l’incoh´ erence peut appartenir ` a l’application. Par exemple, l’´ etat d’une alimentation ´ electrique d’un moteur est effective (bouton ON) et l’´ etat du fonctionnement du moteur est arrˆ et. La d´ etection d’une telle incoh´ erence suppose alors une connaissance de la s´ emantique de l’application. Nous n’aborderons pas ce point de vue. Nous ne consid´ erons uniquement que les concepts offerts par le langage UML (classe, attribut, diagramme, etc.) en cherchant ` a r´ ev´ eler les incoh´ erences dans leurs usages s´ epar´ es ou conjoints dans les applications.

1.2.2 Incoh´ erence et UML

Avant de pr´ eciser le concept d’incoh´ erence dans le cadre d’UML, il est bon de partir de celui de faute et d’erreur.

Le constat qu’un artefact ou mod` ele UML est incoh´ erent peut ˆ etre issu de l’observa- tion :

– d’informations structurelles de l’artefact (par exemple, une classe poss` ede deux

op´ erations de mˆ eme signature) identifiant alors une faute, ou

– d’informations comportementales de l’artefact (par exemple, un diagramme de machine ` a ´ etats qui n’est pas vivant) exprimant dans ce cas une erreur [46].

Exprimer une incoh´ erence associ´ ee ` a UML revient donc ` a d´ efinir des “mod` eles de fautes” ou des “mod` eles d’erreurs” (au niveau M2) dont une incoh´ erence associ´ ee ` a un mod` ele UML est une instance (une faute ou une erreur) au niveau M1 [34].

Un mod` ele de fautes d´ efinit un ensemble de fautes caract´ eris´ ees par des propri´ et´ es structurelles du mod` ele (on parle aussi de propri´ et´ es syntaxiques). Ces propri´ et´ es sont nomm´ ees well-formedness rules.

Le concept de mod` ele d’erreurs a d’abord ´ et´ e introduit en m´ ecanique puis en ´ electro- nique. Un mod` ele d’erreur d´ ecrit un mod` ele comportemental de d´ efaillance qui s’applique

`

a tous les composants d’une certaine nature comme par exemple le blocage d’une vanne ou le collage ` a 0 d’une sortie d’une porte logique. La cause de l’erreur n’est pas pr´ eci- s´ ee, l’objectif ´ etant de fournir une caract´ erisation du constat de la d´ efaillance. On parle parfois de “mode de d´ efaillance”.

Par exemple, pour un programme ´ ecrit en langage Ada, la propri´ et´ e « la valeur d’une expression affect´ ee ` a une variable doit appartenir ` a l’ensemble des valeurs d´ efini par le type de la variable » exprime une propri´ et´ e comportementale car li´ ee ` a l’ex´ ecution des programmes. C’est une propri´ et´ e g´ en´ erique attendue et applicable ` a toutes les variables d’un programme. Il s’agit donc bien d’un mod` ele d’erreur associ´ e ` a une variable qui est une construction (feature en anglais) du langage Ada. Une erreur particuli` ere est lev´ ee lorsqu’une variable donn´ ee d’un programme particulier est affect´ ee par une valeur qui n’appartient pas ` a l’intervalle d´ efini par son type.

Pour notre ´ etude, d´ efinir un mod` ele de fautes ou d’erreurs n´ ecessite donc d’exprimer une propri´ et´ e exig´ ee d’une construction ou d’un ensemble de constructions d’UML. La violation de cette propri´ et´ e dans un artefact particulier utilisant cette (ou ces) construc- tion(s) ´ etant inacceptable.

La propri´ et´ e est syntaxique ou structurelle dans le cas des mod` eles de fautes. Elle est s´ emantique ou comportementale dans le cas des mod` eles d’erreurs.

Les incoh´ erences reposent sur la s´ emantique de v´ erification des constructions du langage UML, c’est-` a-dire sur la bonne fa¸con de constituer un mod` ele UML, et non sur leur s´ emantique op´ erationnelle, c’est-` a-dire sur leurs apports descriptifs dans un mod` ele.

Voici un exemple qui illustre la diff´ erence de ces s´ emantiques en reprenant l’exemple

d’une affectation ´ ecrite en langage ADA. La s´ emantique op´ erationnelle associ´ ee ` a l’ins-

truction « A := B ; » pourrait ˆ etre : « on copie la valeur de l’expression B dans la

variable A » , alors que la s´ emantique de v´ erification serait : « le type de la variable A

et le type de l’expression B doivent ˆ etre identiques » . Cette propri´ et´ e formule un usage

coh´ erent de l’affectation vis-` a-vis de la variable affect´ ee et de l’expression dont la valeur

sera affect´ ee.

Nous nous int´ eressons donc aux r` egles de coh´ erence de l’emploi d’une construction du langage UML et non ` a la fonction qu’elle remplit dans une mod´ elisation.

Dans la suite de notre document, une incoh´ erence est d´ efinie par :

Incoh´ erence Une incoh´ erence est la violation d’une propri´ et´ e associ´ ee au langage UML qui doit ˆ etre respect´ ee par tout mod` ele UML.

Une incoh´ erence peut ˆ etre aussi vue comme la cons´ equence de constructions redon- dantes ou compl´ ementaires incompatibles entre elles. La compatibilit´ e entre les diff´ e- rentes constructions peut ˆ etre exprim´ ee par des r` egles de coh´ erence.

1.3 Vue d’ensemble des travaux

La pr´ esence d’incoh´ erences est intrins` eque ` a la complexit´ e des mod` eles, ` a la diversit´ e des personnes intervenant pour produire ces mod` eles, et ` a leurs modifications en phase de maintenance. Il est donc indispensable de mettre en place une ´ etude permettant de maˆıtriser la pr´ esence de ces incoh´ erences. Notre approche s’est fond´ ee sur un processus de management du risque dont les principales ´ etapes sont :

– l’identification qui a pour but d’´ enum´ erer et de d´ ecrire les risques possibles ainsi que leurs sources,

– l’estimation des risques qui quantifie les risques identifi´ es,

– l’´ evaluation des risques conduisant ` a la hi´ erarchisation des risques ` a partir de leurs estimations mais ´ egalement d’autres crit` eres,

– l’acceptation des risques qui porte un jugement sur les risques hi´ erarchis´ es en fixant un seuil d’acceptabilit´ e, et

– le traitement des risques fournissant des moyens permettant, par exemple, de r´ eduire les valeurs des estimations des risques ` a un niveau acceptable.

Notre travail a tout d’abord consist´ e ` a identifier les types d’´ ev´ enements dom- mageables ´ etudi´ es, c’est-` a-dire les incoh´ erences. Pour cela, nous avons exprim´ e la s´ emantique de v´ erification de chaque ´ el´ ement de base du langage UML, de chaque relation entre ces ´ el´ ements, pour chaque diagramme d´ ecrit par le langage UML, en consid´ erant les r` egles ` a respecter entre les diagrammes. Cette ´ etude est fournie au chapitre 3. Elle est pr´ ec´ ed´ ee par un ´ etat de l’art sur les travaux relatifs aux incoh´ erences (chapitre 2).

L’approche fond´ ee sur le risque suppose que la pr´ esence des ´ ev´ enements domma-

geables que sont les incoh´ erences n’est pas in´ eluctable (attribut de vraisemblance du

risque) et que leurs cons´ equences sont plus ou moins graves (attribut d’importance ou

gravit´ e du risque). Pour ces raisons, nous ´ etudions au chapitre 4 comment les risques

d’incoh´ erence peuvent ˆ etre estim´ es.

Cette estimation permet en particulier d’affecter les moyens n´ ecessaires aux traite- ments de ces risques :

– le refus du risque d’incoh´ erence en interdisant l’usage des constructions UML concern´ ees, approche assez peu satisfaisante, et

– la r´ eduction du risque en fournissant des moyens, par exemple des guides de mo- d´ elisation.

Ces traitements du risque seront ´ etudi´ es au chapitre 5.

Etat de l’art relatif aux incoh´ ´ erences

Notre objectif est d’identifier au chapitre 3, les ´ ev´ enements dommageables que sont les incoh´ erences dans les mod` eles UML. Au pr´ ealable, ce chapitre fournit un ´ etat de l’art sur les moyens d’expression et de d´ etection de ces incoh´ erences.

2.1 D´ etection d’incoh´ erences des mod` eles UML

Le langage UML permet de d´ ecrire plusieurs “vues” d’un mˆ eme syst` eme grˆ ace ` a la notion de diagramme. Cependant ces diff´ erentes vues ne sont pas ind´ ependantes : elles fournissent des informations g´ en´ eralement compl´ ementaires mais aussi fr´ equemment redondantes. De ce fait, ces informations peuvent ˆ etre en conflit, en ´ etant incoh´ erentes [27]. De plus, l’exp´ erience montre que de tr` es nombreuses fautes de mod´ elisation sont perceptibles ` a travers la d´ etection d’incoh´ erences [45].

Les activit´ es de v´ erification sont actuellement surtout effectu´ ees sur le programme source (revue, etc.) et ex´ ecutable (test, etc.). Les entreprises d´ esirent transf´ erer une partie de cette v´ erification vers les mod` eles de sp´ ecification et de conception exprim´ es en UML. Les fautes sont ainsi d´ etect´ ees et corrig´ ees au plus tˆ ot. Ceci permet aussi d’augmenter l’assurance de l’absence de fautes dont la garantie est tr` es difficile ` a obtenir sur des programmes sources complexes. Par ailleurs, on constate qu’un grand nombre de fautes sont introduites lors des phases initiales. En particulier, une grande part des fautes actuelles concerne des probl` emes d’int´ egration de sous-syst` emes qui rel` event des niveaux d’abstraction ´ elev´ es et non du niveau de la programmation. C’est donc lors de ces phases initiales que ces fautes doivent ˆ etre d´ etect´ ees en analysant les mod` eles produits.

Deux approches de la v´ erification sont possibles :

– v´ erifier des assertions formulant des propri´ et´ es propres aux fonctionnalit´ es du sys- t` eme mod´ elis´ e (niveau M1, cf. section 1.1.3), ou

– v´ erifier des propri´ et´ es intrins` eques au moyen de mod´ elisation, ` a savoir UML 2.0 dans notre cas (niveau M2).

La mise en oeuvre de la premi` ere approche est rendue difficile par le fait que son

efficacit´ e ` a d´ etecter des fautes d´ epend de la pertinence des propri´ et´ es exprim´ ees. En cons´ equence, elle d´ epend des comp´ etences des ing´ enieurs qui les formulent. La seconde approche, qui consiste ` a v´ erifier des propri´ et´ es associ´ ees au moyen de mod´ elisation qu’est UML, ne n´ ecessite pas de reformuler ces propri´ et´ es pour chaque application mod´ elis´ ee.

Elle est compl´ ementaire ` a la premi` ere approche en d´ etectant des incoh´ erences des mo- d` eles par la violation de propri´ et´ es exprim´ ees sur les ´ el´ ements du moyen de mod´ elisation

`

a savoir les diagrammes d’UML 2.0 dans notre cas. Ces propri´ et´ es sont exprim´ ees sous forme de r` egles de coh´ erence.

La d´ etection d’incoh´ erences entre les divers constituants des mod` eles est d’autant plus n´ ecessaire que l’expression de vues multiples que permet UML conduit ` a augmenter le nombre de diagrammes et donc le nombre d’incoh´ erences [27].

Dans cette partie, nous pr´ esentons tout d’abord ` a la section 2.2 les ´ etudes existantes sur l’expression et la d´ etection d’incoh´ erences sp´ ecifiques au langage UML. Nous y si- gnalons ´ egalement les limites des r´ esultats de ces ´ etudes. Nous concluons ` a la section 2.3 sur la n´ ecessit´ e d’obtenir une liste exhaustive des r` egles de coh´ erence.

2.2 Etudes actuelles ´

De nombreux r´ esultats ont d´ ej` a ´ et´ e propos´ es sur la coh´ erence des mod` eles UML.

Mais ces ´ etudes sont partielles. Elles sont souvent limit´ ees ` a la v´ erification de quelques propri´ et´ es entre certains diagrammes. Cette limitation est souvent due au choix fait a priori d’une technique de d´ etection.

Dans cette section nous positionnons notre ´ etude dans le cadre des travaux de re- cherche d´ ej` a publi´ es. Pour cela nous consid´ erons 4 crit` eres qui sont abord´ es dans les 4 sous-sections suivantes : le type du mod` ele sur lequel les ´ etudes de coh´ erence sont men´ ees (section 2.2.1) ; les ´ el´ ements du mod` ele consid´ er´ es pour d´ etecter des incoh´ erences (sec- tion 2.2.2) ; le type de propri´ et´ e utilis´ ee pour exprimer les r` egles de coh´ erence (section 2.2.3) ; les techniques mises en oeuvre pour d´ etecter les incoh´ erences (section 2.2.4).

2.2.1 Type de mod` ele ´ etudi´ e

Permettant d’exprimer de multiples points de vue sur un syst` eme, UML favorise l’expression d’informations redondantes.

Cette redondance peut tout d’abord ˆ etre totale : une information d’un mod` ele peut ˆ

etre d´ eduite d’autres informations de ce mod` ele. Par exemple, les diagrammes de com- munication peuvent ˆ etre d´ eduits des diagrammes de s´ equence.

La redondance totale d´ ecrite pr´ ec´ edemment est cependant tr` es limit´ ee. En effet,

chaque vue est une sp´ ecification partielle d´ edi´ ee ` a un aspect technique ou destin´ ee ` a un

type d’utilisateur. Ainsi, il n’existe pas un unique diagramme donnant une vue compl` ete

du syst` eme. Les vues partielles doivent cependant ˆ etre concordantes. On ne cherche donc

pas ` a montrer l’´ equivalence de divers points de vue mais la coh´ erence de l’ensemble. Cette

recherche de coh´ erence doit s’effectuer entre un grand nombre d’´ el´ ements constituant les mod` eles. Par exemple, les diagrammes de machines ` a ´ etats des classes permettent de d´ eduire les interactions acceptables d’une classe prise individuellement. Les sc´ enarios d´ ecrits par les diagrammes de s´ equence expriment les interactions entre diff´ erents objets et doivent ˆ etre conformes avec les interactions acceptables en accord avec le diagramme de classes.

Dans ces ´ etudes, la coh´ erence concerne un seul mod` ele (compos´ e d’un ensemble de diagrammes) d’un syst` eme. Ce mod` ele est associ´ e ` a une phase du d´ eveloppement. On parle de coh´ erence intra-mod` ele.

L’approche inter-mod` ele cherche ` a d´ etecter des incoh´ erences entre plusieurs mod` eles d’un mˆ eme syst` eme. Ces mod` eles peuvent concerner des phases successives du d´ evelop- pement. Dans cette approche, il s’agit de d´ eterminer par exemple qu’un mod` ele d’analyse est coh´ erent avec un mod` ele de conception. [39] ´ etudie la coh´ erence entre des exigences fonctionnelles ´ ecrites en langage naturel et des sp´ ecifications de conception exprim´ ees avec UML. Ces mod` eles peuvent ˆ etre ´ egalement des versions diff´ erentes d’un mod` ele d’un syst` eme, sp´ ecifi´ e comme une collection de diagrammes de classes, de diagrammes de s´ equence et de diagrammes d’´ etats [71].

Nos travaux se limitent ` a l’approche intra-mod` ele.

2.2.2 El´ ´ ements du mod` ele consid´ er´ es

Pour un mod` ele donn´ e (approche intra-mod` ele consid´ er´ ee), les incoh´ erences sont g´ en´ eralement d´ etect´ ees sur les utilisations conjointes d’´ el´ ements d’un unique diagramme ou de plusieurs diagrammes.

La litt´ erature est riche en ´ etudes diverses, la plupart consistant en la d´ efinition et la d´ etection de la coh´ erence au sein d’un seul diagramme ou entre quelques diagrammes sp´ ecifiques. Par exemple, [30] ´ evalue les diagrammes d’activit´ es au moyen d’exigences ex- prim´ ees en logique temporelle lin´ eaire (linear temporal logic en anglais). Les diagrammes de machines ` a ´ etats sont ´ evalu´ es apr` es avoir ´ et´ e transform´ es en r´ eseaux de Petri [77]

par transformation de graphes, ou exprim´ es en Promela [50], langage d’entr´ ee du model- checker SPIN.

Concernant la d´ etection d’incoh´ erences entre plusieurs diagrammes, d’autres travaux traitent des aspects dynamiques afin de d´ etecter des incoh´ erences comportementales. [51]

d´ ecrit une approche algorithmique pour la v´ erification de la coh´ erence entre diagrammes

de s´ equence et diagrammes de machines ` a ´ etats. [49] s’int´ eresse ` a la coh´ erence entre le

diagramme de s´ equence et d’autres diagrammes, par exemple en v´ erifiant la coh´ erence

entre l’invocation d’une m´ ethode et l’´ etat du syst` eme par l’´ etude conjointe des dia-

grammes d’objet et des diagrammes de machines ` a ´ etats. On peut aussi citer [40] qui

traduit les diagrammes comportementaux d’UML en terme de pr´ edicats d’´ etats et qui

utilise le theorem prover PVS (Prototype Verification System). Mais les diagrammes de

composants et de d´ eploiement ne sont pas consid´ er´ es.

Nous constatons donc que ces propositions concernent des ´ el´ ements particuliers du langage UML sans chercher une couverture exhaustive. Elles se limitent ` a un ou plusieurs diagrammes mais sans tenter de consid´ erer l’ensemble des diagrammes UML dans sa totalit´ e. Nous ´ etendons ces travaux en ´ etudiant de fa¸con syst´ ematique les coh´ erences qui doivent exister :

– tout d’abord sur l’utilisation des ´ el´ ements d’UML, ` a l’exception des relations, pris s´ epar´ ement ;

– ensuite sur les relations qui relient ces ´ el´ ements dans la description d’un dia- gramme ;

– puis sur l’expression d’un diagramme int´ egrant ´ el´ ements et relations en consid´ erant chacun des types de diagrammes offerts par UML 2.0 ;

– enfin entre diagrammes.

2.2.3 Type de propri´ et´ e utilis´ ee

Comme d´ ecrit dans [70], UML est un langage semi-formel dont certaines construc- tions peuvent ˆ etre interpr´ et´ ees de fa¸con sensiblement diff´ erente. Notre but n’est pas de figer une seule interpr´ etation mais de d´ efinir pr´ ecis´ ement les interpr´ etations licites ; l’uti- lisation du langage conduisant ` a un mod` ele contenant des incoh´ erences est consid´ er´ ee comme illicite.

La d´ efinition des incoh´ erences n´ ecessite la d´ efinition des propri´ et´ es qui doivent ˆ etre respect´ ees (c’est-` a-dire ce qui est coh´ erent).

On distingue g´ en´ eralement [29] :

– La coh´ erence syntaxique, mettant en jeu la “bonne formation” structurelle de la syntaxe abstraite sp´ ecifi´ ee dans le m´ etamod` ele (well-formedness rule en an- glais). Un exemple typique de r` egle de “bonne formation” est : “Une g´ en´ eralisation consiste en une relation entre un classificateur g´ en´ eral et un classificateur sp´ e- cifique.” Une incoh´ erence associ´ ee ` a cette r` egle serait l’utilisation d’une relation de g´ en´ eralisation entre un classificateur et autre chose qu’un classificateur, par exemple un commentaire.

– La coh´ erence s´ emantique est induite par le sens donn´ e aux constructions du lan- gage. Elle est souvent exprim´ ee en langage naturel et est fr´ equemment d´ efinie par un ensemble de r` egles qui sont difficilement exprimables dans un langage for- mel [28]. Un exemple de r` egle de coh´ erence s´ emantique est : “Toute hi´ erarchie de g´ en´ eralisation doit ˆ etre directe et acyclique.” [59]. Une incoh´ erence associ´ ee ` a cette r` egle serait la pr´ esence d’un cycle dans une hi´ erarchie de g´ en´ eralisation.

Cet exemple illustre que la d´ etection de cette incoh´ erence peut se faire par la syntaxe, mais que l’incoh´ erence porte bien sur le sens donn´ e ` a la relation de g´ en´ e- ralisation qui est une relation d’ordre total. Notons que cette r` egle de coh´ erence s´ emantique est ici exprim´ ee dans [59] sous la forme d’une contrainte OCL.

Nos travaux concernent ces deux aspects.

On distingue ´ egalement la coh´ erence statique ou dynamique [28] :

– La coh´ erence statique d’UML repr´ esente les propri´ et´ es que doit respecter un mo- d` ele UML sans “l’ex´ ecuter”. Elle est d´ ecrite formellement par le m´ etamod` ele et des contraintes OCL, ainsi que de mani` ere textuelle. Elle peut ˆ etre v´ erifi´ ee entre autres par une inspection statique du mod` ele. Par exemple, cette contrainte s´ emantique est d’ordre statique : “Une contrainte attach´ ee ` a un st´ er´ eotype ne doit pas rentrer en conflit avec aucune des contraintes d’aucun st´ er´ eotype h´ erit´ e, ou avec aucune contrainte de la classe de base.”

– La coh´ erence dynamique repr´ esente les propri´ et´ es ` a respecter qui seront v´ erifi´ ees

`

a l’ex´ ecution. UML n’´ etant pas ex´ ecutable, ces contraintes dynamiques doivent ˆ

etre embarqu´ ees dans un formalisme ex´ ecutable (comme le code source). En cons´ equence elle ne peut pas toujours ˆ etre compl` etement v´ erifi´ ee avant l’ex´ ecution du programme d´ eriv´ e du mod` ele. Par exemple, il n’est pas possible de v´ erifier statiquement qu’une pr´ econdition d’une op´ eration est satisfaite avant que l’op´ e- ration n’ait ´ et´ e appel´ ee dans un diagramme d’interaction.

On peut noter que la s´ emantique d’UML restant ambig¨ ue sur certains points, elle offre la possibilit´ e de plusieurs interpr´ etations diff´ erentes. Un exemple est l’absence de sp´ ecification de la strat´ egie pour d´ efiler les ´ ev´ enements produits par une machine

`

a ´ etats [70]. Cet ´ etat de fait aura pour cons´ equence de rendre la v´ erification de la coh´ erence d´ ependante de choix faits par les concepteurs sur ces ambigu¨ıt´es r´ emanentes.

Nous nous int´ eressons aussi bien aux coh´ erences statiques que dynamiques.

Notre ´ etude cherche donc ` a identifier toutes les propri´ et´ es sur les mod` eles qui sont ind´ ependantes des fonctionnalit´ es du syst` eme mod´ elis´ e et du processus de mod´ elisation, que ces incoh´ erences soient syntaxiques ou s´ emantiques, statiques ou dynamiques.

Elles concernent uniquement les contraintes venant du formalisme UML. Certaines de ces propri´ et´ es sont exprim´ ees dans la norme soit en OCL, soit d’une fa¸con textuelle.

Notre ´ etude ´ etend l’expression des well-formedness rules d’UML et reprend les r` egles textuelles qui n’ont pas (encore) ´ et´ e traduites en OCL et en d´ efinit de nouvelles.

Enfin nous pouvons mentionner que certaines r` egles sp´ ecifiques ` a la plate-forme et ` a l’implantation, dernier niveau de la classification des contraintes d´ efinie dans [69], ont aussi ´ et´ e d´ efinies lors de nos ´ etudes.

D’autres ´ etudes proposent d’autres propri´ et´ es. Par exemple, [26] v´ erifie la plupart des

crit` eres g´ en´ eraux de sˆ uret´ e d´ efinis par N. Leveson [48] ( “Toutes les variables doivent ˆ etre

initialis´ ees” , “Tous les ´ etats doivent ˆ etre atteignables” , etc.) concernant une forme r´ eduite

des statecharts. [77] v´ erifie les propri´ et´ es comportementales que sont les interblocages

(deadlocks en anglais) ou les probl` emes d’atteignabilit´ e (reachability), le caract` ere born´ e

(boundedness), la vivacit´ e (liveness), etc., sur les r´ eseaux de Petri obtenus par trans- formation de mod` eles UML. Mais l’approche propos´ ee n’a ´ et´ e valid´ ee qu’en partant de diagrammes de machines ` a ´ etats. L’intention des auteurs est de v´ erifier les corr´ elations qui existent entre diagrammes (r` egles de coh´ erence inter-diagrammes) en les prenant en compte lors des transformations de diagrammes UML en r´ eseaux de Petri.

Notre but est de fournir toutes les propri´ et´ es exprimant la coh´ erence des mod` eles UML afin d’´ elargir le nombre de fautes de mod´ elisation d´ etect´ ees. D’autres travaux cherchent ´ egalement ` a ´ etablir des mod` eles de fautes possibles. Comme exemple, on peut citer des ports de composants non connect´ es dus ` a un connecteur manquant, ce qui a pour effet d’empˆ echer la r´ eception de messages. Un autre exemple est un ´ etat manquant dans une machine ` a ´ etats [12]. Cette ´ etude parle de ”mod` eles de fautes” que l’on peut voir comme des fautes g´ en´ eriques exprimant chacune une possible incoh´ erence. Le sch´ ema 2.1 illustre comment un ensemble de fautes de mˆ eme type au niveau mod` ele peut ˆ etre vu au niveau m´ etamod` ele UML comme un mod` ele de faute (g´ en´ erique) et que l’on pourra retrouver par instanciation dans n’importe quel mod` ele. Ce mod` ele de faute est donc associ´ e au langage UML et les r` egles de coh´ erence que nous fournissons sont d´ efinies ` a ce niveau-l` a.

(avec des règles sur Le langage UML

Un modèle UML

généralisation 1 modèle de faute associé au langage UML

instanciation

(devant respecter les instances

= 1 incohérence

fautes du même type sur le modèle de règles du niveau métamodèle)

le métamodèle UML)

Fig. 2.1: Mod` ele de faute et incoh´ erence

Mentionnons ´ egalement que si les incoh´ erences signalent la pr´ esence certaine de fautes

dans les mod` eles, toute faute ne g´ en` ere pas des incoh´ erences et ne peut pas ˆ etre d´ etect´ ee

par l’approche propos´ ee. En effet, une faute sp´ ecifique, ou propre au probl` eme trait´ e,

ne pourra pas ˆ etre d´ etect´ ee. Si l’expression de la propri´ et´ e est g´ en´ erale, sa d´ etection,

n’est possible qu’en disposant d’informations suppl´ ementaires issues par exemple d’un

mod` ele de d´ epart ou de documentations. En d’autres termes, un mod` ele UML coh´ erent

peut cependant poss´ eder une ou plusieurs fautes de conception. La v´ erification de la

coh´ erence permet cependant de d´ etecter un certain nombre de ces fautes.

2.2.4 Technique de d´ etection

Les moyens utilis´ es pour exprimer et d´ etecter des incoh´ erences ont une grande influence sur les travaux effectu´ es. Les types d’incoh´ erences consid´ er´ es par les ´ etudes sont souvent tr` es r´ eduits du fait de ces choix. C’est pour cette raison que nous avons

´

etabli des r` egles de coh´ erence sans chercher ` a prendre en compte le moyen de leur expression ni les techniques ou outils n´ ecessaires ` a la d´ etection du non-respect des r` egles. Cependant, dans cette sous-section, nous synth´ etisons les approches utilis´ ees pour mettre en oeuvre expression et d´ etection. Nous les pr´ esentons en les regroupant en deux grandes familles : l’approche transformationnelle et l’approche qui tend ` a enlever l’ambigu¨ıt´e d’UML, soit en offrant de meilleures contraintes ` a UML, soit en tentant de d´ efinir une s´ emantique formelle pour le m´ etamod` ele d’UML. Nous mettrons l’accent sur la premi` ere famille d’approches qui est la plus classique.

La premi` ere famille dite approche transformationnelle consiste ` a traduire les ´ el´ ements d’un ou de plusieurs diagrammes UML dans un langage for- mel puis d’analyser des propri´ et´ es associ´ ees au mod` ele formel obtenu. Par exemple, [64] a d´ efini pour des types particuliers (statecharts) puis pour des types plus larges de machines ` a ´ etats, une s´ emantique CSP (Communicating Sequential Processes). [29]

transforme les mod` eles UML vers CSP pour v´ erifier des propri´ et´ es dynamiques concer- nant les diagrammes de classes et les machines ` a ´ etats associ´ ees. Afin de v´ erifier des propri´ et´ es dynamiques exprim´ ees en CTL, [30] consid` ere le diagramme d’activit´ es et le transforme en syst` eme de transitions (transition system en anglais). On pourrait citer d’autres exemples bas´ es sur divers formalismes : une alg` ebre des processus exprim´ ee en RT-LOTOS pour le profil d’UML TURTLE [14], l’alg` ebre logique [15] ou encore B [55].

L’approche transformationnelle est int´ eressante car elle permet d’utiliser les capacit´ es d’analyse des langages formels cibles et permet ainsi de d´ etecter un certain nombre d’incoh´ erences. Elle est sch´ ematis´ ee ` a la figure 2.2.

En revanche, la traduction d’un langage “ambigu” (UML) vers une notation formelle requiert de prendre des d´ ecisions pour r´ eduire l’ambigu¨ıt´e, choix qui ont pour cons´e- quence de figer la s´ emantique du langage “ambigu” selon [28].

Cette approche pr´ esente plusieurs autres inconv´ enients :

– Premi` erement, ces ´ etudes ne concernent que certaines caract´ eristiques de certains diagrammes d’UML dont la traduction peut ˆ etre faite dans le langage formel choisi.

Par exemple, certains aspects dynamiques des mod` eles UML vers les r´ eseaux de Petri.

– Deuxi` emement, les propri´ et´ es v´ erifi´ ees sont restreintes ` a celles analysables par le langage formel (par exemple, la vivacit´ e pour les r´ eseaux de Petri).

– Troisi` emement, une fois une propri´ et´ e du mod` ele formel ni´ ee, les outils signalent

tr` es rarement les ´ el´ ements du mod` ele UML qui sont ` a l’origine de l’incoh´ erence

r´ ev´ el´ ee [27].