afin de charger les données requises et de réutiliser les plug-ins préexistants. Le Smart-hub est configuré pour charger ces plug-ins de ce site et ensuite il est mis en exécution.
Le site de distributeur GDS a changé le format de données d’Excel à CSV. Comme les plug-ins de composant de communication et de composant indépendant de domaine sont modulaires, ils ne sont pas affectés par ce changement. Il est juste nécessaire d’utiliser le plug-in "CSVProjection" au lieu de "ExcelProjection" au niveau de composant spécifique au domaine. Le plug-in existant "CSVProjection" gère seulement l’extraction pour le processus de génération de données (utilisé par le système QGIS), donc il est entendu pour gérer aussi l’injection pour le processus d’acquisition de données. Ensuite, le Smart Hub est reconfiguré pour prendre en compte cette nouvelle configuration.
Ce cas d’usage a souligné les principales caractéristiques du Smart-hub :
• Générique : le Smart-hub n’impose pas un modèle de données ou une norme spéci- fique à respecter. Donc, il peut être appliqué dans n’importe quel domaine où l’inter- opérabilité doit être traitée. Ici, nous avons appliqué dans le domaine des réseaux de gaz.
• Modulaire : la modularité du Smart-hub en termes de différents niveaux d’inter- opérabilité a joué un rôle important dans notre proposition. Nous avons pu modi-
fier/remplacer le plug-in à un niveau d’interopérabilité sans affecter le plug-in pour les autres composants. Par exemple, dans le cas d’ usage étendu de projet GONTRAND, nous avons remplacé les plug-ins à un niveau d’interopérabilité sans affecter les autres niveaux.
• Extensible : le Smart-hub est extensible à tous les niveaux d’interopérabilité et pour chaque niveau, nous sommes en mesure d’étendre les composants avec les plug-ins appropriés qui sont requis par les systèmes dans l’environnement.
• Agnostique : le Smart-hub est agnostique de la technologie/normes des systèmes avec lesquels elle interagit. Avec les extensions (les plug-ins), le Smart-hub a pu interagir avec les systèmes tels qu’ils existent sans leur imposer de suivre une technologie ou une norme spécifique.
La modularité et l’extensibilité ont eu un impact important sur la réutilisation et l’agilité du système. Un plug-in est créé une fois et utilisé plusieurs fois. De plus, lorsque l’environ- nement évolue, que de nouveaux systèmes sont ajoutés ou que des systèmes sont supprimés ou modifiés à un niveau d’interopérabilité particulier, le développeur peut rapidement réagir à ces changements en ajoutant les plug-ins requis et en configurant le Smart-hub. Il n’est pas nécessaire de retravailler le système d’interopérabilité de zéro. Cela se traduit par un gain global en termes de réduction du temps et du coût de développement, comme cela sera ex- pliqué dans le chapitre suivant.
5.3 Conclusion
Ce chapitre a discuté l’application du Smart-hub à deux cas d’usage afin de démontrer com- ment utiliser notre système. Dans le premier cas d’usage de l’exemple fil rouge, nous avons créé un certain nombre de plug-ins afin d’étendre le Smart-hub pour interagir avec les sys- tèmes externes de l’exemple. Nous avons montré comment configurer le Smart-hub pour charger ces plug-ins et comment il interagit avec les systèmes externes. Nous avons égale- ment montré comment le Smart-hub gère les données dans les deux processus pour l’acqui- sition de données et la génération de données des et aux systèmes externes, respectivement. Enfin, cet exemple s’est terminé avec la représentation du comportement du système vis-à- vis de l’architecture dirigée par les modèles.
La deuxième partie de ce chapitre visait à démontrer l’application de notre système sur le cas d’usage de projet GONTRAND. Ce cas d’usage a mis en évidence les principales carac- téristiques de notre système telles que la modularité, l’extensibilité, l’agnositicité et l’aspect générique qui à leur tour favorisent la réutilisation et réduisent ainsi le coût de temps et du développement comme nous le verrons dans le chapitre suivant.
Validation
Sommaire
6.1 Le carré de validation dans le contexte du Smart-hub . . . 126
6.1.1 Validation théorique de la structure . . . 126
6.1.2 Validation empirique de la structure. . . 128
6.1.3 Validation empirique de la performance . . . 131
6.1.4 Validation théorique de la performance. . . 132
La validation est une phase essentielle de la théorie du design pour guider le dévelop- pement et l’évaluation de nouvelles méthodes [Barth et al.,2011b]. L’IEEE définit la valida- tion [IEE,1998] comme "la confirmation, par la fourniture de preuves objectives, que les exigences spécifiées ont été remplies". Autrement dit, la validation détermine si la méthode où le logiciel final accomplit son but prévu en répondant aux exigences et aux attentes des utilisateurs. Maintenant que nous avons présenté notre solution, nous souhaitons fournir quelques arguments qui valident que celle-ci répond bien au besoin d’interopérabilité entre les systèmes hétérogènes et que celle-ci a aussi des valeurs ajoutées par rapport aux solutions existantes en validant les caractéristiques présentées précédemment : générique, modulaire, agnostique et extensibles.
Différentes approches de validation peuvent être utilisées pour valider les nouvelles so- lutions dans une grande variété de disciplines. Dans les disciplines de problèmes fermés qui utilisent des équations et des algorithmes mathématiques, la validation est un proces- sus strictement formel, algorithmique, réductionniste, de confrontation, où les nouvelles connaissances sont vraies ou fausses. Cependant, dans certaines disciplines de problèmes ouverts, où les nouvelles connaissances sont associées à des heuristiques et à des représen- tations non précises, ainsi qu’à la modélisation mathématique, la validation n’est pas direc- tement formelle. En fait, la validation est considérée comme un processus graduel de ren-
forcement de la confiance dans l’utilité de la nouvelle connaissance par rapport à un but
[Seepersad et al.,2006].
Il y a plusieurs façons et des études différentes proposant des cadres de validation tels que [Barth et al.,2011a,Seepersad et al.,2006]. [Frey and Dym,2006] fournit une revue de la littérature de certaines approches de validation. Le cadre du carré de validation (Validation Square, en anglais) [Seepersad et al.,2006] est utilisé pour valider la recherche en conception et les méthodes de conception dans le domaine de l’ingénierie. Il convient de valider les recherches et les résultats scientifiques en général pour autant qu’ils puissent être appliqués à l’évaluation quantitative et qualitative. Dans ce manuscrit, nous utilisons ce cadre du carré de validation pour évaluer le Smart-hub comme expliqué dans la section suivante.
6.1 Le carré de validation dans le contexte du Smart-hub
Le carré de validation a pour but d’établir un processus de confiance pour valider les résultats scientifiques dans son utilité pour un but donné. Ici, notre but est d’assurer l’interopérabilité entre des systèmes hétérogènes en temps réel de manière à ce que chaque système puisse interagir en utilisant sa propre technologie (mécanisme de communication, son format de données et sa sémantique) en mettant l’accent sur les caractéristiques du systèmes géné- rique, modulaire, agnostique et extensibles. Pour atteindre le but indiqué, nous avons défini quelques fonctions comme indiqué dans la section1.5du chapitre1.
Dans ce cadre, l’utilité d’un résultat est associée à deux critères. Le premier critère est l’efficacité (effectiveness, en anglais) : est-ce que les résultats sont corrects ? Cela correspond à l’évaluation sur la base de mesures qualitatives. Le deuxième critère est l’efficience (effi- ciency, en anglais) : est-ce que les résultats sont obtenus avec des performances acceptables ? Cela correspond à l’évaluation sur la base de mesures quantitatives (ex. moins de temps et moins de dépenses) ? La figure6.1illustre le processus de renforcement de la confiance dans l’utilité où le carré de validation au bas du diagramme représente la synthèse du processus de validation.
Pour valider les résultats scientifiques, le carré de validation préconise alors de diviser l’exercice en quatre dimensions : (1) la validation théorique de la structure ; (2) la valida- tion théorique de la performance ; (3) la validation empirique de la structure ; (4) la valida- tion empirique de la performance ; dans la suite, nous appliquons chaque dimension dans le contexte du système Smart-hub.
6.1.1 Validation théorique de la structure
L’objectif principal de la validité structurelle théorique est la cohérence logique du système (notre résultat scientifique) proposé. La validation théorique de la structure impose trois étapes. La première étape consiste à définir les exigences de haut niveau qui doivent être satisfaites par notre système. Nous revoyons ces exigences qui ont déjà été définies dans la section1.5.
Smart-Hub Data Co ns ume rs Data P roduce rs Purpose Refer to chapter 1 - section 1.5 System Validity Criteria: USEFULNESS with
respect to a PURPOSE THEORETICAL STRUCTURAL VALIDITY THEORETICAL PERFORMANCE VALIDITY EMPIRICAL STRUCTURAL VALIDITY EMPIRICAL PERFORMANCE VALIDITY 1 2 3 4 Appropriateness of examples and use cases used to verify system usefulness
Accepting the logical consistency of the constructs of the system
Performance of system with respect to examples and use cases Performance of the system beyond the examples and use cases
A Leap of Faith Effect iv eness : Q ual itati v e Ev al uati on of the s y s tem Efficiency : Q uanti tati v e Ev al uati on of the s y s tem