LOG240 chapitre 1

• Objectif : Améliorer la maintenance des logiciels.
• La présentation porte sur la compréhension du logiciel, chapitre 3, présentée par Dr. Alain April à Montréal, le 11 septembre 2016.

Sujets du Chapitre 3

• Rôle de la compréhension d'un logiciel.
• Objectifs de la compréhension du logiciel.
• Besoins de compréhension du mainteneur.
• Exploration des modèles de compréhension et leur utilisation.
• Le modèle mental.
• Stratégies de compréhension et leurs différences.
• Techniques de lectures.
• Facteurs ayant un impact sur la compréhension.

La Compréhension du Logiciel

• Essentielle pour la maintenance.
• La compréhension d'un logiciel prend du temps et n'est pas instantanée.
• La compréhension d'un grand logiciel peut être impossible en totalité.

Situation

• Un nouveau "code base" est abordé.
• L'effort de maintenance décroît après le développement initial.

Objectifs de la Compréhension

• Comprendre le domaine d'affaire du point de vue de l'utilisateur.
• Comprendre le changement demandé.
• Comprendre l'état actuel du logiciel.
• Anticiper les changements futurs.
• Comprendre les spécificités des composants du logiciel.
• Développer un modèle mental du fonctionnement du logiciel à modifier.
• Le rôle du génie logiciel est de s'assurer qu'un logiciel fonctionne et qu'il soit de qualité.
• La complexité du logiciel est également un facteur déterminant dans la compréhension.

Perspectives de la Connaissance

• Connaissance du domaine d'affaire : supporte l'estimation et guide les choix d'algorithmes, méthodes, outils et personnel.
• Effet de l'exécution : confirme la réflexion du changement sur le comportement désiré.
• Relation cause à effet : précise la portée du changement et prédit les effets secondaires.
• Réaction logiciel/environnement technique : évalue l'impact d'un changement logiciel sur sa qualité opérationnelle.
• Support à la décision : appuie les processus techniques et de gestion pour les décisions.

Les Besoins d'information

• Plusieurs personnes doivent connaître le logiciel à différents niveaux.
• Le gestionnaire en maintenance, les analystes, concepteurs, et programmeurs.

Le Modèle Mental

• Le mainteneur développe un modèle mental du logiciel durant l'apprentissage.
• Un modèle mental accélère un raisonnement correct.
• Il permet de prédire plus facilement ce qui se passe au cours de certaines actions.
• Le modèle mental est constamment évolué.
• La Taxonomie de Bloom
• Plus votre pyramide d'analyse des activités est grande, meilleur est votre apprentissage.

Stratégies de Compréhension

• Approche descendante.
• Approche ascendante.
• Approche opportuniste.
• Ces approches aident le mainteneur à se former un modèle mental d'un logiciel.

Approche Descendante

• Le mainteneur commence par les éléments de haut niveau qui décrivent le logiciel.
• Par exemple, ce qui se passe quand on exécute une requête.
• La compréhension des détails se fait ensuite : structures de données, flux de traitement, lectures/écritures à la base de données.
• Cette approche utilise des balises.
• Des exemples de balises internes du programme sont : commentaires, noms de variables, déclarations, indentation.
• Des exemples de balises externes au programme sont : manuel, d'exigences, d'architecture, représentations graphiques, imprimés/algorithmes de références.
• C'est une approche itérative.
• On fait des hypothèses de haut niveau avec l'aide de balises ; les hypothèses sont confirmées et raffinées progressivement.

Approche Ascendante

• C'est une approche itérative.
• Le programmeur reconnaît les patrons dans le programme.
• À chaque itération, ces patrons sont regroupés afin de fournir un modèle de plus plus haut niveau.

Approche Opportuniste

• Approche itérative, combinant les approches descendantes et ascendantes.
• Fréquemment utilisée en pratique.
• Le mainteneur a souvent déjà une base de connaissances.

Techniques de Lecture

• Définir un but.
• Petits logiciels: du début vers la fin.
• Grands logiciels : par composants.
• Faire des dessins.
• Prendre des notes.
• Exécuter avec un traceur.

Diviser pour Régner (Technique de Lecture)

1. Diviser le code en groupes liés.
2. Se concentrer sur un groupe.
3. Comprendre comment les éléments interagissent les uns avec les autres.

Exercice

• Former des équipes de 5 ou 6 personnes.
• Développer une stratégie en quatre étapes pour apprendre rapidement le fonctionnement et la structure d'une application.
• Identifier le niveau taxonomique de Bloom employé à chaque étape.
• Afin de mieux comprendre le code, il peut être restructuré ou réusiné (refactoring) pour le simplifier sans modifier son comportement externe.
• Il existe aussi des outils de détection de "code smells" qui peuvent aider à identifier des problèmes potentiels dans le code.
• SonarQube : https://www.sonarqube.org/
• PDM : https://pmd.github.io/
• CheckStyle : http://checkstyle.sourceforge.net/
• jDeodorant : https://github.com/tsantalis/JDeodorant

Facteurs de compréhension

• Domaine : problème, application et système.
• Programmation : décomposition, granularité et dissimulation de l'information.
• Documentation : externe et interne.
• Organisation/Présentation : indentation, espacements et patron.
• Outils : statiques et dynamiques.

Points Importants pour la Programmation

• Utiliser des conventions de noms claires (10 à 16 caractères).
• Utiliser des abréviations connues (dictionnaire).
• Éviter les synonymes, les chiffres et le mélange de langues.
• Préférer un même nom pour les concepts répétitifs.
• Utiliser des abréviations signifiantes pour les boucles (i,j,k à l'intérieur ; descriptifs à l'extérieur).
• Clarifier les variables d'états (if flag=0, vs if punctuation = '.').
• Utiliser des booléens explicites (erreur='true').
• Éviter les "Magic Numbers".
• Consulter les conventions de noms établies.

Bonnes Pratiques

• Se concentrer sur son métier et intérêts.
• Consulter les ressources suivantes :
• Livre "Clean Code" de Robert C. Martin.
• Ressources "Tout sur le code" de Steve McConnell.
• Site web de Microsoft (Rob Caron).
• Présentation de Patrick Guio.

Complexité

• Si le code d'un collègue semble trop complexe, il faut simplifier ce code.
• Valider les valeurs McCabe.
• Utiliser son jugement et plus d'une mesure !

Documentation

• Externe : cas de tests, documents d'exigences, plans de tests, modèles de données, spécifications de composants.
• Interne : commentaires, code source.

Commentaires

• Utiliser Javadoc avant class, field et method.
• Suivre les bonnes pratiques pour les commentaires:
  • Répétition du code.
  • Explication du code.
  • Marquage du code.
  • Description de l'intention du code.
  • Information générale.
  • Indenter le code avec la structure.

Organisation et Mise en Page

• Utiliser des niveaux de logique de codage / patrons.
• Identer le code (avec une norme ou un outil spécifique).
• Établir une norme pour les longueurs de ligne (exemple).

Résumé du Chapitre 3

• Les objectifs de la compréhension ont été énumérés.
• Les perspectives des connaissances requises sont posées.
• Les modèles et stratégies de compréhension sont comparées.
• Les techniques de lecture d'un logiciel sont données.
• Présentation des principaux facteurs d'impact sur la compréhension.
• Les lois de Lehman indiquent que les logiciels doivent constamment être modifiés et mis à jour et que la complexité croissante est une réalité à gérer.
• La rétro-ingénierie permet d'analyser un programme sans les spécifications originales, afin de comprendre son fonctionnement interne et d'identifier ses composants.
• Des outils de rétro-ingénierie comme X-Ray, DA4Java et CodeCity existent.
• La rétro-ingénierie ne modifie ni ne crée de système, mais permet d'examiner et de comprendre le système actuel.
• Les coûts de maintenance continuent d'augmenter et peuvent représenter entre 50% et 75% des coûts globaux de développement logiciel.
• Jusqu'à 60% des efforts de maintenance sont consacrés à la compréhension du logiciel existant.
• Catalogue de restructuration de Martin Fowler : https://www.refactoring.com/
• Les logiciels existants sont fréquemment modifiés de manière ad hoc en raison du manque de temps et de ressources.
• Une bonne conception initiale n'est pas toujours maintenue, conduisant à du code spaghetti et des dépendances non gérées.
• La documentation n'est pas toujours mise à jour, et les développeurs originaux peuvent quitter l'entreprise avec leurs connaissances.