CHAPITRE VI CONCEPTION ET IMPLEMENTATION DE
VI. 2. 1 Formalisation de l’architecture de l’environnement de développement
DEVELOPPEMENT... 128 VI. 2. 2 CONSTRUCTION DE L’ENVIRONNEMENT A PARTIR DE L’ARCHITECTURE... 135 VI. 3 IMPLEMENTATION DE SEAM... 136 VI. 3. 1 BASE DE DONNEES... 136 VI. 3. 1. 1 Structure des blocs ... 136 VI. 3. 1. 2 Types de blocs et règles... 139 VI. 3. 1. 3 Liens de dépendances... 140 VI. 3. 1. 4 Documentation ... 141 VI. 3. 1. 5 IHMs... 142 VI. 3. 2 INTERFACE D’EXPLOITATION DE LA BASE DE DONNEES... 143 VI. 3. 2. 1 Interface principale... 143 VI. 3. 2. 2 Gestion des équipements ... 145 VI. 3. 2. 3 Gestion des règles ... 146 VI. 3. 2. 4 Gestion des IHMs... 147 VI. 3. 2. 5 Gestion des dépendances ... 148 VI. 3. 2. 6 Gestion de la documentation... 148 VI. 3. 3 MODELISATEUR GTPM ... 148 VI. 3. 3. 1 Interactions avec la base de données... 149 VI. 3. 3. 2 Personnalisation de l’interface graphique... 150 VI. 3. 3. 3 Définition de la feuille de style... 151 VI. 3. 4 VERIFICATEUR DE CONFORMITE... 152 VI. 3. 4. 1 Conversion des IHMs en ADL et vérification des contraintes... 154 VI. 4 CONCLUSION ... 154
Chapitre VI : Conception et implémentation de l’environnement
VI. 1 Introduction
Les précédents chapitres ont présenté une approche de conception d’IHMs (logiciels de supervision) au moyen d’un environnement de développement, contrôlé par l’utilisation d’un style formel spécifique à la supervision du redémarrage des accélérateurs de particules. Ils ont en outre décrit le contexte d’utilisation de cet environnement, et traité des techniques disponibles pour exploiter le style formalisé.
Le but du présent chapitre est de détailler l’implémentation de cette approche. La section VI.2 présente tout d’abord l’intégration du style GTPM à l’architecture de l’environnement de développement, et la section VI.3 décrit en détail l’implémentation des différents modules de cet environnement ainsi que leurs interactions.
VI. 2 Intégration du style dans l’architecture de l’environnement de développement
Cette section présente l’intégration du style GTPM dans l’architecture de l’outil SEAM. Cet outil doit constituer un environnement de développement permettant à des utilisateurs non informaticiens de développer des IHMs via une interface intuitive contrainte par le style, et permettre de générer leur code interprétable par le système de supervision.
L’approche choisie dans le cadre de cette thèse consiste à construire des logiciels de supervision à partir d’un environnement de développement dédié, SEAM, intégrant les contraintes d’un style architectural, le style GTPM. Afin d’illustrer le processus de développement architectural utilisé dans ce contexte, la figure VI.1 reprend le processus proposé figure IV.5. Comme l’indique cette figure, les différentes contraintes du style GTPM sont intégrées à l’architecture de SEAM. Cette architecture est faite de plusieurs composants (une base de données, une interface avec la base de données, un modélisateur graphique, et un vérificateur de conformité), intégrant chacun une sous partie des contraintes du style. Le fait que toutes les contraintes du style soient spécifiées au niveau de l’architecture permet de produire des IHMs qui, par construction, vérifient ces contraintes. Il est à noter que la base de données est un composant particulier, son schéma fait partie de l’architecture de l’environnement (il comporte certaines contraintes du style) et ses tables contiennent toutes les informations concernant les architectures
d’IHMs. Ces informations sont contraintes par le schéma de la base mais aussi par les autres composants de l’architecture de l’environnement de développement.
Figure VI. 1 : Construction d’IHMs conformes au style
La section suivante expose la formalisation de l’architecture de l’environnement de développement.
VI. 2. 1 Formalisation de l’architecture de l’environnement de développement
Cette section présente de façon non détaillée la formalisation de l’architecture de l’environnement de développement. La figure VI.2 présente l’architecture décrite en utilisant la notation UML-ADL [Alloui et Oquendo 2003]. Afin de ne pas surcharger la figure, les connexions ne sont pas représentées : seuls les composants, les connecteurs, et leurs ports respectifs sont présents. Les différents attachements spécifiant des interactions sont représentés au niveau des ports.
Figure VI. 2 : Architecture de l’environnement de développement
Cette figure représente les différents composants et connecteurs intervenant dans l’architecture de l’environnement de développement d’IHMs. Les composants sont :
- la base de données interne : il s’agit de la base contenant toutes les informations nécessaires à la production d’IHMs. Celle-ci interagit avec le connecteur
« Traducteur XML » pour produire le code XML interprétable par le système de supervision ;
- les bases de données sources : il s’agit d’un composant externe à l’environnement de développement. Il représente les bases existantes contenant des informations utiles pour définir les logiciels de supervision ;
- l’interface base de données : ce composant permet à l’utilisateur de sélectionner des informations des bases de données sources (via le connecteur « Moteur de requête BD sources », et de sélectionner/insérer/mettre à jour des informations dans la base de données interne (via le connecteur « Moteur de requête BD interne ») ;
- le modélisateur graphique : ce composant permet à l’utilisateur de créer/modifier graphiquement les logiciels de supervision. Il interagit avec la base de données interne via le connecteur « Moteur de requête BD interne » ;
- le vérificateur de conformité : ce composant consulte les informations de la base interne (via le connecteur « Moteur de requête de la base interne ») et les analyse pour informer l’utilisateur du respect ou non respect du style par les logiciels de supervision définis dans la base ;
- le système de contrôle : il s’agit d’un composant externe à l’environnement de développement. Il représente le système de contrôle existant interprétant le code XML extrait de la base interne.
La suite de cette section présente la formalisation de cette architecture en langage ArchWare C&C.
Les ports « Port requêtes BD interne », « Port requêtes BD sources », « Port BD », et
« Port BD sources », représentés sur la figure VI.2 sont du type Port_Bd_In. Ce port est utilisé pour envoyer des requêtes sous forme de chaîne de caractères et pour fournir en retour le résultat de la requête dans une liste de tuples (lignes de base de données).
archetype Port_Bd_In is port with { connections
requete : connection[String], resultat : connection[Tuple{}] ; protocol
replicate
via requete send.
via resultat receive;
}
Les ports « Port vérificateur conformité », « Port modélisateur graphique », « Port interface BD », « Port moteur requêtes », et « Port traducteur XML » représentés sur la figure sont du type Port_Bd_Out :
archetype Port_Bd_Out is port with { connections
requete : connection[String], resultat : connection[Tuple{}] ; protocol
replicate
via requete receive.
via resultat send;
}
Le port « Port système de contrôle » représenté sur la figure est du type Port_Syst_Ctrl. Ce port est utilisé pour envoyer des requêtes sous forme de chaîne de caractères et pour fournir en retour le résultat de la requête sous la forme d’un fichier au format XML.
archetype Port_Syst_Ctrl is port with { connections
requete : connection[String], fluxXML : connection[String] ; protocol
replicate
via requete receive.
via fluxXML send;
}
Le connecteur « Moteur de requêtes BD sources » comporte un port pour se connecter aux « Bases de données sources » et un pour se connecter à « l’interface base de données ». Ce connecteur permet de transmettre la requête et de retourner son résultat en gérant les connexions aux bases de données sources.
archetype Moteur_BD_Sources is connector with { ports
interface_bd_port: Port_Bd_Out, bd_port: Port_Bd_In;
configuration
new interface_bd_port. new bd_port;
routing
replicate
via interface_bd_port~requete receive.
unobservable.
-- ouverture de la connexion avec -- la base de données source via bd_port~requete send.
via bd_port~resultat receive.
unobservable.
-- fermeture de la connexion via interface_bd_port~resultat send;
}
Le connecteur « Moteur de requêtes BD interne » comporte un port pour se connecter à la « Base de données interne » et trois pour se connecter à « l’interface base de données », au « Modélisateur graphique » et au « Vérificateur de conformité ». Ce connecteur permet de gérer les connexions et le routage de requêtes entre la base de données interne de l’environnement et les autres composants.
archetype Moteur_BD_Interne is connector with { ports
interface_bd_port: Port_Bd_Out, modelisateur_port: Port_Bd_Out, verificateur_port: Port_Bd_Out,
bd_port: Port_Bd_In;
configuration
new interface_bd_port. new modelisateur_port.
new verificateur_port. new bd_port;
routing
replicate choose{
{via interface_bd_port~requete receive.
via bd_port~requete send.
via bd_port~resultat receive.
via interfacebd_port ~resultat send};
or
{via modelisateur_port~requete receive.
via bd_port~requete send.
via bd_port~resultat receive.
via modelisateur_port ~resultat send};
or
{via verificateur_port~requete receive.
via bd_port~requete send.
via bd_port~resultat receive.
via verificateur_port ~resultat send};
} }
Le connecteur « Traducteur XML » comporte un port pour se connecter à la « Base de données interne » et un pour se connecter au « Système de contrôle ». Il transmet la requête provenant du système de contrôle, et retourne son résultat en format XML.
archetype Traducteur_XML is connector with { ports
systeme_controle_port: Port_Syst_Ctrl, bd_port: Port_Bd_In;
configuration
new systeme_controle_port. new bd_port;
routing
replicate
via systeme_controle_port~requete receive.
via bd_port~requete send.
via bd_port~resultat receive.
unobservable. -- conversion XML via systeme_controle_port~fluxXML send;
}
Le composant « Modélisateur graphique » comporte un port pour se connecter à la
« Base de données interne » (le composant vérificateur de conformité fonctionne de la même manière) :
archetype Modelisateur_Graphique is component with { ports
bd_port: Port_Bd_In;
attributes
… consituents
… configuration
new bd_port;
computation replicate
unobservable.
-- interaction avec l’utilisateur : spécification d’informations -- concernant les IHMs et demande d’insertion/modification -- dans la base de données interne (requete)
using(requete) verify {…}
-- vérifie que les informations à insérer respectent les -- contraintes du style avant l’envoi de la requête via bd_port~requete send.
via bd_port~resultat receive.
unobservable;-- interaction avec l’utilisateur }
Le composant « Interface base de données » comporte un port pour se connecter à la
« Base de données interne » et un pour se connecter aux « Bases de données sources » : archetype Interface_BD is component with {
ports
bd_sources_port: Port_Bd_In.
bd_interne_port: Port_Bd_In;
attributes
… consituents
… configuration
new bd_source_port. new bd_interne_port;
computation replicate
unobservable. -- interaction avec l’utilisateur choose{
-- consultation BD sources
{via bd_source_port~requete send.
via bd_source_port~resultat receive}
or
-- consultation ou spécification d’informations concernant les
-- IHMs et demande d’insertion/modification dans la base de -- données interne (requete)
{using(requete) verify {…}
-- vérifie que les informations à insérer respectent les -- contraintes du style avant l’envoi de la requête via bd_interne_port~requete send.
via bd_interne_port~resultat receive}}
unobservable;-- interaction avec l’utilisateur }
Le composant « Base de données interne » comporte un port pour se connecter au connecteur « Moteur de requêtes BD interne », et un pour se connecter au connecteur
« Traducteur XML » :
archetype BD_Interne is component with { ports
traducteur_xml_port: Port_Bd_Out.
moteur_requetes_port: Port_Bd_Out;
attributes
… consituents
… configuration
new traducteur_xml_port.
new moteur_requetes_port;
computation replicate
choose{
{via moteur_requetes_port~requete receive.
using(requete) verify {…}
-- vérifie que les informations à insérer respectent les -- contraintes du schéma avant l’exécution de la requête unobservable.
via moteur_requetes_port~resultat send}
or
{via traducteur_xml_port~requete reveive.
unobservable. -- execution de la requête via traducteur_xml_port~resultat send}};
}
Les composants « Bases de données sources » et « Système de contrôle » ne sont pas décris ici car ils sont externes à l’environnement de développement.
La section suivante explique comment l’environnement est construit à partir de cette architecture.