Chapitre 1' Introduction

1
Chapitre 1. Introduction

• 1.1. Rappel pourquoi les techniques formelles
• 1.2. Rappel comment ça marche
• 1.3. Mais les limites
• 1.4. Objet du cours

2
1.1. Rappel pourquoi les techniques formelles ?

• Constat
• complexité croissante des systèmes informatiques
• gt difficulté de développement
• risques de retards,
• risques de surcoûts
• gt risques de défaillances dues à des erreurs de
  conception aux 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...

3
1.1. Rappel pourquoi les techniques formelles ?

• Mais ?
• Cela suffira-t-il pour faire face à
  laccroissement 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)
• gt Les Méthodes Formelles pour démontrer qu'un
  système (un protocole, un système embarqué)
  fonctionne comme désiré !

4
1.2 Rappel comment ça marche ?
Le cahier des charges de S
S le système pour lequel on exige un
fonctionnement correct
5
1.2 Rappel comment ça marche ?
Le cahier des charges de S
explicitation et formalisation
En exigences de fonctionnement
M le modèle du système
E2 exigences de fonctionnement
E1 exigences de fonctionnement
(en UML, SDL, RdP, java, C, )
(en logique temporelle...)
production, compilation
S le système pour lequel on exige un
fonctionnement correct
6
1.2 Rappel comment ça marche ?
cahier des charges
explicitation et formalisation
En exigences de fonctionnement
M' un modèle simplifié
abstraction
M le modèle du système
E2 exigences de fonctionnement
E1 exigences de fonctionnement
(en UML, SDL, RdP, java, C, )
(en systèmes de transitions...)
(en logique temporelle...)
production, compilation
S le système pour lequel on exige un
fonctionnement correct
7
1.2 Rappel comment ça marche ?
cahier des charges
informel ou semi-formel
explicitation et formalisation
formel
En exigences de fonctionnement
M' un modèle simplifié
abstraction
M le modèle du système
E2 exigences de fonctionnement
E1 exigences de fonctionnement
(en UML, SDL, RdP, java, C, )
(en systèmes de transitions...)
(en logique temporelle...)
Outil de vérification
production, compilation
(model checker, prouveur...)
S le système pour lequel on exige un
fonctionnement correct
réponse
8
1.3. Mais... les limites

• Pour que le processus de validation soit
  pertinent, il faut
• que le cahier des charges soit réécrit en
  exigences cohérentes !
• que la théorie sous-jacente à la technique
   formelle  de vérification permette
  l'expression et la vérification d'exigences
   pertinentes 
• gt est-ce le cas des techniques formelles vues en
  2ème année ?

9
1.3. Mais... les limites

• Rappel du cours  Validation de protocoles  de
  2ème année
• M' (modèle abstrait du système) un système de
  transitions
• Exigences formules de logique temporelle
• gt on ne manipule que de signaux discrets
• gt le temps une succession chronologique de
  signaux (qualitatif)
• gt pas d'aspect chronométrique (quantitatif)

10
1.3. Mais... les limites

• gt Conséquences
• les contraintes de temps quantitatives ne peuvent
  être exprimées qu'en comptant des itérations
• les comportements temps réel quantitatifs ne
  peuvent être modélisés qu'en enchaînant des
  transitions tirées sur des tops d'horloges
• gt difficulté d'expression
• gt modélisation dépendante du pas d'horloge
  considéré
• gt précision des modèles limitée et dépendante du
  pas d'horloge considéré
• gt explosion du nombre d'états
• gt difficulté accrue pour les systèmes distribués
  asynchrones (tels que souvent les protocoles de
  communication)

11
1.3. Mais... les limites

• gt Nécessité d'un formalisme intégrant un temps
  "chronométrique", et pas uniquement
  "chronologique"
• Idée étendre les formalismes  discrets  avec
  le temps  continu  (dans R)
• SDL avec les timers (vu en 2TR)
• Réseaux de Petri temporisés
• Lotos temporisé
• les automates temporisés (i.e., des systèmes de
  transitions temporisés)

12
1.3. Mais... les limites

• gt Idée un temps continu
• le temps est modélisé par des valeurs réelles
  positives
• le délai entre deux événements peut-être un
  nombre réel arbitraire
• gt invariance du modèle par rapport à l'échelle
  de temps
• gt plus proche du temps réel
• gt mieux adéquat aux systèmes asynchrones
• Mais tout cela a un coût !
• espace d'états infini
• gt obligation de représenter symboliquement cet
  espace d'états pour pouvoir le manipuler (et
  vérifier des exigences)
• gt algorithme de vérification plus complexe

13
1.4 Objet du cours

• Objet du cours
• exposer une technique de modélisation de systèmes
  temps réel sans faire référence à des tops
  d'horloge discrets
• exposer une technique de vérification dexigences
  temporelles quantitatives
• gt Le formalisme les automates temporisés
• gt La technique de vérification model checking
  symbolique
• gt des outils UPPAAL (Aalborg)
• gt prise en compte d'un temps dense (dans R)