Génie logiciel

Maintenance

Louis-Edouard LAFONTANT
 Couts des phases de développement logiciel

Maintenance
• Tout changement de n’importe quel artéfact du
logiciel une fois déployé
• Code source, tests, documents
• Maintenabilité doit être pensée dès le début
• Pour réduire l’effort, le temps et les coûts
• Ne doit pas être compromise par le processus
de développement
• Source majeure de revenu
• Certaines compagnies en font leur principal Maintenance
modèle d’affaire 67%

• Maintenance est un des aspects les plus difficiles de

la production de logiciel
• Incorpore tous les autres workflows Maintenance Test unitaire Test système Programmation
Design Exigences Spécifications
 Correctif

Types de Perfectif Maintenance Adaptif

changement

Préventif
Type de changements

➢ Perfectif (51%) : accroître la valeur du logiciel suite à des changements demandés par le client
❑ Ajouter des fonctionnalités
❑ Améliorer la performance
➢ Adaptatif (24%) : préserver la valeur du logiciel en répondant aux changements de l’env.
❑ Transférer vers un nouveau compilateur, OS, matériel
❑ Changement légal (ex: taux d’imposition), de norme (ex: nouvelle devise)
➢ Correctif (22%) : corriger les défauts restants
❑ Analyse, conception, implémentation, documentation, …
➢ Préventif (3%) : protège le logiciel en facilitant les changements futurs par anticipation
❑ Augmenter sa maintenabilité
❑ Invisible à l’utilisateur (changement interne, ex: refactoring)
 • De quels outils dispose le programmeur de
maintenance pour trouver la faute ?
• Le rapport de défauts produit par un utilisateur
• Le code source
• Et souvent, rien d’autre (la documentation ?)
Maintenance
• Il doit donc avoir des talents de débogage
corrective extraordinaires
• La faute peut être n’importe où dans le produit
• La cause de la faute peut être située dans une
exigence ou un document de conception
aujourd’hui inexistant
 Supposons qu’on a localisé la faute.
Comment la corriger sans (ré)introduire une faute?

• Comment minimiser les fautes de régression ?

• Consulter la documentation complète du produit
Problèmes de • Consulter la documentation détaillée de chaque
régression module
• Souvent, la documentation est inexistante, incomplète ou
erronée
• Il doit déduire du code même toute l’information pour
éviter d’introduire une faute de régression
 • Tester que les modifications fonctionnent correctement
• En utilisant des cas de test spécifiquement conçus
pour celles-ci

• Effectuer des tests de régression

• Ré-exécuter les test en utilisant les données de test
Vérification existantes

• Ajouter les nouveaux cas de test à ces données pour

qu’ils fassent parties de tests de régression futurs

• Documenter tous les changements

Assurer la
maintenance
Penser à la maintenance tout au
long du développement
Assurer la maintenance

• Maintenance n’est pas un effort ponctuel

• Il faut la planifier tout au long du cycle de vie du logiciel
• Workflow de conception : utiliser les techniques de dissimulation
d’information et d’implémentation
• Workflow d’implémentation : choisir des noms de variables qui facilite la
compréhension
• Documentation doit être complète, juste et refléter la version courante de
tous les artéfacts
• Ne pas compromettre la maintenabilité durant la maintenance
Problème de cible mobile

Solution apparente
• Geler les exigences une fois qu’elles ont été signées, jusqu’à la livraison du produit
• Après chaque requête de maintenance perfective, geler les exigences pendant
(disons) 3 mois ou 1 an
En pratique
• Le client peut ordonner des changements le lendemain
• Tant qu’il paye la facture, il peut faire des demandes de changement
quotidiennement
• Des changements fréquents ont un effet nocif sur la maintenabilité du produit
× Plus il sera difficile d’intégrer de nouveaux changements
× Moins la documentation est fiable
× Moins les tests de régression sont à jour
Maintenance et OO

Le paradigme OO facilite la maintenance

✓ Application composée d’unités indépendantes
✓ Encapsulation et Dissimulation
✓ Seul moyen de communication est via l’envoi de
messages
…mais il l’entrave aussi
× Trop grande hiérarchie d’héritage
× Conséquences du polymorphisme et de liaisons
dynamiques
× Fragilité de l’héritage. Modifier une superclasse
=> Toutes les sous-classes sont affectées
 Adapter le système à
Flux de maintenance de nouvelles exigences
post-déploiement
 Changement post-déploiement (étapes)

Exigences Analyse/Conception Implémentation Déploiement

Initiation Concepts Impact Réalisation Refactoring Conclusion

Vérification

Test

Interactions avec l’extérieur

Conception
Implémentation
Initiation
• Débute par une demande de changement
• Exigence du changement
• Priorisés par sévérité
• Programmeur décide d’implémenter le changement
• S’auto-assigne la demande ou assignée par le gestionnaire du projet
• Une fois le bogue assigné, le programmeur doit
• Identifier la cause
• Trouver une solution pour le corriger
• Trouver un moyen de contourner le problème
Logiciels de suivi
de défauts
 • L’utilisateur doit disposer d’un mécanisme pour rapporter
les défaut trouvés
Rapport de défauts • Doit inclure assez d’information pour permettre au
programmeur de maintenance de recréer le problème pour
l’investiguer
Déterminer le type de changement
• Incrémental : ajoute une nouvelle fonctionnalité (perfectif)
• Contraction : retire une fonctionnalité obsolète d’un logiciel
(perfectif)
• Permet de réduire la complexité du logiciel
• Remplacement : remplace une fonctionnalité existante par une autre
(adaptatif/correctif)
• ex: correction de bogue, amélioration de la performance
• Réusinage (refactoring) : substitue une structure par une autre sans
modifier le comportement observable (préventif)
• Permet de limiter la dégradation d’un logiciel due aux changements
Localisation
des concepts
But: identifier l’emplacement du
code qui doit subir des changements
Changements souvent formulés en
termes de concepts du domaine

Initiation Concepts Impact Réalisation Refactoring Conclusion

 • Concepts extraits de la requête de changement
• Repérés dans le code et deviennent le point de
départ pour les changements à effectuer
• On recherche:
Localisation des • L’extrait de code à changer
concepts • Le module où la fonctionnalité/correction
se situera
• La partie de la documentation qui décrit
ces concepts
 • Un très grand programme ne peut être
complètement compris
• Un programmeur
• Cherche à obtenir une compréhension
Compréhension minimale qui permet d’effectuer un
partielle du code changement
• Ne veut explorer une partie du code
que lorsque c’est nécessaire
• Cherche à comprendre comment les
concepts sont reflétés dans le code
Recherche textuelle dans du code inconnu

grep “payment” *.java

Recherche par dépendances
• Utilise la structure des classes pour guider la navigation et localiser un
concept
• Chaque classe joue un rôle dans le système, qui correspond à sa
responsabilité
• Principe de responsabilité unique en programmation OO
• Ex: la classe Item d’un système de POS est responsable des items
vendus par un commerce et leurs propriétés
• Nouveaux items, description des items, etc.
Graphe de
dépendances
• L’ensemble des dépendances entre les
classes forme un graphe dirigé
• Nœuds : classes
• Arcs : dépendances
• Associations
• Héritage (bidirectionnel dans le cas de
l’héritage polymorphique)
• Utilisations
• Autres dépendances possibles
Tranche de
fournisseurs
• Responsabilités locales : assumées par la
classe seule
• Responsabilités collectives / composites :
assumée par la tranche de fournisseurs
d’une classe
• Permet à la classe d’implémenter des
fonctionnalités qu’elle ne peut
assumer complètement seule
Recherche par dépendances
 Exemple

Requête de changement :
« Ajouter un auteur à chaque classe créée
dans un diagramme de classes »

• Concept : « auteur »
• Concept nouveau, n’apparaît pas dans le code
• Correspond à une propriété d’un nœud
Localiser les
propriétés
d’une classe
Classes à
inspecter
Fournisseur
le plus
probable
Prochaines
classes à
inspecter
Mauvais
choix...
 Retour en
arrière
(backtrack)
Concept
localisé
 Extensions
possible de
la recherche
 Autre
emplacement
trouvé
 Recherche textuelle vs. par dépendance

Recherche textuelle Graphe de dépendances

• Dépend des conventions de nommage • Utilise la structure des classes du
• Indépendant de la structure du programme
programme • Nécessite la compréhension des
• Applicable à des concepts explicites fonctionnalités locales et composites
seulement • Applicable aux concepts implicites et
explicites
 Analyse de l’impact
Souvent le changement n’est pas appliqué à un seul module, mais peut affecter
d’autres partie du logiciel
But : Déterminer la stratégie à utiliser et l’impact des changements à apporter

Initiation Concepts Impact Réalisation Refactoring Conclusion

Portée de l’impact
• Impact localisé : affecte au plus quelques modules étroitement liés
• Facile à réaliser, impact facile à prévoir
• Souvent une conséquence de l’organisation du code
(ex: classes faiblement couplées)
• Impact significatif : affecte un nombre élevé de modules
• Plus difficile à prévoir, requiert des outils et techniques plus avancés
• Impact massif : affecte la majorité des modules
• Coûteux et à haut risque  considérer le redéveloppement
• Un changement affecte aussi d’autres artéfacts que le code source
• Documentation, cahier des charges, etc.
 Statut des classes

Classe non-inspectée et qui n’apparaît pas dans la

Vide
liste de classes à inspecter.

Changée / Un programmeur a inspecté la classe et a déterminé

Impactée qu’elle était impactée par le changement.

Un programmeur a inspecté la classe et a déterminé

Non-impactée
qu’elle n’était pas impactée par le changement.

Suivante La classe apparaît dans la liste de classes à inspecter.

Algorithme d’analyse d’impact itérative
Ensemble
d’impact
initial
Inspecter les
voisins
 Non-
impacté, au
suivant
 Voisin
impacté,
ajout à
l’ensemble
Inspecter les
nouveaux
voisins
Non-impacté
 Impacté,
voisins déjà
traités
Pas d’impact
direct, mais
la propage
Nouveaux
voisins
Non-impacté
 Impacté,
ajout à
l’ensemble
Nouveaux
voisins
 Impacté,
ajout à
l’ensemble
 Non-
impacté,
analyse de
l’impacte
achevée
Outils pour
l’analyse d’impact
 Réalisation
Modification du code existant ou création de nouvelle fonctionnalité
Insérer nouveau code dans l’ancien code
Traverser les classes dépendantes et les mettre à jour

Initiation Concepts Impact Réalisation Refactoring Conclusion

Stratégie adoptée
• « Quick fix » : changement d’urgence
• Utilisé lorsque le logiciel n’est plus activement maintenu (service)

• Changement durable : toutes les autres situations

• Le coût d’un changement rapide est plus élevé à long terme que le bénéfice
qu’on en retire
• Il est préférable de bien exécuter un changement, de façon professionnelle
et réfléchie
Ajout de fonctionnalité
• Ajout de nouveau code qui interagit avec le code existant
• L’impact de l’ajout ou de modifications se répercute sur les classes voisines
• Propagation des changements
• Effet domino

• Petit changement : directement dans le code existant

• Ex: augmenter la taille d’un tableau

• Changement important : ajout de nouvelles classes

Exemple

Ajout de fonctionnalité locale Ajout d’une nouvelle classe

 • Peut aussi propager le changement

Retrait de • Toutes les références à la fonctionnalité retirée

fonctionnalité doivent aussi être retirées
• Les changements secondaires se propagent
obsolète à d’autres classes
 • L’analyse de l’impact prédit les classes qui
seront impactées

• La propagation de changements modifie le code

Propagation des des classes impactées
changements
• L’analyse d’impact peut surestimer ou sous-
estimer les changements à effectuer
• Conséquence de l’invisibilité du logiciel
• Rend la planification difficile
Réusinage
(Refactoring)
Modifie la structure du code sans
affecter la fonctionnalité

Initiation Concepts Impact Réalisation Refactoring Conclusion

 • Modifie la structure du code sans affecter la
fonctionnalité
• Activité importante lors de l’évolution
• Certains changements sont apportés afin de
Refactoring minimiser l’impact des changements
• Consiste en une séquence de
transformations qui préservent le
comportement
Catalogue de patrons de refactoring

if (isSpecialDeal()):
total = price * 0.95
send()
Refactoring else:
total = price * 0.98
send()

Refactoring
if (isSpecialDeal()):
total = price * 0.95
Refactoring else:
(patron de méthode) total = price * 0.98
send()

[Link]
 Vérification
Garantir que le changement est correct
Créer de nouveaux tests pour
le nouveau code
Re-tester le code existant
 • Après un changement, le programmeur re-teste
le code
• Rétablit la confiance que les fonctionnalités
antérieures fonctionnent toujours
• Changement peut avoir introduit par
inadvertance des problèmes dans des parties
Test de non-modifiées
• Cas de test antérieurs font partie du test de
régression régression
• La suite de tests augmente
• Souvent effectués durant la nuit

• Préserver toutes les suites de test après le

déploiement !
 Conclusion

• Soumettre le code complété et vérifié dans le système de contrôle de

révisions
• Créer une nouvelle révision ou un tag

• Changer le statut de la demande de changement à complété

• Écrire un prologue qui commente les changements effectués

• Redéploiement et livraison ?

Initiation Concepts Impact Réalisation Refactoring Conclusion