Fiança

Le problème de construction d’un pont entre le monde des besoins et le monde des

spécifica-tions formelles n’est pas récent. Il a été étudié par plusieurs approches comme l’approche d’Abrial,

KAOS, ProR et l’approche agile qui contribuent à la réduction de l’écart entre ces deux mondes via

des interactions et des échanges. Le pont établi est important pour assurer la communication entre

deux documents de différentes natures : un qui est écrit en langage naturel et qui peut contenir tout

type d’imperfection et un autre très rigoureux écrit en langage de spécification formelle comme B

événementiel, LTL ou TLA

⁺

. L’importance des interactions réside dans la détection des incohérences

et lacunes des besoins et contribue à l’obtention d’un système ou logiciel de qualité.

Les deux mondes des besoins et des spécifications formelles doivent évoluer en même temps. Une

manière de faciliter cette évolution est de recourir à la réutilisation, une notion clé en génie logiciel.

Parmi les idées proposées dans ce contexte, les patrons émergent comme un concept important

four-nissant un guide et une aide aux développeurs. Ils permettent d’éviter de refaire le travail pour des

problèmes similaires. Les patrons de GoF se présentent lors de la phase de conception et

d’implé-mentation pour favoriser la réutilisation. Bien qu’ils soient rigoureusement décrits selon un canevas,

ceux-ci souffrent d’un manque de sémantique associée au code et aux diagrammes UML fournis. Ce

qui complique la tâche de leur réutilisation. Une telle tâche englobe le choix du patron adapté au

pro-blème en question et son intégration. Quant aux patrons de spécification formelle, ils sont proposés

dans une phase amont dans le développement. Des outils permettant l’automatisation de certaines

par-ties du développement des spécifications grâce à ces patrons ont été mis en place. Ces modèles sont

très spécifiques au domaine et ne seront pas réutilisés en dehors de ce domaine particulier.

Notre approche

Sommaire

3.1 Vue d’ensemble . . . . 45

3.1.1 Constituants . . . . 47

3.1.2 Outils . . . . 48

3.2 Description détaillée . . . . 48

3.2.1 Structuration du cahier des charges du client . . . . 49

3.2.2 Préparation du développement . . . . 51

3.2.3 Évolution du système . . . . 52

3.3 Système < CdC, Liens, Spec > . . . . 59

3.3.1 Utilisation des outils . . . . 60

3.3.2 Patrons de développement . . . . 61

3.3.3 Détection des oublis . . . . 62

3.4 Conclusion . . . . 62

Dans ce chapitre, nous présentons notre approche de gestion des exigences, de leur spécification

formelle et des liens entre eux. Nous définissons le système < CdC, Liens, Spec > et décrivons son

évolution tout au long du processus de développement. Notre démarche utilise les concepts du génie

logiciel tels que la généricité et les approches de réutilisation de l’existant.

3.1 Vue d’ensemble

La construction des systèmes et logiciels dans un cycle en V [Forsberg and Mooz, 1991] passe par

les phases suivantes :

1. Analyse et expression des besoinsdurant laquelle les besoins du client sont recueillis et gérés

dans un cahier des charges.

2. Spécificationau cours de laquelle ce que fait le futur système est décrit. Il s’agit de décrire "le

quoi ?"

3. Conception générale, appelée aussi conception architecturale, qui consiste à élaborer une vue

d’ensemble du système en le spécifiant sous forme de modules et de communications entre eux.

4. Conception détailléedurant laquelle les détails de chaque module sont introduits en précisant

5. Codageou implantation des modules en utilisant un langage de programmation.

6. Tests unitairesayant pour objectif de tester chaque unité du programme développé.

7. Test d’intégration au cours duquel l’assemblage des modules ou des programmes développés

est testé pour vérifier leur coopération et leur fonctionnement global.

8. Test de validation, appelé encore test fonctionnel, permettant de tester le système développé.

9. Test d’acceptation, ou recette, visant à assurer que le système final est conforme aux besoins du

client.

Notre travail s’organise autour des deux premières phases du processus en V, voir figure 3.1.

Nous nous intéressons à la gestion et l’évolution en permanence des exigences et de leur spécification

formelle.

Analyse et

expression

des besoins

Test

d’acceptation

Spécification ^{Test de}

validation

Conception

générale

Conception

détaillée

Test

d’intégration

Tests unitaires

Codage

FIGURE3.1 – Place de notre approche dans un processus en V

Notre approche, présentée dans la figure 1.2 du chapitre introductif de ce mémoire, fait intervenir

deux mondes : celui du semi-formel - décrit par un CdC regroupant les besoins réécrits du client - et

le formel présenté par la spécification appelée Spec dans la suite. La différence majeure entre notre

approche et les deux premières phases du cycle en V est que nous considérons que ces deux étapes

(ainsi que leurs documents correspondants) évoluent en même temps. Notre approche est décrite selon

deux parties de nature différente qui se complètent :

- une partie statiquereprésentant l’état actuel du système et composée des éléments CdC, Liens et

Spec et

- une partiedynamiquequi concerne les décisions de développement et les traitements. Celle-ci

s’in-téresse à l’évolution du système pour l’obtention d’un nouvel état décrit par un système < CdC

⁰

,

Liens

⁰

, Spec

⁰

>.

3.1.1 Constituants

3.1.1.1 CdC

Nous faisons la différence entre le cahier des charges du client, lorsqu’il existe, et celui que nous

construisons et appelonsCdC:

- le premier document concerne les besoins décrits par le client. Il n’est pas modifiable dans notre

approche. Nous l’utilisons en consultation pour comprendre le futur système. En se référant à

l’approche de Jean-Raymond Abrial [Abrial, 2010], ce document est considéré comme un texte

explicatif et

- le deuxième document, CdC, est construit d’après notre compréhension des besoins du client. C’est

le document de référence pour toutes les étapes de notre approche. Il résulte d’une étape de

réécriture du cahier des charges du client sous forme d’une suite de phrases courtes,

hiérarchi-sées, typées et étiquetées. Une phrase peut contenir des termes formels intégrés dans son texte

informel. Ces termes proviennent de la Spec associée au CdC. Ce dernier évolue tout au long du

processus de développement. La forme de ce document adoptée dans notre approche est décrite

dans le paragraphe 3.2.2.

3.1.1.2 Spec

Désignant la spécification formelle, elle constitue le deuxième composant de notre approche. Nous

avons choisi de travailler en grande partie de notre approche en utilisant la méthode formelle B

évé-nementiel pour développer cette Spec. Ce choix est justifié par :

- la facilité du développement des modèles et systèmes utilisant la technique de raffinement : un

système complexe est construit progressivement en introduisant ses détails pas à pas,

- l’aspect rigoureux du développement avec cette méthode : chaque modèle développé doit être

vé-rifié. Le passage de ce modèle au modèle raffiné nécessite la vérification de la correction du

raffinement,

- l’existence des outils sous Rodin permettant l’automatisation de certaines étapes comme la

vérifi-cation, la validation et la gestion des Liens entre le CdC et la Spec et

- la possibilité de communiquer entre les besoins et la Spec via les plugins de Rodin tels que ProR et

ProB. Ceci réduit l’écart entre les deux mondes. L’évolution de la Spec est couplée avec celle

du CdC et des Liens entre eux.

Nous montrons dans le chapitre 7 que notre approche est applicable en utilisant la méthode

for-melle TLA

⁺

.

3.1.1.3 Liens

Ils sont établis lorsque nous commençons la construction de la Spec. Ils sont mis en place dans les

deux sens : de la Spec vers le CdC et inversement. Grâce aux outils existants comme ProR, ces liens

sont gérés, automatiquement mis à jour et propagés tout au long du développement. Ils sont présentés

par unglossairedécrit comme suit :

Formal term Informal description

Ce glossaire est constitué de couples(Formal term, Informal description)dans lesquels le premier

élément représente le terme formel issu de la Spec et le second décrit la définition informelle

corres-pondante à ce terme dans le CdC. Sur le plan pratique, sous l’outil ProR, ces liens se matérialisent

par :

- Des termes formels venant de la Spec et introduits entre crochets [ ] dans les phrases du CdC. Un

[terme_formel] exprime une relation de traçabilité entre les deux mondes formel et semi-formel.

Son introduction se présente comme suit :

ID Description Link

Req_ID Ceci est un [terme_formel] introduit dans la description informelle

d’une phrase du CdC

. . .

FIGURE3.2 – Introduction d’un terme formel dans le CdC sous ProR

- Le contenu de l’élémentLink, décrit dans le chapitre 2 section 2.3.2.2. L’introduction d’un terme

formel dans le CdC se réalise par la création d’un lien sous forme d’une adresse reliant ce terme

formel de la Spec avec la phrase correspondante du CdC.

3.1.2 Outils

Notre approche commence par une étape de compréhension de la demande du client exprimée

à partir de son cahier des charges. Si ce document n’est pas assez clair, nous enrichissons sa

docu-mentation par l’utilisation des images et des vidéos explicatives. Rodin, plateforme utilisant Eclipse,

est dotée de plusieurs outils et plugins favorisant la réécriture des besoins, leur formalisation en B

événementiel, la vérification, la validation et la visualisation du système < CdC, Liens, Spec >. Ces

outils, utilisés à tout moment du développement, sont :

- ProR pour la gestion du CdC et des Liens. Outre la structure hiérarchique des exigences qu’il offre,

cet outil permet d’établir des liens entre les exigences du CdC et les éléments formels de la

Spec.

- Des générateurs d’obligations de preuve OPs permettant de générer l’ensemble des preuves relatives

à la Spec et présentées sous forme de séquents. La structure d’un séquent est décrite dans le

paragrapheVérificationde la section 2.2.3.3 du chapitre 2.

- Des prouveurs automatiques et interactifs pour vérifier la correction mathématique de la Spec en

cours de construction en prouvant les OPs générées.

- Des outils comme ProB, JeB et AnimB pour la validation de la Spec relativement au CdC.

- Des outils de visualisation graphique donnant une vue d’ensemble des contextes et machines de

la Spec comme l’outil Project Diagram

⁴³

ou décrivant l’état de la Spec comme l’outil EventB

StateMachines

⁴⁴

.

No documento Cartas de conforto (páginas 33-40)