docEvolution, Maintenance et Réutilisation des logiciels, aka: E/M/R.
download 
Plainte Transcription
Evolution, Maintenance et Réutilisation des logiciels, aka: E/M/R.
Evolution, Maintenance et Réutilisation des logiciels, aka: E/M/R. Olivier Inizan - Bureau PEPI IDL - INRA - GAP - URGI La Londes Les Maures, 5-9 décembre 2011 Objectifs de la session Dans votre expérience quotidienne: identifier les éléments qui permettent d’assurer l’E/M/R des logiciels. E/M/R - Définitons I Evolution: à partir d’un système existant, augmenter le comportement du système. Métaphore du contrat. intégrer de nouvelles clauses. I Maintenance: conserver le comportement du système. Toujours la métaphore du contrat, les clauses ne sont pas respectées. I Réutilisation: d’un système à un autre système, être en mesure de reprendre ”qqch”. Se positionner par rapport aux autres métiers de l’ingénieur I L’E/M/R n’est pas la chasse gardée de l’ingénierie logicielle. I L’idée ici est de regarder ces notions dans d’autres métiers de l’ingénieur. I Pour tout produit manufacturé (une automobile, un viaduc, un smartphone) comment décriveriez vous ces notions ? I Maintenance: réparation. / Evolution: création d’un nouveau produit. / Réutilisation: plans et pièces ... Software v.s Hardware I I Est ce que l’industrie du software présente des spécificités par rapport à ces notions ? Caractéristiques du software: I I I ”soft”: ce qui est modifiable sur une base matérielle. discipline relativement jeune par rapport aux autres métiers de l’ingénierie. Est ce que ces caractérisitiques nous permettent d’avoir une idée plus précise des notions d’E/M/R pour notre discipline ? Le problème I L’aspect ”souple” du soft le rend plus accessible aux changements. I Il est, en théorie, plus ”facile” de maintenir et de faire évoluer un logiciel qu’un autre produit. I La discipline est ”jeune” et bénéficie d’un historique faible: moins de capitalisation. I Deux rythmes se téléscopent: le rythme rapide de l’évolution et de la maintenance, le rythme ”lent” de la capitalisation. Eléments A partir de ce problème il s’agit d’identifier dans l’ingénierie logicielle les éléments qui solutionnent l’E/M/R: I En quoi la conception influence l’E/M/R ? I Est ce que le choix d’un langage informatique a un impact sur l’E/M/R ? I Le cycle de développement logiciel: existe-t-il des cycles plus adaptés à l’E/M/R ? I Comment positionner le test et la production de code par rapport à l’E/M/R ? En quoi la conception influence l’E/M/R ? Eléments de conception I ”Ce qui se conçoit bien s’énonce clairement”. I Un logiciel ”bien” conçu doit être facilement maintenable et réutilisable. I Qu’est ce qu’un logiciel bien conçu lorsque ”fondamentalement c’est du 0/1”. I Comment ”bien” concevoir pour une machine ? La réponse par les approches I I De l’approche procédurale à l’approche objet. Pierre-Alain Muller: ”Modélisation Objet avec UML.” I I Petit exercice: modéliser un même exemple avec une approche procédurale et une approche objet. Quel sont nos schémas de pensée ? Sont-ils compatibles avec la représentation des données en machine ? L’approche objet est-elle suffisante ? I L’approche objet est-elle suffisante pour produire un logiciel ”plus” adapté aux E/M/R ? I Les ”piliers” de la conception objet sont une première réponse. Ex: l’héritage favorise la réutilisation. I Aller plus en avant: les ”design patterns”, les principes de conception. Design Patterns I ”Gang of four”: formaliser des solutions génériques à des problèmes récurrents. I Exemple: une seule instance pour une classe, le pattern singleton. I Exemple: un objet se comporte comme une valeur, le pattern value object. Les principes orientés objet, POO I I Récoltés et formalisés par Robert C. Martin, ’Uncle Bob”. Exemple. Open close principle: un code doit être ouvert aux évolutions mais fermé aux modifications: I I Exemple: principe de substitution de Liskov. I I Tout ajout au système doit au minimum ”casser” l’existant. Dans un hierarchie d’héritage il doit être possible de remplacer les objets les moins spécialisés par les objets les plus spécialisés. Les patterns sont une abstraction, les principes sont l’abstraction de l’abstraction: plusieurs patterns ”implémentent” le même principe. Patterns et Principes: les dérives I Ticket d’entrée d’entré élevé. I De l’esthétique dans le code. I Une première tendance, abuser de l’esthétique: la ”pattern-ite”. I Une seconde tendance, l’élitisme: ”software craftmanship”. Est ce que le choix d’un langage informatique a un impact sur l’E/M/R ? Langages I Les langages informatiques ne sont pas égaux devant l’E/M/R. I Exemple: d’expérience une modification est plus facile à impacter sur un code python que sur un code C++. I Pourquoi ? compilé v.s. interprété / syntaxe / ticket d’entrée / connaissance du langage / ... I Tendance pour l’E/M: s’orienter vers des langages qui remplissent les critères ci-dessus. Les limites de la tendance I Limite 1: interprété plutôt que compilé: coût en performance. I Limite 2: d’un langage à l’autre les piliers de la conception objet sont plus ou moins ”respectés”: I En python pas de notion d’encapsulation, pas d’interfaces: impact sur la modélisation. Une seconde tendance I I Appréhender le cycle de vie d’un code. Un code héberge des parties stables et des parties variables: I I Stable = code peu modifié, ancien, aux interfaces clairement définies. Variable = code souvent modifié, récent, aux interfaces pas clairement définies. I Dynamique du cycle: d’un code variable vers un code stable. I La performance arrive généralement en second dans le cycle. Un début de solution I Le code stable (design éprouvé + performance) peut être écrit avec un langage à typage fort. I Le code variable (design incomplet) peut être écrit avec un langage à typage faible. Existe-t-il des cycles de développement plus adaptés à l’E/M/R ? Cycle de développement I 1970, crise du logiciel: de plus en plus de bugs, de la nécessité de formaliser le cycle. I Un premier pas: cycle en V, cycle en cascade. I Cycle courts, notion d’itérations: RAD. I 2000 Kent Beck: ”Embrace change”. Agile Manifesto. I 2005 SCRUM Cycle en V I La phase de décision (spécifications) ne communique pas du tout avec la phase de réalisation. I Effet ”tunnel”: toutes les spécifications sont arrêtées à un moment. I Difficile de revenir sur les spécifications un fois que le développement a débuté. I Or, en phase de développement, des problèmes de périmètre se posent. Itérations I Découper en petits cycles en V la construction du logiciel: diffuser la phase de spécifications tout au long du cycle. I Adaptation au changement I: ne pas limiter les décisions dans le temps. I Adaptation au changement II: profiter du logiciel déjà produit pour ajuster les décisions, le feedback. Le prix à payer I Avec des spécifications fréquentes, un formalisme imposant comme le cahier des charges n’est plus envisageable. I I User Stories, Features. Implication forte du ”client”. I Product Owner. (PO) I Ingénierie incrémentale: tout le système n’est pas imaginé au début. I Etre en mesure à chaque itération de produire un logiciel opérationel (mode dégradé). I Construire une architecture qui s’adapte au changement. I Gestion technique et gestion de projet à revoir. En quoi la production de tests peut influencer l’E/M/R ? Un détour par la production de code I Différentes ”façons” de produire du code. I A partir d’un modèle. I A partir d’un modèle et de façon automatique (MDA). I A partir des tests: TDD. La non régression: le retour immédiat sur l’investissement I Assurer que le contrat est rempli suite à une modification du code. I Une pratique pour assurer la non régression: le test fonctionnel (TF). I TF: à chaque item décrit dans les spécifications correspond un test. I Une pratique un peu extrême: les spécifications par les tests, BDD. I Systématiser l’écriture d’un TF lors de la spécification avec le client. I Spécification et test ne font plus qu’un: bı̂nomage ? Le TDD et le test first I I Le TDD, 3 étapes: coder le test, l’implémentation et se soucier du design (refactoring). D’expérience du TDD au test first: I 2 étapes: coder le test puis l’implémentation. I Mécaniquement la non régression est assurée, mais à un niveau plus fin que le TF: aide au diagnostic. I Existe - t - il d’autres partiques qui assurent une non regression à ce niveau ? C.f. cours tests. A vous de jouer ! 3 groupes I Faire un retour d’expérience en se basant sur les éléments listés. I Les relations entre personnes: un élement pour l’E/M/R ? I Sensibiliser votre hiérarchie à l’E/M/R.
