Méthodes Formelles

Olfa BELKAHLA DRISS

Maître de Conférences, ESCT
Laboratoire LARIA, ENSI

1ère année mastère de Recherche

Informatique Décisionnelle et Intelligente Appliquée à la Gestion (IDIAG)
 Génie logiciel
 Ensemble des techniques et des méthodes
permettant de produire du logiciel, de A à Z

 Ensemble des activités de conception et de mise

en œuvre des produits et des procédures pour
rationaliser la production logiciel et son suivi
(maintenance)

 C’est l’art de spécifier, concevoir, réaliser et faire

évoluer des programmes, des documentations et
des procédures de qualité, avec des moyens
plausibles et dans des délais raisonnables
Méthodes Formelles - O.Belkahla Driss 2
 Génie logiciel
Rôle de l’informaticien :
• Modéliser et utiliser ce modèle comme référence ;
• Traduire un cahier de charges vagues en spécifications
précises ;
• Communiquer avec tous les intervenants ;
• Transmettre les informations à l’utilisateur en terme
d’application et non de problème d’ordinateur ;
• Maîtriser les différents niveaux d’abstraction ;
• Spécifier ;
• Programmer ;
• Faire les preuves de programmes et vérifications ;
• S’occuper de la maintenance.
Méthodes Formelles - O.Belkahla Driss 3
 Génie logiciel
Le génie logiciel propose des méthodes et des outils pour :
• Faciliter la communication ;
• Organiser des projets (planification et communication
pour le travail en équipe) ;
• Documenter, définir et respecter des normes ;
• Estimer les coûts et les délais ;
• Organiser les ressources (humaines, matérielles et
logicielles) ;
• Suivre l’évolution du logiciel (maintenance, cycle de vie) ;
• Mesurer la qualité des logiciels utilisés.

Méthodes Formelles - O.Belkahla Driss 4

Le processus de développement d’un logiciel

1. Étude de faisabilité
2. Spécification
3. Organisation du projet
4. Conception
5. Implémentation
6. Tests
7. Livraison
8. Maintenance

Méthodes Formelles - O.Belkahla Driss 5

 Qu’est-ce qu’un cycle de vie logiciel ?

Période qui débute au moment de la définition et du

développement d'un logiciel et se termine lorsque le logiciel
n'est plus disponible pour utilisation [Définition de l'IEEE]

Modèle du cycle de développement du logiciel =

Description idéalisée et simplifiée des activités de
développement (descriptif)
Description de ce qui est supposé se passer durant le
développement (prescriptif)

Répond donc aux questions suivantes :

Qu'est-ce qui sera fait ?
Dans quel ordre les différentes tâches seront réalisées ?

Méthodes Formelles - O.Belkahla Driss 6

 Qu’est-ce qu’un cycle de vie logiciel ?

 Enchaînement des activités de développement

logiciel ;
 Définition des Pré et Post conditions pour chaque
phase ;
 Procédures de gestion et d’encadrement ;
 Procédures de mesures ;
 Cycle de vie logiciel : synonyme de méthodologie
logiciel.

Méthodes Formelles - O.Belkahla Driss 7

 Qu’est-ce qu’un cycle de vie logiciel ?

• Etapes d’un cycle de vie

– Analyse : opportunité fonctionnelle et faisabilité technique ;
– Conception : choix tactiques de réalisation et d’architecture ;
– Codage : réalisation informatique du détail des opérations ;
– Test : tests unitaires et tests d’intégration.

• Les deux grandes catégories de cycles de vie :

– Les cycles linéaires : succession d’étapes ordonnées (cycle
en cascade, cycle en V)
– Les cycles de vie itératifs : réalisation incrémentale par
évolutions (modèle de la cascade plusieurs variantes, modèle en V,
modèle du prototypage, modèle de la programmation exploratoire,
modèle en spirale, modèle incrémental)

Méthodes Formelles - O.Belkahla Driss 8

 Modèle en cascade [Royce70, Boehm76]

Analyse
spécification V&V

Conception
V&V
architecturale

Conception
V&V
détaillée

Codage V&V

Tests V&V

Exploitation /
Maintenance

Méthodes Formelles - O.Belkahla Driss 9

 Caractéristiques du modèle en cascade

• Chaque étape du cycle est caractérisée par des ACTIVITES dont

le but est d’élaborer un ou des produits intermédiaires ;

• Chaque fin d’étape est matérialisée par un événement, où

s’exerce une activité de contrôle (VERIFICATION et VALIDATION)
afin d’éliminer au plus tôt les anomalies des produits réalisés. Le
passage à l’étape suivante est conditionné par le résultat de
contrôle (acceptation, rejet, ajournement) ;

• Autant que possible, les retours en arrière sur les étapes

précédentes se limitent à un retour sur l’étape immédiatement
antérieure.

Méthodes Formelles - O.Belkahla Driss 10

 Cycle de vie & assurance qualité
sont fortement liés; il faudra donc en permanence assurer :

 la validation : sommes-nous en train de faire le bon produit ?

 la vérification : est ce que nous faisons le produit correctement ?

• La validation et la vérification sont en général garanties par la mise en

place d'inspections et de revues. L'inspection est une lecture critique
d'un document (spécification, conception, code, plan d'intégration...);
elle est destinée à améliorer la qualité d'un document.

• De manière générale, l'inspection est faite par une équipe

indépendante du projet (un Modérateur, un Expert, Secrétaire, le
client éventuellement un banquier, un représentant du service
qualité...)

Méthodes Formelles - O.Belkahla Driss 11

 Analyse et spécification vs. conception

Intuitivement, l'analyse répond à la question :

Que fera le système ? QUOI ? Mais ... plusieurs niveaux de QUOI ?

(a) Les besoins et exigences des usagers

(b) L’espace des solutions possibles
(c) Une solution particulière
(d) La structure interne de la solution choisie
(e) La description des modules (interfaces)
(f) Les algorithmes
(g) Le code final

Méthodes Formelles - O.Belkahla Driss 12

 Analyse et spécification vs. conception
L’étape d'analyse et spécification porte sur :

1. Analyse du problème = Analyser et comprendre le problème à

résoudre, les besoins et exigences des usagers, les contraintes à
respecter = (a)+(b)

2. Spécification du produit = Décrire le logiciel qui va satisfaire aux

besoins et exigences et qui va respecter les contraintes = (c)

Exigences et besoins vs. spécifications (selon M. Jackson) :

• Exigences et besoins = phénomènes de l’environnement

• Spécifications = phénomènes à l’interface entre l’envrt . et la machine

• Programmes = phénomènes internes à la machine

Méthodes Formelles - O.Belkahla Driss 13

Pourquoi une spécification est-elle importante ?

Spécification Besoins et exigences

= contrat à satisfaire
Validation
Spécification comportementale
ou fonctionnelle du système
Validation : Are we building Validation Vérification
the right product ?
= Construit-on le bon produit ?

Vérification : Are we building

the product right ?
= Construit-on le produit Structure interne ou
correctement ? architecture du système
Vérification
Mise en œuvre du système
(pgme exécutable)

Méthodes Formelles - O.Belkahla Driss 14

 Analyse et spécification vs. conception
La conception vise à répondre aux questions suivantes :
 Comment le système sera-t-il construit ?
 Quelle sera sa structure interne ?
 Comment fonctionnera-t-il ?

Deux grandes composantes de la conception :

 Conception architecturale :
 Quels sont les principaux modules ?
 Comment sont-ils organisées et structurées ?
 Quelles sont les interfaces entre les modules ?
 Conception détaillée (procédurale) :
 Que fait précisément chacun des modules ?

Analyse et spécification : Conception : Concepts et

Analyse et
Concepts et interfaces spécification interfaces pour construire
pour utiliser le système vs. le système (point de vue
(point de vue de conception du constructeur)
l'usager)
Méthodes Formelles - O.Belkahla Driss 15
 Enoncés informels / Enoncés semi-formels /
Méthodes formelles de spécification
Enoncés informels : En langue naturelle, avec (ou sans) respect
de normes  Problèmes d’incohérence, d’ambiguïté,
d’incomplétude, de redondance des informations.

Enoncés semi-formels : Dictionnaires de données (Merise)

• Définition des termes utilisés classés (par fonction, par sous
domaine, etc.) souvent présentés par ordre alphabétique.
• Précisent les synonymes, alias, symboles, domaines, unités utilisées
• exemple : informations sur les fichiers, les dépendances, les versions
• génération automatique (Windesign, Javadoc,…)
Autres exemples : Diagramme de flux , MCD, Les Use Cases

Méthodes formelles : Insuffisance des méthodes «semi formelles» :

imprécises et floues, Présence de langage naturel, Interprétable selon
l’utilisateur ;
Une méthode formelle suit une syntaxe bien définie (comme un
langage de programmation) et sa syntaxe est accompagnée d’une
sémantique rigoureuse. Méthodes Formelles - O.Belkahla Driss 16
 Pourquoi les méthodes formelles ?
Complexité croissante des systèmes informatiques
=> difficulté de développement
→ risques de retards
→ risques de surcoûts
⇒ risques de défaillances dues à des erreurs de conception…
⇒ conséquences graves (économiques, humaines …)

Réponse : « Ingénierie » des systèmes, logiciels, protocoles

art de spécifier, concevoir, réaliser et faire évoluer
– avec des moyens (langages, modèles de développement, méthodes…)
– des systèmes, logiciels, protocoles… mettant en œuvre des
programmes informatiques
tels que : des protocoles, des systèmes de contrôle et commande, des
systèmes temps réel, des systèmes de gestion...

Méthodes Formelles - O.Belkahla Driss 17

 Pourquoi les méthodes formelles ?
Mais ?
Cela suffira-t-il pour faire face à l’accroissement continu de la
complexité des systèmes ?

Non : problème du « mur » de la complexité !

Certains organismes imposent déjà l'utilisation de techniques
mathématiques dans le développement de systèmes informatiques :
→dans le domaine de la sécurité : obligation d'utiliser des méthodes
formelles pour certains niveaux de sécurité
→dans le ferroviaire… (métro Météor)

=> Les Méthodes Formelles : pour démontrer qu'un système

(un protocole, un système embarqué…) fonctionne comme
désiré !

Méthodes Formelles - O.Belkahla Driss 18

 Pourquoi les méthodes formelles ?

L’ambition initiale des techniques formelles :

 Supprimer les phases de tests lors de la conception des

programmes
 Tests coûteux en temps et donc en argent
 Tests fastidieux pour le développeur
 Le test n’est jamais exhaustif : il ne peut pas vérifier
toutes les exécutions possibles du système

Méthodes Formelles - O.Belkahla Driss 21

Comment ça marche ? Le cahier des
charges de S

informel ou semi-formel formel explicitation et formalisation

En : exigences
abstraction M' : de fonctionnement
M: un modèle E2 : exigences
le modèle du système simplifié E1 de fonctionnement
: exigences
(en UML, SDL,
(en systèmes de transitions...) de fonctionnement
RdP, java, C,… )
(en logique
production, temporelle...)
compilation…
Outil de
vérification
(model checker, prouveur...)

S: réponse :
le système pour
lequel on exige un - S satisfait les exigences E1… En
fonctionnement - S ne satisfait pas l'exigence Ei
correct (avec contre-exemple à l'appui)
- pas Driss
Méthodes Formelles - O.Belkahla de réponse 20