INF3143

Modélisation et spécification
formelles des logiciels

Hiver 2018

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
● Mardi, de 09h30 à 12h30 (SH-3580)
● Mardi, de 18h00 à 21h00 (PK-2205)

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
● dates à déterminer

Examen Intra (35 %) - le samedi 03 mars

TP 2 (15 %) par groupe de 2 personnes
● Contrats et vérification
● dates à déterminer

Examen Final (35 %) - le samedi 28 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
● terrasa.alexandre@uqam.ca

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:
15
http://www.commentcamarche.net/contents/473-cycle-de-vie-d-un-logiciel
Modèle en V

Illustration:
16
http://www.commentcamarche.net/contents/473-cycle-de-vie-d-un-logiciel
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
28
de la solution.
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