Les modèles formels pour le temps réel

Afin de présenter les modèles formels adaptés au traitement temporel, nous avons privilégié une taxonomie basée sur deux critères : le premier est lié aux techniques d’analyse offertes, le second aux paradigmes de modélisation. Par conséquent, un rappel sur les techniques d’analyse est d’abord effectué, puis la taxonomie est donnée. Enfin, notre choix pour un modèle formel conclut ce chapitre.

I.2.5.1. Rappels sur les techniques d’analyses formelles

Il existe essentiellement deux types de techniques d’analyse formelle : celles fondées sur la démonstration de théorèmes (theorem­proving) et celles basées sur les évaluations de modèles

(model­checking). Elles ont été étudiées intensivement dans la littérature et de nombreux

algorithmes et outils ont été développés (voir par exemple [L'Her-1997]). Les démonstrations de théorème

Avec les démonstrations de théorèmes, le modèle du système et les propriétés désirées sont exprimés comme des formules d'une logique [Clarke-1996a]. A partir de l'ensemble des formules représentant le système, les propriétés doivent être retrouvées par des mécanismes de déduction et de substitution. Aux différentes étapes de cette preuve, les formules représentant le système sont réécrites en respectant un ensemble de règles jusqu'à l'obtention de la propriété.

Cette technique est puissante : elle permet de prouver des propriétés sur des systèmes de toute taille (à la limite infinie). Cependant, si elle permet de montrer qu'un système est correct, elle n'indique pas clairement les erreurs lorsqu'elles existent. C'est donc une méthode utilisée généralement en dernière phase de vérification.

Le plus gros problème pour son utilisation est qu’elle n'est pas automatisable (et ne le sera jamais11). C'est pourquoi la technique entièrement automatisée des évaluations de modèles est généralement préférée [Clarke-1996b].

11 Le mathématicien Gödel a démontré qu’il est impossible de trouver un ensemble de règles de déductions et

30 I.2 Problèmes abordés et choix de l’axe de recherche

Les évaluations de modèles (model-checking)

Avec les évaluations de modèles, le système à vérifier est d'abord décrit dans un langage parallèle de haut niveau. Ensuite, cette description est traduite vers un modèle sous-jacent qui est généralement un système de transitions étiquetées. Ce graphe (ou automate) contient, éventuellement avec certaines abstractions, tous les comportements possibles du programme. Finalement, les propriétés de bon fonctionnement de l'application, exprimées dans un formalisme approprié (automates, logiques temporelles...) sont vérifiées sur le système de transitions étiquetées à l'aide d'outils appelés évaluateurs (model­checkers).

La technique de model­checking est automatique. Elle fournit des informations utiles même si le

système n'est pas complètement spécifié. Elle donne un contre-exemple lorsqu'une propriété n'est pas vérifiée. Elle s'avère particulièrement utile dans les premières phases du processus de développement, quand les erreurs sont encore nombreuses.

Toutefois le model­checking est confronté à l'explosion du nombre d'états modélisant le système,

car les algorithmes sont de l'ordre de la taille des systèmes. Les techniques de model­checking sont

donc souvent restreintes à des systèmes ayant un nombre fini d'états.

I.2.5.2. Taxonomie des modèles formels

I.2.5.2.a) Par rapport aux techniques d'analyse Trois grands groupes peuvent se dégager12 [Bucci-1995] :

• Les modèles déclaratifs, qui se fondent sur les notations mathématiques (axiomes, clauses,…) et qui donnent une vue abstraite de l'espace d'état à l'aide d'équations logiques et algébriques. Le système est décrit en spécifiant ses propriétés globales. Ce type d'approche privilégie l'analyse formelle de type démonstration de théorème. Dans cette approche se retrouvent : les logiques temporelles (RTL [Jahanian-1986], TLA [Lamport-1994], TRIO+ [Mandrioli-1992],…), les langages déclaratifs à flots de données comme LUSTRE [Halbwachs-1991] ou SIGNAL [Benveniste-1990], les méthodes algébriques de type VDM [Jones-1993], VDM++[Dürr-1995], Z [Spivey-1989]…

• Les modèles opérationnels (ou impératifs), qui se définissent en terme d'états et de transitions. Ils sont, par conséquent, intrinsèquement exécutables. La simulation est généralement possible et des analyses formelles (par model-checking) sont généralement proposées. Dans cette famille se retrouvent : les formalismes comme les RdP [Petri-1962], SDL [Union-1992], les modèles basés sur CCS de Milner [Milner-1980] et sur CSP de Hoare [Hoare-1978] comme les algèbres de processus telles que LOTOS [Eijk-1989] ou RT-LOTOS, les automates temporisés, les dérivés formels (comme Modecharts [Jahanian-1988]) des Statecharts [Harel-1987], les langages impératifs de type ESTEREL [Berry-1992]….

• Les modèles duaux, qui essaient d'intégrer à la fois les caractéristiques des modèles opérationnels et déclaratifs en les faisant cohabiter. ESM/RTTL [Ostroff-1987], qui couple des machines étendues à la logique temporelle d'intervalles, est représentative de ce type d'approche.

I.2.5.2.b) Par rapport aux paradigmes de modélisation

Afin de simplifier les tâches de vérification et de validation du système, diverses hypothèses simplificatrices de modélisation, concernant essentiellement les CT, peuvent être émises. Suivant le respect de ces hypothèses de modélisation, trois paradigmes de synchronisation peuvent être distingués [Carcagno-1995] :

• Paradigme synchrone fort : Dans cette approche, les actions et les communications sont considérées comme immédiates et de dynamiques négligeables par rapport à la dynamique du

12 Précisons que cette classification n'en est qu'une parmi un grand nombre (cf. par exemple [Hoare-1987],

I.2 Problèmes abordés et choix de l’axe de recherche 31

procédé. Le temps manipulé est défini par rapport aux arrivées successives des événements. C'est une vision multiforme du temps, car il y a autant de temps que d'événements externes indépendants. Le système évolue par l'arrivée d'événements. La phase de transition (ou transitoire) entre deux états est considérée comme immédiate. Par ailleurs, on suppose une communication synchrone par diffusion large (broadcasting) : toutes les communications sont diffusées à tous les composants. Le système est donc un système réflexe (les réactions sont supposées instantanées).

• Paradigme synchrone faible : Cette approche, par rapport au synchrone fort, permet de mieux maîtriser les temps de communication et d'exécution. Ceux-ci ne sont plus supposés nuls, mais sont uniformisés et fixés arbitrairement à une même constante. Le comportement du système peut donc se synthétiser par une suite temporelle d'instants équidistants, le système réagissant aux changements survenus depuis le dernier instant. Pour fonctionner, un tel système doit être cadencé par une horloge globale (ou un ensemble d'horloges locales synchronisées). Le temps de réaction correspond alors à une unité de temps de cette horloge. Une communication par broadcasting est là aussi supposée. Le système n'est plus réflexe mais périodique.

• Paradigme asynchrone : Avec ce paradigme, la durée des actions et les temps de communication sont considérés comme bornés (mais peuvent varier dans des intervalles). Les délais de transitions du système ne sont pas supposés constants (une transition pouvant prendre un nombre variable de cycles de calcul). Lorsque des synchronisations sont nécessaires entre nœuds, elles sont faites de manière explicite par des communications. La communication par diffusion n’est plus supposée par défaut.

Ainsi, dans les approches synchrones, nous retrouvons les logiques temporelles, les langages de type SIGNAL, ESTEREL, LUSTRE, les dérivés de Statecharts…

Avec le paradigme asynchrone, nous retrouvons les algèbres de processus (CSP, SDL), les langages déclaratifs de type ELECTRE [Cassez-1995] ou les RdP.

Notons que, dans un contexte de système distribué, il peut y avoir une utilisation de modèles synchrones, pour la description du comportement des nœuds et, de modèles asynchrones pour la description des communications entre les nœuds (voir par exemple [Carcagno-1995]).

I.2.5.3. Notre choix : les Réseaux de Petri

Concernant les techniques d'analyse, nous préférons les modèles opérationnels pour plusieurs raisons :

• Ils permettent d'obtenir rapidement des modèles exécutables ; ils offrent donc des possibilités de simulation, de vérification et d'évaluation des performances très tôt dans le cycle de développement.

• Les techniques d'analyses (par model-checking) sont automatisées.

• Les STR étant déjà complexes par nature, nous voulons limiter l'utilisation de familles de modèles différentes, afin de ne pas y ajouter une complexité d'étude.

Une grande partie de notre problématique touchant le traitement du temps, nous préfèrerions utiliser des modèles formels ne faisant pas d’hypothèse simplificatrice et donc suivant un paradigme de modélisation asynchrone.

Cet ensemble de critères permet de restreindre notre choix des modèles formels à la famille des algèbres de processus, à des langages déclaratifs asynchrones ou à des RdP.

Parmi ces modèles formels asynchrones, nous avons choisi les RdP car :

• Ils disposent de nombreux outils d'aide, de vérification et de validation.

• Leur spectre d'utilisation est très large sur le cycle de vie.

32 I.2 Problèmes abordés et choix de l’axe de recherche

et de parallélisme.

• Leur utilisation et les nombreux travaux existants dans différents domaines13 sont garants de la qualité du formalisme et de son adaptation à la grande majorité des problèmes des STR.

• Tous les modèles formels adaptés à l'expression du comportement dynamique reposent (directement ou indirectement) sur une description états/transitions du système. Or, les RdP sont l'un des formalismes états/transitions possédant des mécanismes puissants d'abstraction et de description.

• Un grand nombre de modèles de RdP manipulant le temps de manière explicite a été défini. De ce fait nous avons la garantie de disposer d’un modèle ayant une sémantique riche concernant l’expression des contraintes temporelles.

• Enfin, notre équipe de recherche dispose d’une longue expérience et de travaux antérieurs sur ce formalisme.

Néanmoins, ainsi qu’il a été annoncé en §I.2.1.3, l’utilisation conjointe d’un modèle formel avec la notation UML soulève de nombreuses interrogations. Celles-ci sont maintenant détaillées.