L’ensemble des exécutions a été effectué sur la même machine cluster (plus précisément sur les différents nœuds du cluster). Les expérimentations se font en parallèle sur des nœuds distincts. Elles ne partagent aucune information tout au long de leurs exécutions car chacune d’elle se trouve dans un espace bien spécifique avec un processeur et une mémoire allouée.
Enfin, nous utilisons le caractère itératif de l’ARC (cf. 3). Les exécutions correspondant aux configurations de l’ARC se font de deux façons : d’un côté, une exécution globale qui comprend l’ensemble des étapes de factorisation et d’un autre côté, une exécution étape par étape. La condi- tion d’arrêt pour ce type d’exécution est la même que pour l’exécution globale (le point fixe est atteint).
6.2.3 Récapitulatif des exécutions
Cette démarche génère un peu plus de 1070 exécutions1avec des résultats très intéressants en termes de fusion et d’émergence de nouvelles abstractions.
Néanmoins, un peu moins de 50 exécutions se sont avérées trop longues pour produire des résultats. Ces dernières correspondent aux versions de modèles les plus complexes avec la configu- ration C2 qui contient les relations principales. L’analyse des métriques choisies pour comprendre le comportement de l’ARC sur des modèles UML fait l’objet des sections suivantes.
6.3 L’impact des paramètres
L’ARC effectue plusieurs étapes pour arriver à une factorisation maximale (cf. chapitre3), au cours desquelles elle crée des concepts par fusion ou abstraction d’entités. Le nombre d’étapes dépend principalement de la quantité d’éléments de modélisation pris en compte dans la confi- guration. Par conséquent, cette quantité a un impact sur la complexité des résultats obtenus, par exemple sur le nombre de concepts dans le treillis [Osman Guédi et al.,2012] et sur le comporte- ment général de l’ARC.
Durant toutes nos expérimentations, nous observons que le choix des paramètres présentés précédemment a des conséquences sur la complexité en termes de temps d’exécution et de résul- tats produits. Nous étudions l’effet de ces paramètres à l’aide de métriques et nous en déduisons des recommandations qui permettront d’améliorer la complexité et de favoriser une utilisation in- teractive de l’approche.
6.3.1 Le nommage des éléments de modélisation
En général, Les outils de modélisation s’utilisent d’une manière plus ou moins similaire dans les divers ateliers de génie logiciel. Créer un modèle pour un système d’information consiste à ins- tancier des éléments du méta-modèle. Ainsi, ces outils de modélisation offrent une manipulation flexible, transparente et interactive à l’utilisateur, par exemple avec l’aide d’un système de "Glisser- déplacer" (connu sous le terme de Drag-and-drop en anglais). En premier lieu, lors de l’ajout d’un élément de modélisation, un nom par défaut lui est attribué, qui dépend dans certains cas du nom
de l’élément du méta-modèle instancié. Dans notre cas de figure, Objecteering propose systémati- quement un nom par défaut pour l’ensemble des élément de modélisation. Par exemple pour les classes, Objecteering propose Classe1, Classe2 etc. et pour les attributs, il propose attribut1, attri- but2, etc.
Par contre, nous remarquons que les rôles portent par défaut un nom unique, le nom "undefi- ned", signifiant que le nom du rôle en question n’est pas défini. L’utilisation de ce nom par défaut aura un impact sur les exécutions et les résultats de nos expérimentations. Dès lors que les modèles possèdent des rôles dont le nom n’est pas défini (donc portant le nom "undefined") nous consta- tons une hausse du nombre de rôles sélectionnés, c’est-à-dire que nous avons plus de rôles dans le contexte relationnels de rôles pour les configurations (C1 et C2). Des métriques sont introduites pour évaluer les conséquences de ce paramètre, d’une part sur les factorisations obtenues (cf. cha- pitre5) et d’autre part sur le comportement de l’ARC.
Remarquons que pour notre cas de figure, les seuls rôles dont le nom n’est pas défini dans les modèles, sont les rôles qui sont à l’opposé du sens de la navigabilité. Donc leur étude se limite à la configuration C2 et au cas où la navigabilité est ignorée. Dans ce cas (sans navigabilité et en considérant les undefineds), la fin de l’exécution n’a été atteinte que pour les quatre premières versions. Nous n’étudierons donc ce paramètre que pour ces quatre premières versions.
Le rôle est un élément très important dans la configuration C2, car il décrit les associations (qui possèdent des rôles), ainsi que les classes (qui possèdent aussi des rôles) et les rôles sont décrits à son tour par les classes pour définir leur type. Une première observation montre que le nombre d’étapes augmente sensiblement lors de la prise en compte de ces éléments de modélisation non nommés (cf. figure6.1). Ce nombre d’étapes s’accroît de 44% en moyenne. Enfin, plus les modèles deviennent complexes plus cette hausse se confirme.
V e rs io n A v ec und e fineds S ans u ndefine d s R endem ent V0 17 6 64,71% V1 22 11 50% V2 16 12 25% V3 22 14 36,36%
TABLE6.1: Gain de nombre d’étapes
FIGURE6.1: Gain de nombre d’étapes
Par voie de conséquence, les rôles non nommés ont, d’une part, un impact sur la cohérence des factorisations (cf. chapitre5) et d’autre part, ils augmentent la complexité des exécutions. Donc, les premières recommandations à l’utilisateur consisteront à ne prendre en compte dans les confi- gurations que les rôles dont le nom est défini. Ces conséquences se généralisent pour tout autre élément de modélisation présentant les mêmes caractéristiques. En d’autres termes, il vaut mieux ne prendre en compte que les classes, associations, méthodes, attributs, etc. dont le nom a été dé- fini par l’utilisateur et non pas généré automatiquement.
6.3. L’IMPACT DES PARAMÈTRES 111
6.3.2 L’impact du sens de la navigabilité des associations
Le second paramètre des expérimentations s’avère essentiel sur le comportement de l’ARC. Il concerne la prise en compte du sens de la navigabilité (cf. section 4.3.2.3, qui est aussi déterminant sur l’aboutissement des exécutions.
En effet, l’ARC procède en plusieurs étapes pour arriver à une factorisation maximale. De ce fait, la prise en compte du paramètre correspondant à la navigabilité influence d’une part le nombre d’étapes et d’autre part la complexité liée à l’exécution pour arriver à terme, autrement dit, son temps de calcul et l’espace mémoire utilisé.
La prise en compte du sens de la navigabilité diminue le nombre d’éléments de modélisation dans les contextes et nous remarquons que l’ensemble de ces exécutions arrivent bien à leur terme. A l’inverse, lorsque le sens de la navigabilité est ignoré et que seuls les éléments nommés sont pris en compte (resp. non pris en compte), seules les exécutions des cinq (resp. quatre) premières ver- sions du modèle arrivent à terme.
Les contextes relationnels sont moins volumineux lorsqu’ils prennent en compte le sens de la navigabilité (cf. les tables de contextes du chapitre4), notamment le cas de la configuration C2, car cette dernière contient plusieurs relations liées aux rôles. Dans le cadre de nos modèles, l’avantage de ce paramètre est de sélectionner uniquement les rôles qui sont du côté navigable des associa- tions et d’éviter les rôles dont le nom n’est pas défini.
Un gain de 22% en moyenne est observé sur le nombre d’étapes lors de la prise en compte de la navigabilité (cf. le tableau 6.1). V e rs io n A v e c na viga b ilité S ans nav ig abi li té R endem ent V0 6 6 0% V1 8 11 27,27% V2 10 12 16,67% V3 8 14 42,86%
TABLE6.2: Gain sur le nombre d’étapes
FIGURE6.2: Gain sur le nombre d’étapes
En effet, la figure 6.2montre que la prise en compte de la navigabilité permet d’atteindre en peu d’étapes la factorisation maximale, tout en produisant moins de concepts dans le treillis final. De même que la précédente, les figures 6.3et 6.4indiquent le nombre de concepts produits par l’ARC pour la première étape et la sixième étape. Cette dernière est l’étape la plus lointaine atteinte par les expérimentations pour l’ensemble de versions du modèle. Ainsi, nous constatons d’une part, un écart sur le nombre de concepts et d’autre part, que cet écart augmente au cours des étapes comme le montre la figure6.4qui correspond à l’étape 6 de la factorisation pour l’ensemble de versions.
FIGURE6.3: Le métrique sur le rendement à l’étape 1
FIGURE6.4: Le métrique sur le rendement à
l’étape 6
Nous définissons ci-après une métrique de rendement qui exprime le gain en nombre de concepts créés en prenant en compte la navigabilité par rapport au cas où la navigabilité n’est pas prise en compte. Rendement =
Nombr e d e concep t s sans l a navi g abi l i t é − Nombr e de concept s avec l a navi g abi l i té Nombr e d e concept s sans l a navi g abi l i t é
× 100 (6.1)
Le gain en nombre de concepts est à 17% en moyenne à la première étape et il passe à 89% en moyenne à l’étape 6 de la factorisation, cette étape 6 correspond à la plus lointaine que nous ayons pu atteindre dans nos exécutions. En d’autres termes, l’ARC produit de plus en plus de concepts tout au long des étapes et ce nombre de concepts augmente particulièrement dans le cas où le sens de la navigabilité est ignoré.
6.3.3 Discussion et recommandation
Nous avons vu dans cette section, d’une part, l’importance de nommer chaque élément de mo- délisation, surtout dans notre cadre d’étude où la sémantique a une forte importance pour la facto- risation des éléments de modélisation. D’autre part, nous avons constaté l’influence de la prise en compte de la navigabilité des associations. Ces deux paramètre améliorent considérablement les résultats, tant sur la cohérence des factorisations obtenues que sur le nombre d’étapes de factori- sation et sur le nombre de concepts obtenus dans les treillis.