Bilan

En essayant d'apporter des réponses aux questions que nous nous sommes posées dans la présentation du but de notre recherche (section 1.2), nous pouvons juger l'effort accompli pour ce travail de thèse. Sur la base des exemples qui ont été traités, nous pouvons savoir ce qui est fait, ce qui reste à améliorer et ce qui serait encore à faire.

8.1.1 Quels sont les éléments nécessaires dans le flot de données?

Pour pouvoir intégrer le flot de données, nous avons besoin des concepts permettant de considérer les données utilisées individuellement par les nœuds du script, les données partagées par l'ensemble des nœuds et les échanges des données entre les nœuds.

Est-ce que ces concepts sont donc présents dans notre formalisme? La réponse est trois fois OUI. Il s'agit des paramètres des nœuds pour les données individuelles, des nœuds de données pour les données partagées et les arcs de flots de données pour les échanges de données.

8.1.2 Comment ces éléments sont-ils représentés dans notre formalisme visuel?

La réponse à cette question est développée dans le chapitre 4 mais nous pouvons la résumer comme suit.

Les paramètres sont représentés visuellement par des décorations ajoutées aux nœuds concernés. Puisque nous avons deux modes de vues, nous avons deux types de décorations:

les terminaux de données dans la vue flot de données et les anses de paramètres dans la vue flot de contrôle.

Les nœuds de données ont trois formes de représentation. La première est une représentation plutôt textuelle qui est affichée avec le contenu du nœud. Les deux autres sont des représentions iconiques.

Et finalement, l'échange de données est représenté par des arcs orientés, l'origine de l'arc correspond au nœud "expéditeur" des données et sa destination correspond au nœud

"destinataire" des données.

8.1.3 Quelle est l'utilité de ces éléments?

Le fait de pouvoir représenter visuellement les paramètres des nœuds permet aux utilisateurs de prendre connaissance facilement de l'existence des données manipulées par ces nœuds. Si cette représentation fait défaut, l'utilisateur doit consulter le contenu du nœud et pourrait être obligé à déchiffrer ce contenu. Ce qui n'est pas forcement facile.

La présentation visuelle des échanges permet de suivre les circulations des données, et d'en déduire les éventuelles dépendances entre les différents nœuds. Les autres sémantiques que nous avons ajoutées aux arcs de flot de données enrichissent davantage les informations fournies par leurs représentations.

L'utilisation des nœuds de données permet de spécifier les stockages des données qui pourront être traitées ultérieurement ou qui pourront être partagées par plusieurs nœuds. Le fait de donner une représentation visuelle de ces nœuds permet de spécifier explicitement la volonté de stocker les données.

8.1 Bilan 189

L'ensemble de tous ces éléments permet aux concepteurs de penser en terme de données durant la spécification de leur application.

8.1.4 Quels sont les différents comportements que l’intégration du flot de données rend possibles?

Le premier comportement évident est l'échange de données entre les nœuds. Si un arc de flot de données relie deux nœuds d'activités, lorsque le nœud source finit son exécution, il envoie le long de cet arc les données correspondantes qui seront donc reçues tout de suite par le nœud destinataire. Si la source est un nœud de données, les données sont transférées lorsque le destinataire en a besoin.

D'autres comportements ont été définis au niveau du nœud destinataire. Celui-ci peut

"consommer" les données qu'il reçoit et aura donc besoin d'une nouvelle arrivée de données pour sa prochaine activation. Ou bien, la dernière valeur des données reçue par le destinataire reste toujours valable et il peut l'utiliser plusieurs fois si aucune nouvelle valeur n'est arrivée.

8.1.5 Comment ces comportements sont-ils spécifiés visuellement?

Le comportement correspondant aux envois de données est simplement spécifié visuellement par les arcs de flot de données. Mais le comportement correspondant à la "consommation" des données par les nœuds destinataire est spécifié visuellement par les terminaux de données.

C'est pour cela que nous avons défini deux sortes de terminaux d'entrée: terminaux déclenchants et terminaux non déclenchants.

8.1.6 Comment tenir compte des données dans le générateur de code?

Le générateur de code doit respecter la même règle qu'en chimie qui disait "rien ne se perd et rien ne se crée mais tout se transforme". C'est à dire que dans les modules produits par le générateur, les éléments visuels et les comportements spécifiés par le script doivent être

"transformés" ou "décodés" pour que l'application ainsi développée ait les comportements attendus.

Pour cela, les paramètres de chaque nœud deviennent des paramètres formels de la procédure ou fonction correspondante. L'envoi des données le long des arcs est codé par des copies de chaque paramètre de sortie à tous les paramètres d'entrées qui lui sont attachés. Ces valeurs deviennent ensuite des paramètres actuels pour l'appel des procédure ou fonction correspondante. Une structure de données spéciale est créée pour chaque paramètre d'entrée afin qu'on puisse vérifier l'arrivée d'une nouvelle instance si ce paramètre correspond à un terminal déclenchant.

8.1.7 Un peu de chiffres

Pour l'implémentation de notre formalisme, nous avons repris les codes qui existent déjà pour la version purement de flot de contrôle et nous y avons ajouté les codes nécessaires pour l'intégration du flot de données. La raison de ce choix est notre décision de garder tel quel le comportement de l'ancien système pour qu'on puisse utiliser toujours les scripts créés avec celui-ci.

Pour cela, il a fallu comprendre les milliers lignes de code pour savoir "où mettre la main".

Ceci est une tâche assez difficile puisque ces codes ne sont pas toujours bien documentés.

Rappelons que pour l'éditeur de script l'interface utilisateur graphique est écrit en Tcl/Tk tandis que les manipulations internes sont écrites en Ada. La communication entre ces deux composantes est écrite en C. Quant au générateur, il est écrit entièrement en Ada. Le petit tableau suivant recense les nombres de lignes de code existant avant (c'est-à-dire, les codes à comprendre) et les nombres de lignes de code après l'intégration.

Nombre de lignes de code Ada Nombre de lignes de code Tcl/Tk Composante

Avant Après ajout Avant Après ajout

Editeur de script 66.274 71.713 5.439 15.837 17.627 1.790

Générateur de code 4.712 6.615 1.903