Description du contrôleur de robot original

Description du contrôleur de robot original

Implémentation actuelle du cadre de raisonnement de modificabilité

En plus du cadre de raisonnement de performance, ArchE 3.0 est livré avec un cadre de raisonnement de modificabilité. Ce dernier est intéressant, car il possède la capacité de suggérer et d’appliquer automatiquement des tactiques de modificabilité. Même si les tactiques sont différentes, il est tout de même possible d’en étudier le fonctionnement. Cette section examine donc le processus utilisé par le RF de modificabilité pour suggérer et appliquer automatiquement des tactiques. Il est ainsi possible d’en sortir les forces et les défis pour ainsi avoir une base intéressante pour intégrer les tactiques dans le cadre de raisonnement de performance.
Le diagramme de séquence suivant résume l’implémentation du cadre de raisonnement de modificabilité. Puisque ce qui nous intéresse est le processus d’utilisation des tactiques, les détails de l’implémentation de l’analyse de modificabilité ont été omis afin d’alléger le diagramme. La méthode checkRFDependencies n’effectue aucun traitement spécifique pour la gestion des tactiques. Tout comme la méthode dans le cadre de raisonnement de performance, elle vérifie les paramètres et les liens contenus dans l’architecture.
Les méthodes doInterpretation et doEvalutation sont utilisées pour effectuer l’analyse. L’interprétation initialise l’analyseur, alors que l’évaluation va effectuer et retourner le résultat de l’analyse. Si les résultats de l’analyse font en sorte qu’un scénario n’est pas satisfait, la méthode suggestTacticsBasedOnAnalysis est appelée. Cette méthode interne du cadre de raisonnement utilise une série de conditions où chacune utilise un résolveur différent. Chacun de ces résolveurs est une classe séparée du cadre de raisonnement et n’a qu’une seule fonction : vérifier si une tactique s’applique au système. Si elle s’applique, une suggestion de tactique sera retournée à ArchE. Il peut y avoir zéro, une ou plusieurs suggestions de tactiques retournées à ArchE.
Les méthodes applySuggestedTactic et applyTacticByUserQuestion sont pratiquement identiques dans leur forme et leur fonction. La seule différence vient du fait que applyTacticByUserQuestion va chercher les réponses de l’utilisateur dans la question, alors que applySuggestedTactic va utiliser des valeurs par défaut inscrites dans le cadre de raisonnement. Ces deux méthodes vont utiliser des objets internes (privés) au cadre de raisonnement en utilisant le patron « commande ». La commande est initialisée avec les paramètres de la tactique ainsi qu’avec les informations fournies par l’utilisateur (applyTaticByUserQuestion) ou avec les informations par défaut (applySuggestedTactic). Dans les deux cas, la commande s’exécutera de la même manière en utilisant des données provenant des différentes sources.
Pour terminer, la méthode describeTactic retourne une question décrivant la tactique. ArchE appelle cette méthode pour chacune des tactiques proposées par le cadre de raisonnement. Pour retourner la bonne question, une séquence de conditions vérifie de quel type de tactique il s’agit et retourne la question appropriée. Les questions contiennent plusieurs informations. Il y a le type de question dont il s’agit (pour obtenir le texte contenu dans le fichier de questions), la tactique à laquelle la question réfère (pour l’application par l’utilisateur) et des paramètres définis par le concepteur du cadre de raisonnement (soit pour remplacer des variables dans le texte de la question, soit pour l’application de la tactique).

 Problèmes de l’implémentation actuelle

En analysant la gestion des tactiques du cadre de raisonnement de modificabilité, plusieurs points problématiques ont été repérés. Cette section examine ces points afin d’y remédier ou de les éviter afin de développer une meilleure stratégie pour gérer les tactiques dans le cadre de raisonnement de performance.L’aspect le plus problématique vient du couplage très élevé entre l’exécution du cadre de raisonnement et les tactiques. En effet, la classe correspondant au cadre de raisonnement devrait s’occuper uniquement de l’exécution des commandes provenant d’ArchE et reléguer les tâches d’analyse connexe à d’autres modules. Cette approche est déjà suivie pour l’analyse (avec la classe ChangeImpactAnalyser). Par contre, le code servant à gérer les tactiques se retrouve en majorité dans la classe du cadre de raisonnement.En effet, la suggestion des tactiques se fait dans une méthode privée du cadre de raisonnement. Même si cette méthode utilise des résolveurs externes au cadre de raisonnement, il reste tout de même une longue série de conditions vérifiant chacun des résolveurs. Il y a un point positif avec la séparation des résolveurs pour déterminer si une tactique s’applique au système : l’utilisation d’une interface commune. Cette interface pourrait faire abstraction des détails de l’implémentation des résolveurs, mais ce n’est pas le cas dans cette implémentation. En effet, le cadre de raisonnement doit créer lui-même chacun des résolveurs implémentant cette interface. Ceci fait en sorte qu’il a un lien direct avec chacun d’eux, alors qu’il ne devrait pas les connaître. Il faudrait isoler les résolveurs correctement (ex. : dans chacune des tactiques).Contrairement à la suggestion des tactiques, les deux méthodes d’application vont utiliser des classes internes (privées) au cadre de raisonnement pour effectuer leurs opérations. Cependant, le reste est similaire. Il y a une série de conditions, exécutées dans le cadre de raisonnement, vérifiant chaque type de tactique pour déterminer la bonne commande à exécuter. De plus, le code des deux méthodes d’application est pratiquement une copie conforme. Cette duplication pose un défi de maintenance du code, car une modification faite dans une des méthodes doit absolument être faite dans l’autre, sinon il pourrait y avoir des conflits. La description des tactiques est aussi problématique. Premièrement, il s’agit encore d’une série de conditions vérifiant chacune le type de la tactique décrite. De plus, la description est elle aussi faite dans le cadre de raisonnement. Extraire cette information et la conserver dans un module de tactiques externe permettrait d’augmenter la cohésion du cadre de raisonnement.
Tous ces points, en plus de réduire la cohésion du cadre de raisonnement en incluant d’autres tâches, font que des modifications aux tactiques vont aussi toucher au cadre de raisonnement. La nouvelle implémentation devrait mieux isoler les tactiques du cadre de raisonnement. Cela permettrait de faciliter l’ajout et la modification de tactiques.En résumé, l’implémentation de chaque tactique devrait être mieux encapsulée. Cette encapsulation permettrait d’extraire toutes les informations concernant les tactiques (recherche, application et description) du cadre de raisonnement et de les contenir dans des objets représentants des tactiques.

 Implémentation proposée des tactiques dans le cadre de raisonnement de performance

L’analyse des cadres de raisonnement effectuée dans les deux dernières sections permet de développer une solution pour l’intégration des tactiques dans le cadre de raisonnement de performance. Cette section décrit l’implémentation choisie et comment celle-ci règle les problèmes énoncés précédemment. La description se limite à l’aspect technique de l’implémentation et ne touche pas à l’implémentation des tactiques de performance. Le développement d’une solution automatisée pour les tactiques de performance dans ArchE est décrit dans le troisième chapitre.Le diagramme de classes suivant résume les différentes interactions entre les composantes actuelles du cadre de raisonnement et des nouvelles composantes ajoutées pour les tactiques. Il ne s’agit pas d’un diagramme UML strict, car il y a des composantes de type « méthode » qui correspondent aux méthodes de l’interface d’ArchE. Ces méthodes sont incluses afin de faciliter la compréhension de l’utilisation des classes puisqu’elles contiennent l’appel que chacune de ces méthodes doit faire. De plus, deux exemples de tactiques de performance sont inclus, sans plus de détails, afin de montrer l’utilisation des objets.

Table des matières

INTRODUCTION
CHAPITRE 1 REVUE DE LA LITTÉRATURE
1.1 Architecture logicielle
1.1.1 L’architecture logicielle selon le SEI
1.1.2 Méthode ADD
1.1.3 Difficultés de la conception des architectures logicielles
1.2 ArchE
1.3 Cadres de raisonnement
1.4 Cadre de raisonnement de performance
1.4.1 Type d’analyse
1.4.2 Traduction ArchE vers Lambda-WBA
1.4.3 Traduction Lambda-WBA vers MAST
1.4.4 Analyse RMA
1.5 Tactiques architecturales
1.6 Conclusion
CHAPITRE 2 ANALYSE ET MODIFICATION DES CADRES DE RAISONNEMENT
2.1 Description d’un cadre de raisonnement dans ArchE
2.1.1 Fonctionnalités de base d’un cadre de raisonnement dans ArchE
2.1.2 Interface des cadres de raisonnement
2.1.3 Configurations et paramètres des cadres de raisonnement
2.1.4 Utilisation d’un cadre de raisonnement par ArchE
2.2 Implémentation actuelle du cadre de raisonnement de performance
2.2.1 Parties manquantes au cadre de raisonnement de performance pour l’application des tactiques
2.3 Implémentation actuelle du cadre de raisonnement de modificabilité
2.3.1 Problèmes de l’implémentation actuelle
2.4 Implémentation proposée des tactiques dans le cadre de raisonnement de performance
2.5 Autres modifications nécessaires au cadre de raisonnement
2.5.1 Ajout du paramètre de priorité
2.5.2 Ajout des questions
2.6 Conclusion
CHAPITRE 3 TACTIQUES AJOUTÉES
3.1 Augmenter les ressources disponibles
3.1.1 Description
3.1.2 Analyse
3.1.3 Application de la tactique
3.1.4 Exemples et validation de la tactique
3.2 Réduire le temps d’exécution d’une responsabilité
3.2.1 Description
3.2.2 Analyse
3.2.3 Choix des responsabilités
3.2.4 Application de la tactique
3.2.5 Exemples et validation de la tactique
3.3 Augmenter la période d’un scénario
3.3.1 Description
3.3.2 Analyse
3.3.3 Définition des types de scénario
3.3.4 Types de scénarios qui ont une influence
3.3.5 Estimation de la nouvelle période
3.3.6 Déterminer les scénarios d’intérêts
3.3.7 Application de la tactique
3.3.8 Exemples et validation de la tactique
3.4 Augmenter la priorité d’une responsabilité
3.4.1 Description
3.4.2 Analyse
3.4.3 Déterminer la priorité plus élevée
3.4.4 Responsabilités affectées
3.4.5 Application de la tactique
3.4.6 Exemples et validation de la tactique
3.5 Tactiques non implémentées
3.5.1 Réduire les calculs supplémentaires lors du traitement d’une opération (« Reduce Computational Overhead »)
3.5.2 Introduire le parallélisme (« Introduce Concurrency »)
3.5.3 Conserver plusieurs copies (« Maintain Multiple Copies »)
3.6 Conclusion
CHAPITRE 4 VALIDATION ET RÉSULTATS
4.1 Tests individuels
4.2 Tests de système
4.2.1 Description du contrôleur de robot original
4.2.2 Modifications du système
4.2.3 Définition du contrôleur de robot dans ArchE
4.2.4 Utilisation d’ArchE pour résoudre le problème
4.2.5 Résultats
4.3 Conclusion
5 CONCLUSION
RECOMMANDATIONS
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES

Télécharger le rapport complet