Introduction aux Méthodes Formelles
Introduction aux Méthodes Formelles
Pascal ANDRE
MIAGE
Université de Nantes
Master Miage M1
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
Rappel du contexte
Le contexte
1. Génie logiciel
2. Le développement du logiciel
3. Méthode de développement du logiciel
I Modèles, produits
I Processus
I Validation, vérification
4. Qualité
Rappel du contexte
I De l’idée au code
I exprimer
I programmer → MODELES
I vérifier
I avec méthode.
I dans le bon ordre PROCESSUS
I éviter l’anarchie → GESTION DE PROJET
I travailler en groupe
I et qualité
I modèles (correct, fiable, évolutif...)
I processus (efficace, rentable...) → QUALITE
Quelques références
I Développement du logiciel et CSI [AV01a, GMSB96]
I Systèmes formels [Lau86, WL88]
I Z [Spi94, WL88], B [Abr96]
I Méthodes formelles et Z
[Mey92, BH96, Bow96, Jac97, AV01b, AV04]
I LOTOS, SDL [Tur93], CSP [Hoa85] ou CCS [Mil89]
I Spécifications algériques [Wir90]
I Automates [Arn92], les réseaux de PETRI [Bra83])
Jean-Raymond Abrial.
Spécifier ou comment matérialiser l’abstrait.
Technique et Science Informatique, 3(3):201–219, 1984.
Jean-Raymond Abrial.
The B-Book Assigning Programs to Meanings.
Cambridge University Press, 1996.
ISBN 0-521-49619-5.
André Arnold.
Systèmes de transitions finis et sémantique des processus communiquants.
Collection Etudes et recherches en informatique. Masson, 1992.
ISBN 2-225-82746-X.
Pascal André and Alain Vailly.
Conception de systèmes d’information ; Panorama des méthodes et des techniques,
volume 1 of Collection Technosup.
Editions Ellipses, 2001.
ISBN 2-7298-0479-X.
Pascal André and Alain Vailly.
Spécification des logiciels ; Deux exemples de pratiques récentes : Z et UML,
volume 2 of Collection Technosup.
Editions Ellipses, 2001.
Méthodes formelles MIAGE
Introduction Motivations Un exemple introductif Les systèmes formels Processus Classification Exemples
ISBN 2-7298-0774-8.
Pascal André and Alain Vailly.
Exercices corrigés en langage Z ; Les spécifications formelles par la pratique,
volume 4 of Collection Technosup.
Editions Ellipses, 2004.
ISBN 2-7298-1942-8.
Jonathan P. Bowen and Michael G. Hinchey, editors.
Applications of Formal Methods.
International Series in Computer Science. Prentice-Hall, 1 edition, 1996.
ISBN 0-13-832544-8.
Jonathan Bowen.
Formal Specification & Documentation using Z: A Case Study Approach.
International Thomson Publishing, 1996.
ISBN 1-85032-230-9.
G. W. Brams.
Réseaux de Petri : théorie et pratique.
Editions Masson, Paris, 1983.
Marie-Claude Gaudel, Bruno Marre, Françoise Schlienger, and Gilles Bernot.
Précis de génie logiciel.
Enseignement. Masson, 1996.
Méthodes formelles MIAGE
Introduction Motivations Un exemple introductif Les systèmes formels Processus Classification Exemples
ISBN 2-225-85189-1.
Charles Antony Richard Hoare.
Communicating Sequential Processes.
International Series in Computer Science. Prentice-Hall, 1985.
ISBN 0-13-153289-8.
Jonathan Jacky.
The Way of Z: Practical Programming with Formal Methods.
Cambridge University Press, 1997.
ISBN 0-521-55041-6.
Cliff B Jones.
VDM, une méthode rigoureuse pour le développement du logiciel.
Masson, Paris, 2e edition, 1993.
Jean.-Louis Laurière.
Résolution de problèmes par l’Homme et la machine.
Eyrolles, 1986.
Bertrand Meyer.
Introduction to the Theory of Programming Languages.
International Series in Computer Science. Prentice Hall, 1992.
ISBN 0-13-498502-8.
Robin Milner.
Communication and Concurrency.
International Series in Computer Science. Prentice-Hall, 1989.
ISBN 0-13-115007-3.
Mike Spivey.
La notation Z.
Collection Méthodologies du logiciel. Editions Masson, 1994.
Traduit de l’anglais par Michel Lemoine, ISBN 2-225-84367-8.
Kenneth J. Turner, editor.
Using Formal Description Techniques, An introduction to Estelle, Lotos and
SDL.
Wiley, 1993.
ISBN 0-471-93455-0.
Jeannette M. Wing.
A specifier’s introduction to formal methods.
IEEE Computer, 23(9):8–24, 1990.
Martin Wirsing.
Algebraic Specification, volume B of
Handbook of Theoretical Computer Science, chapter 13, pages 675–788.
Elsevier, 1990.
Méthodes formelles MIAGE
Introduction Motivations Un exemple introductif Les systèmes formels Processus Classification Exemples
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
Chiffres et besoins
Chiffres et besoins
Bugs et qualité
Chiffres et besoins
Bugs et qualité
I bug = dysfonctionnement logiciel
I problème : tous niveaux
I processeur, ex: bug virgule flottante des processeurs Pentium
I codage, ex : bug an 2000 (années codées sur deux chiffres),
2038 (langage C codé sur 32 bits)
I logiciel, ex : crash Ariane
I faille sécurité, ex : CB
I Un bug peut être :
I soit un non-respect de la spécification du système (c’est-à-dire
de la définition de ce que le système est censé faire),
I soit un comportement inattendu non couvert par la
spécification (par exemple, cas non prévu de deux actions
contradictoires à traiter simultanément, cas du bug de l’an
2000).
Chiffres et besoins
Bugs et qualité
I bug = dysfonctionnement logiciel
I problème : tous niveaux
I processeur, ex: bug virgule flottante des processeurs Pentium
I codage, ex : bug an 2000 (années codées sur deux chiffres),
2038 (langage C codé sur 32 bits)
I logiciel, ex : crash Ariane
I faille sécurité, ex : CB
I Solutions
I Les règles de programmation.
I Les techniques de programmation.
I Les méthodologies de développement.
I Le support des langages de programmation.
I Le test.
I Les méthodes formelles.
Chiffres et besoins
Bugs et qualité
I bug = dysfonctionnement logiciel
I problème : tous niveaux
I processeur, ex: bug virgule flottante des processeurs Pentium
I codage, ex : bug an 2000 (années codées sur deux chiffres),
2038 (langage C codé sur 32 bits)
I logiciel, ex : crash Ariane
I faille sécurité, ex : CB
I Solutions
I Méthodes formelles sont une solution parmi d’autres :
notation/modèle formel + sémantique bien définie + outillage
Chiffres et besoins
Chiffres et besoins
I Codification :
I Preuves de programmes
I Synthèse automatique du code
I Utilisation d’assertions
I Tests
I Génération automatique des tests
Source: G. Tremblay
Méthodes formelles MIAGE
Introduction Motivations Un exemple introductif Les systèmes formels Processus Classification Exemples
Applications et limites
Bénéfices
Source: G. Tremblay
Applications et limites
Applications
(quelques) succès et industriels concernés :
I Orly Val, Métro ligne 14 [méthode B]
I U. Oxford et IBM CICS [Z] / qualité + réduction des coût 9%
I NASA, Airbus, IBM, Microsoft, FT R&D, ...
Exemples ayant utilisé des méthodes classiques :
I Réingénierie du système CICS (IBM).
I Composants matériels (Inmos).
I Appareilsélectroniques (Tektronik).
I Outils pour l’analyse structurée.
I Contrôle du métro (Paris).
I Contrôle de trains (SNCF).
I Contrôle du trafic aérien (UK et USA).
I Contrôle de réacteurs nucléaires (Ontario, USA).
I Navette spatiale de la NASA (contrôleur de vol, GPS).
I Contrôle pour machine de radiothérapie.
Applications et limites
Application 2/2
Exemples ayant utilisé la vérification de modèles :
I
Source: G. Tremblay
Applications et limites
Intérêts
Applications et limites
Intérêts
Applications et limites
Intérêts
I aux aspects formels :
I à la précision :
I à l’abstraction (”quoi pas comment”),
I Une abstraction permet de ne retenir que les caractéristiques
essentielles,
I Une description abstraite est plus évolutive et perméable aux
changements des besoins, elle améliore la maintenabilité du logiciel
son accès.
I L’abstraction permet une distinction plus nette entre étude et
réalisation, pour lesquelles les choix et les décisions sont différents.
Une approche multi-language facilite la distinction.
I Les méthodes formelles mènent à des composants plus faciles à
réutiliser et plus fiables. On se rapproche en ce sens des techniques
d’autres “génies” (civil, mécanique, électrique).
Applications et limites
Inconvénients
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support : peu de méthodes
présentent un processus clair et réaliste, un environnement complet et
convivial fait défaut même si des prototypes existent. Les preuves sont
souvent données de façon anecdotique dans les ouvrages. Le formalisme
doit permettre autant que possible d’automatiser la preuve.
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support :
I difficultés de modélisation : manque de structuration, erreurs,
exceptions, concurrence. On a besoin d’outils et de méthodes pour
construire les spécifications complexes. La modélisation passe aussi par la
capitalisation du savoir (modèles, méthodes utilisées).
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support :
I difficultés de modélisation :
I adéquation : la spécification formelle aide à cerner les oublis et les
contradictions, mais on ne peut prouver que ce qui a été spécifié, pas ce
qui était (implicitement) souhaité par le client.
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support :
I difficultés de modélisation :
I adéquation :
I preuve : des outils de preuve existent (calcul de schémas en Z,
réécriture dans les algèbres), mais ils sont insuffisants. Des études sont en
cours pour les enrichir et donner les algorithmes de test et de preuve.
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support :
I difficultés de modélisation :
I adéquation :
I preuve :
I domaine d’application : actuellement, les spécifications formelles ne
sont appliquées qu’à un nombre réduit d’applications : “Nous avons
présenté dans ce texte une certaine manière d’aborder une petite classe de
problèmes informatiques, ...” [Abr84]. “Certains éléments des langages
de programmation (le parallélisme, l’arithmétique en virgule flottante, les
structures de données complexes) sont encore difficiles à modéliser de
manière satisfaisante.” [Mey92]. Le lecteur trouvera dans [BH96] un
certain nombre d’application “réaliste” de méthodes formelles.
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support :
I difficultés de modélisation :
I adéquation :
I preuve :
I domaine d’application :
I raffinage : la théorie du raffinage ou réification est relativement simple
à comprendre : on transforme petit à petit les structures de données et de
contrôle jusqu’à atteindre les langages de programmation. Il faut noter
que le nombre d’étapes de raffinage peut être important et que la preuve
du bien-fondé de la transformation est souvent très lourde. “Une relation
bien fondée ne contient pas de cycle” [Jon93].
Applications et limites
Inconvénients
I difficulté :
I diversité :
I pauvreté des processus et des outils support :
I difficultés de modélisation :
I adéquation :
I preuve :
I domaine d’application :
I raffinage :
I structuration : on a besoin d’outils de structuration des spécifications
pour en simplifier l’écriture, l’accès la preuve et la réutilisation. Certains
outils existent (dérivation de shéma en Z, sous-typage et relation
d’importation dans les spécifications algébriques) mais ne sont pas
toujours suffisants.
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
Exemple introductif
1. Description informelle
2. Modélisation avec Merise
I MCD
I MCT
I Critique
3. Modélisation avec Z
I Données
I Traitements
I Critique
4. Bilan
Description informelle
L’administration veut gérer automatiquement les salles d’attente à
l’hôpital. Chaque salle a une capacité d’accueil limitée. Elles
portent un nom et sont situées à un emplacement précis de
l’hôpital. Les patients sont admis normalement ou en urgence. Les
patients admis en urgence sont appelés prioritairement vis-à-vis des
patients en admission normale. L’ordre d’appel est l’ordre d’arrivée,
compte-tenu des éventuelles urgences. Un patient appelé est reçu
et soigné par le docteur. Les soins ne sont pas interrompus par
l’arrivée d’un patient en urgence. On considère trois cas :
1. une seule salle d’attente et pas d’urgences,
2. une seule salle d’attente et traitement des urgences,
3. plusieurs salles d’attente et traitement des urgences.
attente normale
num_ordre_na
Patient SalleAttente
0,1
no_SecSoc_p 0,n no_s
nom_p X T nom_s
prénom_p 0,n localisation_s
adresse_p 0,1 nb_places_s
urgence
num_ordre_u
Admission
Patient
Admission Admission refusée
créé
normale urgente
(a) (b)
b prioritaire sur a
Soin
soins prodigués au patient
Patient
guéri
+ explications
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
I contraintes entre associations
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
I contraintes entre associations
I contraintes informelles
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
I contraintes entre associations
I contraintes informelles
- Manque de sémantique formelle
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
I contraintes entre associations
I contraintes informelles
- Manque de sémantique formelle
I Comment vérifier ?
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
I contraintes entre associations
I contraintes informelles
- Manque de sémantique formelle
I Comment vérifier ?
I Comment prouver la correction ?
Critique (MCD)
+ Plus concis et moins soumis à interprétation que la description
informelle.
+ MCD presque complet (cardinalités, contraintes).
Mais ...
- Manque de précision
I règles de gestion
I contraintes entre associations
I contraintes informelles
- Manque de sémantique formelle
I Comment vérifier ?
I Comment prouver la correction ?
I Pas d’oublis ?
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Critique (MCT)
Exemple introductif
1. Description informelle
2. Modélisation avec Merise
I MCD
I MCT
I Critique
3. Modélisation avec Z
I Données
I Traitements
I Critique
4. Bilan
Modélisation avec Z
[PATIENT ]
MAX =
b 20
SalleAttenteH ôpital
patients : seq PATIENT
#patients ≤ MAX
∀i, j : 1 . . #patients | i 6= j • patients(i) 6= patients(j)
Modélisation avec Z
Sortie
∆SalleAttenteH ôpital
p! : PATIENT
patients = hp!i _ patients 0
patients 6= hi
Méthodes formelles MIAGE
Introduction Motivations Un exemple introductif Les systèmes formels Processus Classification Exemples
Modélisation avec Z
pre Arriv é =
b
∃SalleAttenteH ôpital 0 • Arriv ée
Modélisation avec Z
EnAttente
ΞSalleAttenteH ôpital
n! :IN
n! = #patients
Modélisation avec Z
Sorties
∆SalleAttenteH ôpital
p! : PATIENT
n? :IN 1
n? ≤ #patients
∃sa1 : seq PATIENT | #sa1 = n? − 1 •
patients = sa1 _ hp!i _ patients 0
Modélisation avec Z
Prouver des
I propriétés générales e.g.cohérence et complétude, équité, la
vivacité . . .
Modélisation avec Z
Prouver des
I propriétés générales e.g.cohérence et complétude, équité, la
vivacité . . .
I propriétés attendues du système.
Modélisation avec Z
Prouver des
I propriétés générales e.g.cohérence et complétude, équité, la
vivacité . . .
I propriétés attendues du système.
I propriétés liées à la pratique de Z (ou VDM) (obligations de
preuves)
Modélisation avec Z
Prouver des
I propriétés générales e.g.cohérence et complétude, équité, la
vivacité . . .
I propriétés attendues du système.
I propriétés liées à la pratique de Z (ou VDM) (obligations de
preuves)
I Existence d’un état initial.
Modélisation avec Z
Prouver des
I propriétés générales e.g.cohérence et complétude, équité, la
vivacité . . .
I propriétés attendues du système.
I propriétés liées à la pratique de Z (ou VDM) (obligations de
preuves)
I Existence d’un état initial.
I Préservation des invariants dans les opérations.
Modélisation avec Z
Prouver des
I propriétés générales e.g.cohérence et complétude, équité, la
vivacité . . .
I propriétés attendues du système.
I propriétés liées à la pratique de Z (ou VDM) (obligations de
preuves)
I Existence d’un état initial.
I Préservation des invariants dans les opérations.
I Preuve de raffinement de données ou d’opérations.
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
Modélisation avec Z
De la spécification au code...
Deux types de raffinement sont distingués en Z :
I Le raffinement des opérations. Les structures de contrôle du
langage de programmation cible sont introduites
progressivement e.g.séquence, conditionnelles, itérations pour
la programmation impérative.
I Le raffinement des données. Les structures de données du
langage de programmation cible sont introduites
progressivement e.g.structures, tableaux, pointeurs pour la
programmation impérative.
Modélisation avec Z
SalleConcret
file : seq PATIENT
premier :IN
#file ≤ MAX ∧ premier ≤ MAX
∀i, j : 1 . . premier | i 6= j • file(i) 6= file(j)
InitSalleConcret
SalleConcret
premier = 0
Modélisation avec Z
Arriv éeC
∆SalleConcret
p? : PATIENT
premier < MAX ∧ ∀i : 1 . . premier • file(i) 6= p? ∧
premier 0 = premier + 1 ∧ file 0 = hp?i _ front file
Modélisation avec Z
SortieC
∆SalleConcret
p! : PATIENT
premier > 0
premier 0 = premier − 1
pre SortieC
SalleConcret
p! : PATIENT
premier > 0
Modélisation avec Z
SortiesC
∆SalleConcret
p! : PATIENT
n? :IN 1
n? ≤ premier ∧ p! = file(n?) ∧
premier 0 = premier − n? ∧ file 0 = file
Modélisation avec Z
Abs
SalleAttenteH ôpital
SalleConcret
patients = rev ((1 . . premier ) / file)
Preuves du raffinement
I de l’état initial
I des opérations
Modélisation avec Z
Exemple introductif
1. Description informelle
2. Modélisation avec Merise
I MCD
I MCT
I Critique
3. Modélisation avec Z
I Données
I Traitements
I Critique
4. Bilan
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
⇒ Réduction des erreurs tardives, réutilisabilité en confiance
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
⇒ Réduction des erreurs tardives, réutilisabilité en confiance
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
⇒ Réduction des erreurs tardives, réutilisabilité en confiance
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
⇒ Réduction des erreurs tardives, réutilisabilité en confiance
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
⇒ Réduction des erreurs tardives, réutilisabilité en confiance
Modélisation avec Z
Bilan
Les ”spec formelles”
+ Formalisme (théories, logiques et calculs)
+ Rigueur (types, contraintes, invariants, traitements)
+ Abstraction (vis à vis des langages de programmation)
⇒ Réduction des erreurs tardives, réutilisabilité en confiance
Modélisation avec Z
Usage
Modélisation avec Z
Usage
Modélisation avec Z
Usage
Modélisation avec Z
Usage
Modélisation avec Z
Usage
Modélisation avec Z
Usage
Modélisation avec Z
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
Système formel =
I langage formel
Système formel =
I langage formel
I alphabet
I syntaxe → META-LANGAGE
Système formel =
I langage formel
I alphabet
I syntaxe → META-LANGAGE
Système formel =
I langage formel
I système formel
I axiomes
I règles d’inférence
règles de déduction (→ méta-langage d’inférence))
Système formel =
I langage formel
I système formel
I axiomes
I règles d’inférence
règles de déduction (→ méta-langage d’inférence))
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
MIAGE
Spécification
informelle
Classification
Elaboration Elaboration
du MCD du MCT
Processus
Validation
Traduction croisée
en Z
Spécification
Spécification de
l'état du système
Un exemple introductif
La spécification formelle
Spécification
des opérations
en Z
vérification
preuves et
Implantation
raffinement Implantation
Motivations
Méthodes formelles
Application
Tests
(ex: Pascal,
Vérifications
Caml, SGBDR)
Introduction
Introduction Motivations Un exemple introductif Les systèmes formels Processus Classification Exemples
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
Critères possibles :
I type de raisonnement
Critères possibles :
I type de raisonnement
I aspect du système :
I statique : Z, B, VDM, AMN...
I dynamique : automates, réseaux de Petri, SDL, CSP, CCS,
TLA, π-calcul ...
I fonctionnel : spécifications algébriques, λ-calcul
Pour chaque cas, il existe des approches hybrides (LOTOS, COLD,
RSL...)
Critères possibles :
I type de raisonnement
I aspect du système
I langage :
I général : Z, B, VDM, spécifications algébriques, CLU...
I dédié : automates, réseaux de Petri, TLA, SDL, CSP, CCS,
π-calcul, λ-calcul...
Pour chaque cas, il existe des approches hybrides (LOTOS, COLD,
RSL...)
Critères possibles :
I type de raisonnement
I aspect du système
I langage
Plan
Introduction
Motivations
Un exemple introductif
La spécification formelle
Exemples
Exemples
1. Z
2. Spécification algébrique
3. Spécification algorithmique
4. B
5. LOTOS
ex.intro.pdf