LPL YOURCASTle moteur de template Apache Velocity1afin de faciliter la génération de code. L’étape de génération de code produit ainsi dans le cadre de YOURCASTplusieurs projets
distincts contenant leur propre hiérarchie de code : un projet représentant le client, un autre représentant le service d’administration et enfin différents projets pour chacun des providers nécessaires.
Element Code commun Code variant2 Total
Client 10545 4760 15305 Administration 58915 32403 91318 Provider 1 839 288 1127 Provider 2 839 232 1071 Provider 3 839 250 1089 Provider 4 839 231 1070 Total 72816 38164 110980
TABLE9.1 – Métriques de code pour un SDI moyen
LeTableau 9.1donne quelques chiffres concernant la densité de codes générés ou réutilisés dans le cadre d’un SDI moyen contenant 4 zones, et donc 4 providers. Toutes les valeurs données sont en lignes de code. La majorité du code généré est réalisée au sein du système d’administration afin de créer les différentes interfaces de personnalisation en fonction des sources sélectionnées par l’utilisateur et des liens réalisés. Enfin, une partie importante du client est également générée ou réutilisée en fonction des choix utilisateurs. Ces mesures correspondent à la configuration A du tableau présenté plus loin.
9.3.4
Compilation et packaging
La dernière étape du processus de génération réalise la compilation et le packaging des différents projets de code réalisés à l’étape précédente. Ainsi les différents projets générés dans le langage Java sont compilés et packagés pour être déployés sur un serveur d’application de type Tomcat. Dans le cadre de YOURCAST nous exploitons les facilités offertes par l’outil de gestion et d’automatisation de production de logiciels Apache Maven3afin de réaliser ces
opérations.
Le client est par ailleurs compressé sous la forme d’une archive déployable également sur un serveur d’application.
Ainsi le processus de génération part d’une configuration composite et exploite différents métamodèles en association avec un dépôt d’assets afin de réaliser un logiciel compilé et packagé, prêt à être déployé.
9.4
Objectifs et Résultats
Nous avons défini et utilisé la LPL YOURCASTen exploitant l’approche définie dans notre contribution (voir chapitres5et6).
Nos travaux sur les processus de configuration visent à définir un processus qui soit à la fois flexible et cohérent, mais qui soit également utilisable (voirchapitre 4). Nous présentons à
1. http://velocity.apache.org/
2. Il peut s’agir d’un code généré en partie ou totalement, ou simplement réutilisé. 3. http://maven.apache.org/
9.4. Objectifs et Résultats Chapitre 9. Réaliser des produits dans la LPL YourCast
présent les différents processus de configurations opérés et les résultats obtenus, avant de revenir sur nos deux objectifs et leurs validations.
9.4.1
Configurations et résultats obtenus
La LPL YOURCASTa été utilisée pour réaliser différents types de SDI en fonction des dé-
ploiements qui étaient demandés dans le cadre du projet YOURCAST. Nous nous concentrons ici
uniquement sur dix configurations de SDI dont des mesures sont présentées dans leTableau 9.2. De nombreux SDI ont été configurés et générés à partir de cette LPL (plus d’une vingtaine de SDI différents ont été déployés durant le projet YOURCAST), nous nous focalisons cependant
ici sur un échantillon représentatif de SDI réalisés dans différentes conditions.
A B C D E F G H I J Moy. Sous-Config. 37 9 25 17 23 61 11 12 7 21 22,3 Liens 36 8 24 16 22 60 8 9 6 20 20,9 Contextes 19 5 13 9 12 32 9 8 7 11 12,5 CPS 77 21 53 37 49 129 37 33 29 45 51 Actions Util. 259 68 194 147 172 348 78 125 51 138 158 Actions Sys. 4111 849 2835 1727 2703 7218 1416 1587 942 1965 2535,3 Actions Auto. 631 140 462 241 399 1492 299 239 178 213 429,4 Actions FM. 3480 709 2373 1486 2304 5726 1117 1348 764 1752 2105,9 % Actions Util. 5,93 7,42 6,40 7,84 5,98 4,60 5,22 7,30 5,14 6,56 5,87 % Actions Sys. 94,07 92,58 93,60 92,16 94,02 95,40 94,78 92,70 94,86 93,44 94,13
TABLE9.2 – Résultats obtenus suite aux configurations YourCast
Les six premières colonnes de ce tableau (de A à F) ont ainsi été obtenues lors de configu- rations réalisées par des experts de la LPL, soit pour déploiements réels (de A à D), soit pour tester des propriétés de la LPL (E et F). Les quatre colonnes suivantes (G à J) concernent des résultats obtenus dans le cadre d’expérimentations sur l’ergonomie de nos interfaces par des personnes qui n’étaient pas expertes dans l’utilisation des outils de configuration, ni même dans les SDI (personnels administratifs ou de communication). Enfin la dernière colonne présente les moyennes obtenues.
Les deux premières lignes de résultats concernent le nombre de sous-configurations et de liens obtenus dans la configuration composite. Les deux lignes suivantes présentent le nombre total de contextes et de CPS utilisés lors de la configuration, les contextes et CPS supprimés sont donc comptés. Les deux lignes d’après montrent le nombre d’actions utilisateur et système réalisées durant le processus de configuration. Les actions système sont divisées en deux catégories dans les lignes suivantes : les actions portant sur les FM et les autres actions automatisées. Enfin les deux dernières lignes donnent le ratio en pourcentage du nombre d’actions utilisateur et système sur le nombre total d’actions.
Nous avons également agrégé des données sur notre algorithme de propagation durant ces processus de configuration.
9.4. Objectifs et Résultats Chapitre 9. Réaliser des produits dans la LPL YourCast
Chemin # Occurences Durée (ms) # Actions # Contextes impactés4 # CPS impactés
1 141 1,81 9,77 1 1 2 116 2,23 25,02 1,16 1,83 3 60 584,18 32,55 1,05 2,9 4 7 9,29 32,43 1,57 3,14 5 30 99 29,77 2 [CG] 5 6 35 730,26 51,40 1,91 [CG] 4,91 7 36 1607,08 47,97 1,92 [CG] 5 9 1 2109 78 2 [CG] 5 10 2 38 57 2,5 [CG] 7 13 1 1575 52 2 [CG] 9 16 2 1393 77 2 [CG] 9 18 2 785 118,5 2,5 [CG] 7 19 1 798 57 2 [CG] 9 20 1 2035 95 2 [CG] 9 26 3 1556,67 137 3 [CG] 13 27 1 1572 81 7 [CG] 21 36 1 3622 218 7 [CG] 29 40 2 878 120 2,5 [CG] 11
TABLE9.3 – Résultats obtenus sur les propagations
Chemin Durée (ms) # Actions # Contextes impactés # CPS impactés
Minimum 1 0 1 1 1
Maximum 40 4206 218 7 29
Moyenne 3,54 327,11 28,54 1,35 2,81
Ecart type 4,55 708,58 24,25 0,62 2,54
TABLE9.4 – Statistiques globales obtenues sur les propagations
Celles-ci sont présentées dans le Tableau 9.3. Durant les 10 processus de configuration réalisés, nous avons ainsi comptabilisé 442 lancements de l’algorithme de propagation, en dehors des appels de récursivité de l’algorithme. Nous représentons dans leTableau 9.3 les données agrégées sur ces propagations en les groupant en fonction de la taille des chemins de propagation réalisés. La taille d’un chemin de propagation est déterminée par le nombre d’appels récursifs réalisés. Nous représentons cette donnée dans la première colonne du tableau.
La seconde colonne du tableau représente le nombre d’occurences de chaque taille de chemin de propagation. La troisième colonne donne les durées moyennes de propagation en fonction de la taille du chemin. La quatrième colonne montre le nombre d’actions système réalisées en moyenne. La cinquième colonne présente le nombre moyen de contextes impactés durant la propagation ; nous indiquons également dans cette colonne par la mention “[CG]” si le contexte global a été impacté plus de 50% du temps. Enfin, la sixième colonne donne le nombre moyen de CPS qui ont été impactés par la propagation.
LeTableau 9.4reprend les mêmes colonnes que le tableau précédent mais établit cette fois des statistiques globales basées sur les 442 valeurs confondues obtenues durant la propagation. L’ensemble des mesures relatées ici ont été effectuées sur une machine virtuelle exploitant un système d’exploitation Linux Debian version 6.0.8, possédant 4096 Mo de mémoire vive
4. La mention “[CG]” signifie que le contexte global a également été impacté dans la majorité des cas (> de 50%).
9.4. Objectifs et Résultats Chapitre 9. Réaliser des produits dans la LPL YourCast
(RAM) et 4 CPU cadencés à 2,4 Ghz. Nos outils étaient lancés en tant que services sur le serveur d’application Apache Tomcat 6 limité à 512 Mo de mémoire. La version utilisée de la machine virtuelle Java pour nos expérimentations était la version 1.6.0 build 26.
Nous discutons l’ensemble de nos résultats au travers de la validation de nos différents objectifs.
9.4.2
Flexibilité et cohérence du processus de configuration
La flexibilité et la cohérence du processus de configuration constitue le deuxième objectif de nos travaux de thèse (voirsection 4.3). Nous validons cet objectif en reprenant les différents sous-objectifs qu’il définit.
9.4.2.1 Garantir un processus de configuration dynamique et cohérent
Nous avons effectué une validation théorique de la dynamicité et de la cohérence du pro- cessus de configuration à travers notre contribution (voir chapitre 6). En effet, nous avons défini formellement les propriétés de cohérence et de flexibilité du processus de configuration (Propriété 6.1.1) avant de montrer comment notre formalisme associé à nos algorithmes de propagation (section 6.4) et d’annulation (sous-section 6.5.3) permettent d’assurer ces propriétés. Par ailleurs, nous avons également montré comment assurer la dynamicité du processus de configuration en utilisant les algorithmes de satisfiabilité pour assurer l’inférence automatique des contraintes sur les FM (section 6.2).
Les configurations présentées dans leTableau 9.2sont toutes des configurations cohérentes selon laPropriété 5.3.3et ont été obtenues grâce à l’implémentation de notre formalisme qui s’appuie sur des outils permettant d’assurer la dynamicité de la configuration.
9.4.2.2 Permettre un processus de configuration par étapes, ainsi que l’annulation d’étapes et la reprise de configuration
Nous avons défini dans notre formalisme un modèle d’action dans lequel nous distinguons les actions utilisateur et les actions système (section 6.5). Nous considérons par ailleurs un historique de configuration (sous-section 6.5.2) contenant les différentes étapes de configurations définies par les actions utilisateur.
Si nous n’avons pas pu obtenir d’informations concernant l’utilisation des opérations d’an- nulation durant le processus de configuration, la fonctionnalité ayant été développée et intégrée tardivement à l’interface TOCSIN, nous avons cependant agrégé de nombreuses informations concernant les actions réalisées durant différents processus de configuration (voirTableau 9.2). Nous montrons ainsi, qu’en moyenne, si les utilisateurs réalisent 158 actions pour définir un SDI constitué de 22,3 éléments distincts, 2535,3 actions système sont réalisées automati- quement, parmi lesquelles 2105,9 actions sur les FM. Cela revient à dire que notre approche permet d’automatiser plus de 94% des actions afin de configurer un système, sans compter les vérifications effectuées pour chacune des actions.
En outre, nos outils permettent d’enregistrer et d’exporter une configuration sous la forme d’une liste d’actions utilisateur. Cela nous offre la possibilité de réimporter des configurations composites existantes, même si la LPL a évolué : en effet, l’importation d’une configuration consiste à exécuter les actions utilisateur ; si la LPL a évolué et qu’une action utilisateur n’est plus possible, alors la précondition de l’action interdit son action, sans empêcher le reste de l’importation de la configuration. Cette possibilité, combinée aux opérations d’annulation, nous