Introduction aux méthodes formelles

INF3143
Modélisation et spécification
formelles des logiciels
Hiver 2017
Alexandre Terrasa
Département d’informatique, UQÀM
Présentation du cours
2
Description du cours
Initiation aux méthodes formelles de spécification
● mode descriptif vs. mode opérationnel
● assertions, contraintes et contrats
Liens avec le cycle de vie des logiciels
● spécification
● tests et vérifications
3
Objectifs du cours
À la fin du cours, vous serez capable de
● lire et naviguer dans des diagrammes de classes UML
● utiliser la logique et les assertions pour spécifier un
comportement
● écrire des contraintes et des contrats en plusieurs
notations
Et ainsi,
● de spécifier et modéliser des logiciels
● en utilisant des méthodes formelles
4
Déroulement du cours
Cours magistraux
● G20: Mardi, 09h30 à 12h30 au PK-2205
● G21: Mardi, 18h00 à 21h00 au SH-3560
Les notes de cours, ressources et TPs sont
diffusés sur la page du cours:
info.uqam.ca/~terrasa/cours/INF3143/
5
Évaluation
TP 1 (15 %) par groupe de 2 personnes
● UML et OCL
● distribué le 24/01 à remettre le 14/02
Examen Intra (35 %) - le samedi 04 mars
TP 2 (15 %) par groupe de 2 personnes
● Contrats et vérification
● distribué le 28/03, à remettre le 18/04
Examen Final (35 %) - le samedi 29 avril
6
Rappel sur le plagiat
Le plagiat c’est mal!
Pour plus de détails, consulter le règlement
#18 sur les infractions de nature académique.
Rappel: le plagiat c’est mal!
7
Communiquer avec moi
Par email
● [email protected]
En personne
● après le cours
● sur rendez-vous
8
Délais de réponse
9
Spécification de
logiciels
10
Questions?
●
●
●
●
qu’est-ce que le cycle de vie d’un logiciel?
qu’est-ce que la spécification d’un logiciel?
quelle différence avec la conception?
importance de la spécification?
11
Le cycle de vie des logiciels
Selon l’IEEE (1991)
“ La période de temps qui débute au moment de la
définition et du développement d’un produit logiciel et se
termine lorsque le produit logiciel n’est plus disponible
pour utilisation. ”
Le cycle de vie comporte différentes étapes
● en fonction du type de projet
● en fonction de la méthodologie adoptée
12
Modéliser le cycle de vie
Modèle de cycle de vie : représentation idéale
et simplifiée des principales activités durant le
développement.
Décrire ce qui est censé se passer durant le
développement :
● Qu’est-ce qui sera fait ?
● Dans quel ordre ?
● Quand le processus termine-t-il ?
13
Intérêts d’un modèle de cycle
de vie ?
● fournir un vocabulaire de base
○ faciliter la communication
○ pour tous les acteurs (utilisateurs, clients,
gestionnaires, développeurs)
● rendre explicite les étapes du développement
○ rendre visible le processus
○ montrer les étapes et leurs relations
● permettre la gestion et le contrôle du
processus
14
Modèle en cascade
Illustration:
http://www.commentcamarche.net/contents/473-cycle-de-vie-d-un-logiciel
15
Modèle en V
Illustration:
http://www.commentcamarche.net/contents/473-cycle-de-vie-d-un-logiciel
16
Points communs entre les
modèles
Beaucoup de modèles
● cascade, V, spirale, semi-itératif, itératif...
Mais beaucoup de points communs
●
●
●
●
analyse et spécification
conception générale et détaillée
implémentation
tests et validation
17
Analyse et spécification
Analyse du problème
● comprendre le problème à résoudre
● les besoins et exigences des usagers
● les contraintes à respecter
Description du produit
● décrire le système qui satisfera aux
besoins et aux exigences
● respectera les contraintes
18
Document de Spécification
du Logiciel (DSL)
Document contractuel avec le client décrivant
ses besoins et exigences
● résultat de l’analyse des besoins du client
● décrit les fonctionnalités requises du
système à développer
● énoncé du problème auquel le concepteur
devra trouver une solution
19
Conception
Selon l’IEEE (1991)
“Processus qui consiste à définir l’architecture du
logiciel, les composants, les modules, les interfaces, les
stratégies de tests et les données qui feront en sorte
que le système logiciel va satisfaire aux spécifications.”
Pour apporter une solution au problème
● Comment le système sera-t-il construit ?
● Quelle sera sa structure interne ?
● Comment fonctionnera-t-il ?
20
Distinction entre
spécification et conception
Spécification
=
QUOI ?
● que fera le système ?
Conception
=
COMMENT ?
● comment le système sera-t-il construit ?
21
En fonction du point de vue
Spécification
=
Vue extérieure
● comportement observable du système
Conception
=
Vue intérieure
● rouages internes
22
En fonction de l’acteur
Spécification
=
Utilisateurs
● concepts et interfaces pour utiliser le
système
Conception
=
Développeurs
● concepts et interfaces pour construire le
système
23
Importance de la
spécification
Contrat entre le client et le développeur
● attentes du client
● limites du projet
Le système doit satisfaire la spécification
● rien de moins, rien de plus
● obligation pour le développeur
24
Validation et vérification
Processus consistant à s’assurer qu’un
système satisfait une spécification.
Validation
Construit-on le bon produit ?
Are we building the right product?
Vérification
Construit-on le produit correctement ?
Are we building it right?
25
Validation et Vérification dans le cycle de vie
VALIDATION
VÉRIFICATION
VÉRIFICATION
26
Exercice
Spécification ou conception?
● Le calcul doit s’effectuer en moins d’une minute.
● Les listes de produits sont implémentées avec des listes
chaînées.
● La classe Homme dépend de la classe Personne.
● Si aucun paramètre n’est fourni, le système produit une
erreur et s’arrête.
● Les échanges doivent être sécurisés avec HTTPS.
● Les échanges entre les modules A et B sont en JSON.
27
Impacts de la spécification
Elle guide le projet
● fonctionnalités à développer
● contraintes à respecter
● processus de validation et vérification
Impacts d’une mauvaise spécification :
Selon certaines études, 45 à 55% des problèmes
rencontrés lors des tests, seraient en fait des erreurs
dans la compréhension du problème ou la formulation
de la solution.
28
Résumé
● qu’est-ce que le cycle de vie d’un logiciel?
○ période entre la définition et le retrait d’un produit
● qu’est-ce que la spécification d’un logiciel?
○ élaboration des besoins et exigences du client
● quelle différence avec la conception?
○ spécification = QUOI, conception = COMMENT
● importance de la spécification?
○ contrat entre le client et le développeur
29
Ressources
● Pressman R - Software Engineering: A
Practitioner's Approach - Pressman &
Associates (part 1)
● www.commentcamarche.net/contents/473-cyc
le-de-vie-d-un-logiciel
30
Introduction aux
méthodes formelles
31
Questions?
●
●
●
●
qu’est-ce qu’une méthode formelle?
qu’est-ce que la spécification formelle?
quel est l’intérêt des méthodes formelles?
qui utilise les méthodes formelles?
32
Que signifie
“méthodes formelles” ?
Selon Wing (1990), les méthodes formelles
● sont des techniques basées sur les
mathématiques pour décrire les
propriétés d’un système.
● fournissent un cadre systématique
○ pour développer le système
○ pour valider et vérifier le système
33
Spécification formelle
Holloway (1996),
“Les méthodes formelles peuvent êtres utilisées pour
spécifier et modéliser le comportement d’un système et
pour vérifier de façon mathématique que la conception
et la mise en oeuvre du système satisfont bien les
fonctionnalités ainsi que diverses propriétés de sûreté.”
34
Place des mathématiques
Les mathématiques requises pour l’écriture des
spécifications sont faciles.
Hal (1990),
“Un haut niveau de sophistication mathématique est
requis [seulement] si on désire effectuer un
développement formel complet qui inclut des preuves.”
35
Qu’est-ce qu’un langage
formel de spécification ?
C’est un langage
● à la syntaxe et à la sémantique bien
définies
○ pas de flou possible
● permettant une description abstraite du
comportement d’un système
○ concision
36
Syntaxe d’un langage
La syntaxe décrit les mots, les phrases et les
énoncés acceptables et biens formés.
Les vaches produisent du lait.
.lait vache Produise du la
37
Sémantique d’un langage
La sémantique définit le sens et la signification
des énoncés du langage.
Les vaches produisent du lait.
Les vaches demeurent des sapins.
38
Différence avec un langage
de programmation
C, Java, Python possèdent eux aussi une
syntaxe et une sémantique bien définies
Mais sont trop peu abstraits
● comportement décrit de manière
opérationnelle
● algorithme décrivant explicitement chaque
étape
39
Variété des méthodes
formelles
Beaucoup de notations et méthodes différentes
●
●
●
●
●
●
●
●
●
CSP (Hoare, 1987)
LOTOS (Bolognesi Brinksma, 1987)
Z (Spivey, 1988)
CCS (Milner, 1989)
Spec (Berzins Luqi 1990)
VDM (Jones, 1992)
ONE (Meer Roth Vuong 1992)
Larch (Guttag Horning 1993)
… on ne les verra pas toutes :)
40
Bénéfices des méthodes
formelles ?
● obtenir des spécifications claires, précises,
non-ambiguës, plus explicites
● plus concises et compactes que la langue naturelle
(mais plus difficile à comprendre)
● fournit une base précise pour le développement des
tests et des jeux d’essais
● peut s’analyser automatiquement pour effectuer une
vérification formelle
41
Quand utiliser les méthodes
formelles ?
À différentes étapes du cycle de vie
● analyse et spécification
● conception architecturale
● vérification
● implémentation: génération de code
42
Qui utilise les méthodes
formelles ?
Quelques exemples
●
●
●
●
●
NASA: Contrôle de satellites, navettes
RATP: Contrôle du métro de Paris
SNCF: Limitations de vitesse des trains
FAA: Prévention des collisions en vol
Darlington, Ontario: Extinction de
réacteurs nucléaires
43
Conclusion
Méthodes de spécification formelles
● Pour spécifier clairement et précisément
le comportement attendu d’un système
● Essentiellement pour des applications
sensibles: nucléaire, avionique, médical,
finances, électronique...
44
Réponses
● qu’est-ce qu’une méthode formelle?
○ méthode basée sur les mathématiques
● qu’est-ce que la spécification formelle?
○ spécification utilisant une méthode formelle
● quel est l’intérêt des méthodes formelles?
○ clarté, concision, jeux d’essai et automatisation
● qui utilise les méthodes formelles?
○ l’industrie de pointe, projets sensibles
45
Ressources
● Tremblay, G - Modélisation et spécification
formelle de logiciels - Loze-Dion Editeurs
Inc., 2004 (chap 1)
46