Processus de Modélisation dans VALID .1 Architecture de VALID

Le système VALID est un système ouvert qui épouse différents concepts de modélisation et repose sur un processus de modélisation cyclique dit de Gourgant (Figure 9.3). Le cycle dans ce cas est incrémental et itératif, chaque étape étant susceptible d’alimenter les autres. Il est arrêté que lorsque le fonctionnement du système est jugé conforme aux désirs du concepteur.

L’environnement VALID est formé de deux grandes parties aussi importantes l’une que l’autre à savoir :

• Le modèle de connaissance (ou de fonctionnement), contient les spécifications de topologie et de fonctionnement attendu du système. Ce modèle étant la représentation de la partie statique du système, ensuite la partie dynamique sera spécifiée formellement par des règles de réécriture telles que définies auparavant. La description de cette partie est assurée par une interface graphique très conviviale et simple à la fois.

• Le modèle d’action : c’est la traduction du modèle de connaissance, d’abord en un système de réécriture concurrente pour prouver que la spécification du système satisfait les propriétés de confluence, de terminaison. Ensuite une série de transformations formelles de spécifications et dont l’étape finale est l’obtention du code en Prolog qui assurera par la même occasion le comportement du système par l’intermédiaire de l’exécution des règles de réécriture générées par PROLOG lui-même.

Figure 9.3 : Processus de modélisation

La figure suivante (Figure 9.4) définie au mieux l’architecture de VALID quelque peut amélorée dans le cadre de nos travaux. Comme extension apportée à VALID, plusieurs détails furtifs sont consignés dans les articles [RBJ+03a, RBJ+03a, RJ04a, RJ04b].

144

Figure 9.4 : Architecture de VALID

9.2.2.2 Méthodologie de spécification des systèmes concurrents avec VALID La méthode VALID utilise deux phases de spécification distinctes reliées entre elles.

L’éditeur graphique étant la pièce maîtresse et sert de support. Pendant une session de spécification d’un système, il permet d’instancier et de spécialiser les modèles pour chaque objet du système global. La spécialisation consiste essentiellement à préciser le type réel des méta-types : Objet, Valeur, ObjetId, … Pour les méta-types qui ne peuvent pas être spécialisés automatiquement, soit par manque d’information, soit en raison d’ambiguïtés de description, une interaction avec l’utilisateur est ainsi requise pour plus de clarté.

Le système VALID procède selon les phases suivantes :

9.2.2.2.1 Phase de mise en place de l’architecture et de l’interface

La première phase consiste à mettre en place les objets du système en procédant par niveau d’abstraction. Dans cette phase il est important de respecter la hiérarchie naturelle des objets du système modélisé. A un niveau donné, seuls les objets visibles sont mis en évidence.

Dans VALID, un système complexe sera représenté par les éléments suivants : • Des variables d’état,

• Des flots de données et de contrôle en entrée (vecteur d’entrée) • Des flots de données et de contrôle en sortie (vecteur de sortie),

• Des règles et des lois de génération des flots en sortie à partir des flots en entrée (règle de transformation)

145

• Une dynamique du système, exprimée facilement à l’aide des règles que nous avons introduites précédemment,

• Des attributs visibles des sous-systèmes composites nécessaires pour sa partie dynamique Cette représentation est récursive et s’applique aussi aux sous-systèmes.

Un objet complexe est considéré comme un système qui est susceptible d’être décomposé en une suite de sous-systèmes. Cette décomposition est guidée en privilégiant les relations de composition qui existent au sein même du système. A ce niveau de spécification des éléments tels que les relations de spécialisation / généralisation, de référence etc., peuvent être prises en charge par le système VALID. Ce qui revient d’une façon globale à découper les spécifications en modules de spécialisation qui s’emboîtent les uns aux autres.

Le système VALID procède selon les étapes suivantes :

• Création du système principal. Dans le cas de l’éditeur VALID le système principal est toujours de niveau 0 et ne peut contenir qu’un seul sous-système

• Création de l’architecture.

1. Création des systèmes et sous-systèmes.

2. Création des attributs pour les systèmes spécifiés. • Création de l’interface.

1. Création des messages.

2. Description des attributs visibles.

3. Phase de vérification de l’architecture et de l’interface : Cette vérification est importante, car avant d’entamer la description des règles il est impératif que l’architecture soit complète et cohérente. Cette phase évitera plus tard de nombreuses étapes de modifications des règles dues à la mise à jour de l’architecture.

• Description du comportement de chaque système.

La visualisation du système à spécifier se présente sous sa forme réduite selon la figure 9.5. Cette façon de représenter tous les sous-systèmes sur une même fenêtre se fait justement dans cette forme (réduite) qui laisse apparaître que l’interface (messages en entrée et en sortie du système et les attributs visible). A ce stade de spécification, nous omettons la description du contenu.

Remarque : Pour le moment nous mettons de côté tous les éléments techniques de création, de modification, de suppression d’un système ou d’un de ces sous-systèmes. Nous ferrons de même pour l’écriture de toutes les appellations (descriptions). Par contre un système développé c’est la représentation graphique de tous les sous-systèmes (sous leur forme réduite) et attributs qui le composent.

146

L’objet Attribut

L’attribut représente un objet qui ne peut être décomposé hiérarchiquement. Il devient un composant à part entière du système et est décrit par les caractéristiques suivantes :

• Un nom qui l’identifie de manière unique dans le système considéré. • Une description qui représente sa documentation.

• Le Type de l’attribut qui représente l’ensemble des valeurs que peut prendre cet attribut.

• Une case de sélection de visibilité. Si elle est cochée la portée n’est pas seulement locale mais aussi exploitable par le système père de celui qui contient cet attribut.

Pour mieux comprendre la notion d’attribut, il peut être assimilé à une variable locale à un système mais qui peut être modifiable par un système père (ou hiérarchiquement supérieur) en cas de sélection de visibilité.

Les messages

Les messages qui sont pris en charge par VALID sont similaires à ceux de MAUDE (figure 9.6). La boîte de dialogue relative à la description d'un message s'affiche et il ne reste plus qu'à renseigner les différents champs. Après validation des informations, le message apparaît dans la liste concernée par cette création.

Figure 9.6 : Boite de dialogue de description d’un message.

La réduction dans VALID est un moteur d’ordre 0⁺. Il utilise la stratégie du parcours en profondeur d’abord (DFS). Il gère également un échéancier pour la réalisation des contraintes temporelles. Pour créer un scénario de validation, il faut respecter les étapes suivantes :

• Sélectionner un système développé de niveau n, puis sélectionner l'option Tester un objet du menu Réduction. A ce moment une fenêtre apparaît et affiche le système instancié du système sélectionné précédemment.

• Choisir dans le menu Fichier l'option nouveau Scénario. • Décrire les différents états nécessaires au scénario.

147

Figure 9.7 : Schéma exhaustif des différentes phases de spécification sous VALID de l’atelier de fabrication