Techniques semi-automatiques pour Thales Air Systems

En raison de leur nature, les techniques semi-automatiques sont partiellement automatisées et répondent toutes à la première exigence énoncée en début de sec- tion.

3.3. Les techniques de reconstruction d’architecture adaptées aux besoins de

Thales Air Systems 31

Requêtes relationnelles De par leur définition, les requêtes relationnelles ont été appliquées sur des logiciels comportant des bases de données. Cela contredit l’exigence (exivi) et ainsi les requêtes relationnelles n’ont pas été retenues

pour le projet de l’entreprise.

Requêtes logiques Les requêtes logiques nécessitent de pouvoir définir un en- semble de prédicats contenant toutes les implémentations possibles des pa- trons de conception. Cependant, définir toutes ces implémentations entraîne une explosion combinatoire de la complexité de cette technique [Guéhé- neuc 2004,Guéhéneuc 2008]. Cela contredit donc l’exigence(exiiii)du projet

de l’entreprise visant un passage à l’échelle, ce qui implique que les requêtes logiques n’ont pas été retenues pour le projet de Thales Air Systems.

Requêtes lexicales Par leur nature, les requêtes lexicales se basent sur des infor- mations textuelles et en font ainsi une approche statique, ce qui respecte l’exigence (exiii). Le passage à l’échelle (exigence (exiiii)) de telles tech-

niques a été prouvé par Poshyvanyk et al. [Poshyvanyk 2006], avec un cas d’étude sur un logiciel de plus de 3, 7 MLoC. Plusieurs cas d’études dis- ponibles en littérature se concentrent sur la reconnaissance des fonctionna- lités (feature location) [Marcus 2004,Marcus 2005,Poshyvanyk 2006,Ba- vota 2010]. D’autres cas d’études ont pour but la reconnaissance de com- posants [Braga 2001,Sugumaran 2003,Alnusair 2010] dans des applications sans base de données, ce qui confirme les exigences(exiiv)et(exivi). Les re-

quêtes lexicales respectent la totalité des exigences étudiées ici. Ainsi, cette technique est retenue pour automatiser le projet de l’entreprise, sous réserve de respecter l’exigence d’adaptabilité. La technique, utilisant les requêtes lexicales, la plus reconnue est la recherche d’information (information re- trieval) et a été utilisée par Marcus et Poshyvanyk pour chacun des articles cités précédemment.

Recognizers Les recognizers sont utilisés dans plusieurs outils de reconstruction d’architecture [Yeh 1997,Fiutem 1999,Guo 1999]. Cependant, Mendonça et Kramer [Mendonça 2001] ont noté que les recognizers souffrent d’un pro- blème lors d’un passage à grande échelle (grande variabilité des implémen- tations d’une fonctionnalité) ce qui infirme l’exigence(exiiii). Ainsi, les re-

cognizersne sont pas retenus pour le projet de Thales Air Systems.

Reconnaissance de patrons de graphes Les techniques utilisant la reconnaissance de patrons de graphes sont également sujettes à des problèmes lors de leur application sur de grands projets (passage à l’échelle). En effet, Sartipi [Sar- tipi 2003a] explique dans sa thèse de doctorat qu’un logiciel de grande taille augmente significativement le temps de calcul de cette technique (plusieurs dizaines d’heures pour des logiciels d’une dizaine de kLoC). Cela empêche la technique d’être performante avec de grands logiciels ce qui contredit l’exi-

gence (exiiii). Ainsi la reconnaissance de patrons graphe n’est pas retenue

pour le projet de l’entreprise.

Moteurs d’états Comme indiqué dans la Section 3.2.3, les moteurs d’états sont des techniques nécessitant une exécution du logiciel. Or cela contredit l’exi- gence(exiii)et implique donc que les moteurs d’états ne sont pas applicables

dans le cadre du projet de Thales Air Systems.

3.3.3

Techniques quasi-automatiques pour Thales Air Systems

De par leur nature, les techniques quasi-automatiques sont presque entièrement automatisées et répondent donc toutes à la première exigence énoncée en début de section.

Analyse de Concepts Certaines études [Siff 1999,Bhatti 2012] ont montré que l’analyse de concepts est une technique dont l’application sur de grands pro- jets reste difficile. Notamment, Siff et Reps [Siff 1999] mettent en évidence le fait que l’analyse de concepts peut produire beaucoup plus de résultats (plus de 13 000 concepts) que d’entrées fournies (189 objets et 32 attributs). L’analyse de concepts ne répond donc pas à l’exigence de passage à l’échelle (exigence (exiiii)) et n’est pas retenue comme technique applicable pour le

projet de Thales Air Systems.

Dominance Lundberg et Löwe ont montré que les techniques de dominance ne sont pas adaptées à la reconnaissance d’une architecture entière [Lundberg 2003]. Cela contredit autant l’exigence(exiiv)que l’exigence(exiiii), ainsi la domi-

nance n’est pas retenue pour le projet de l’entreprise.

Matrice de dépendances structurelles Bien que les matrices de dépendances struc- turelles puissent être calculées sur de grands logiciels, Ducasse et al. [Du- casse 2007] ont montré que l’exploitation de ces matrices sur de grands lo- giciels reste complexe. Ainsi cette technique souffre de difficulté de passage à l’échelle ce qui contredit l’exigence(exiiii). Cette technique n’est donc pas

adaptée au projet de Thales Air Systems.

Regroupement Le regroupement est une technique quasi-automatique ayant été appliquée sur des logiciels en se basant sur leurs informations statiques [Man- coridis 1998,Koschke 2000,Maqbool 2007,Garcia 2013], comme requis par l’exigence(exiii). Koschke a montré dans sa thèse de doctorat [Koschke 2000]

que le regroupement peut être appliqué dans le cadre de la reconnaissance d’une architecture à composants dans un logiciel avec une architecture dif- férente et sans bases de données (exigence (exiiv) et (exivi)). La possibi-

lité d’appliquer le regroupement sur de grands projets a été démontrée par des cas d’études sur des logiciels de plus d’une centaine de kLoC [Ko- schke 2000,Koschke 2003,Maqbool 2007]. Le regroupement respecte donc

3.4. Techniques retenues pour le projet de Thales Air Systems 33 l’exigence(exiiii). Finalement, cette technique respecte toutes les exigences

du projet de Thales Air Systems étudiées dans cette section. Koschke décrit une technique de regroupement qu’il a appliquée sur un projet présentant de fortes similitudes avec celui de Thales Air Systems (reconnaissance de com- posants dans un logiciel critique, embarqué, avec une architecture différente et développée en Ada 83). Cette technique a été retenue pour être appliquée sur le projet de l’entreprise, car ces similitudes laissent à penser que l’adap- tabilité de la technique sera assurée.

3.4

Techniques retenues pour le projet de Thales Air

Systems

La section précédente a permis de mettre en évidence trois techniques pouvant être appliquées sur le projet de Thales Air Systems afin d’automatiser la démarche d’évolution d’architecture décrite en Section2.2.3. La présente section détaille ces trois techniques (Reflexion Model, recherche d’information, regroupement)