Evolution, Maintenance et Réutilisation des logiciels, aka: E/M/R.

Transcription

1 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

2 Objectifs de la session Dans votre expérience quotidienne: identifier les éléments qui permettent d assurer l E/M/R des logiciels.

3 E/M/R - Définitons Evolution: à partir d un système existant, augmenter le comportement du système. Métaphore du contrat. intégrer de nouvelles clauses. Maintenance: conserver le comportement du système. Toujours la métaphore du contrat, les clauses ne sont pas respectées. Réutilisation: d un système à un autre système, être en mesure de reprendre qqch.

4 Se positionner par rapport aux autres métiers de l ingénieur L E/M/R n est pas la chasse gardée de l ingénierie logicielle. L idée ici est de regarder ces notions dans d autres métiers de l ingénieur. Pour tout produit manufacturé (une automobile, un viaduc, un smartphone) comment décriveriez vous ces notions? Maintenance: réparation. / Evolution: création d un nouveau produit. / Réutilisation: plans et pièces...

5 Software v.s Hardware Est ce que l industrie du software présente des spécificités par rapport à ces notions? Caractéristiques du software: 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?

6 Le problème L aspect souple du soft le rend plus accessible aux changements. Il est, en théorie, plus facile de maintenir et de faire évoluer un logiciel qu un autre produit. La discipline est jeune et bénéficie d un historique faible: moins de capitalisation. Deux rythmes se téléscopent: le rythme rapide de l évolution et de la maintenance, le rythme lent de la capitalisation.

7 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: En quoi la conception influence l E/M/R? Est ce que le choix d un langage informatique a un impact sur l E/M/R? Le cycle de développement logiciel: existe-t-il des cycles plus adaptés à l E/M/R? Comment positionner le test et la production de code par rapport à l E/M/R?

8 En quoi la conception influence l E/M/R?

9 Eléments de conception Ce qui se conçoit bien s énonce clairement. Un logiciel bien conçu doit être facilement maintenable et réutilisable. Qu est ce qu un logiciel bien conçu lorsque fondamentalement c est du 0/1. Comment bien concevoir pour une machine?

10 La réponse par les approches De l approche procédurale à l approche objet. Pierre-Alain Muller: Modélisation Objet avec UML. 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?

11 L approche objet est-elle suffisante? L approche objet est-elle suffisante pour produire un logiciel plus adapté aux E/M/R? Les piliers de la conception objet sont une première réponse. Ex: l héritage favorise la réutilisation. Aller plus en avant: les design patterns, les principes de conception.

12 Design Patterns Gang of four : formaliser des solutions génériques à des problèmes récurrents. Exemple: une seule instance pour une classe, le pattern singleton. Exemple: un objet se comporte comme une valeur, le pattern value object.

13 Les principes orientés objet, POO 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: Tout ajout au système doit au minimum casser l existant. Exemple: principe de substitution de Liskov. 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.

14 Patterns et Principes: les dérives Ticket d entrée d entré élevé. De l esthétique dans le code. Une première tendance, abuser de l esthétique: la pattern-ite. Une seconde tendance, l élitisme: software craftmanship.

15 Est ce que le choix d un langage informatique a un impact sur l E/M/R?

16 Langages Les langages informatiques ne sont pas égaux devant l E/M/R. Exemple: d expérience une modification est plus facile à impacter sur un code python que sur un code C++. Pourquoi? compilé v.s. interprété / syntaxe / ticket d entrée / connaissance du langage /... Tendance pour l E/M: s orienter vers des langages qui remplissent les critères ci-dessus.

17 Les limites de la tendance Limite 1: interprété plutôt que compilé: coût en performance. Limite 2: d un langage à l autre les piliers de la conception objet sont plus ou moins respectés : En python pas de notion d encapsulation, pas d interfaces: impact sur la modélisation.

18 Une seconde tendance Appréhender le cycle de vie d un code. Un code héberge des parties stables et des parties variables: Stable = code peu modifié, ancien, aux interfaces clairement définies. Variable = code souvent modifié, récent, aux interfaces pas clairement définies. Dynamique du cycle: d un code variable vers un code stable. La performance arrive généralement en second dans le cycle.

19 Un début de solution Le code stable (design éprouvé + performance) peut être écrit avec un langage à typage fort. Le code variable (design incomplet) peut être écrit avec un langage à typage faible.

20 Existe-t-il des cycles de développement plus adaptés à l E/M/R?

21 Cycle de développement 1970, crise du logiciel: de plus en plus de bugs, de la nécessité de formaliser le cycle. Un premier pas: cycle en V, cycle en cascade. Cycle courts, notion d itérations: RAD Kent Beck: Embrace change. Agile Manifesto SCRUM

22 Cycle en V La phase de décision (spécifications) ne communique pas du tout avec la phase de réalisation. Effet tunnel : toutes les spécifications sont arrêtées à un moment. Difficile de revenir sur les spécifications un fois que le développement a débuté. Or, en phase de développement, des problèmes de périmètre se posent.

23 Itérations Découper en petits cycles en V la construction du logiciel: diffuser la phase de spécifications tout au long du cycle. Adaptation au changement I: ne pas limiter les décisions dans le temps. Adaptation au changement II: profiter du logiciel déjà produit pour ajuster les décisions, le feedback.

24 Le prix à payer Avec des spécifications fréquentes, un formalisme imposant comme le cahier des charges n est plus envisageable. User Stories, Features. Implication forte du client. Product Owner. (PO) Ingénierie incrémentale: tout le système n est pas imaginé au début. Etre en mesure à chaque itération de produire un logiciel opérationel (mode dégradé). Construire une architecture qui s adapte au changement. Gestion technique et gestion de projet à revoir.

25 En quoi la production de tests peut influencer l E/M/R?

26 Un détour par la production de code Différentes façons de produire du code. A partir d un modèle. A partir d un modèle et de façon automatique (MDA). A partir des tests: TDD.

27 La non régression: le retour immédiat sur l investissement Assurer que le contrat est rempli suite à une modification du code. Une pratique pour assurer la non régression: le test fonctionnel (TF). TF: à chaque item décrit dans les spécifications correspond un test. Une pratique un peu extrême: les spécifications par les tests, BDD. Systématiser l écriture d un TF lors de la spécification avec le client. Spécification et test ne font plus qu un: bînomage?

28 Le TDD et le test first Le TDD, 3 étapes: coder le test, l implémentation et se soucier du design (refactoring). D expérience du TDD au test first: 2 étapes: coder le test puis l implémentation. Mécaniquement la non régression est assurée, mais à un niveau plus fin que le TF: aide au diagnostic. Existe - t - il d autres partiques qui assurent une non regression à ce niveau? C.f. cours tests.

29 A vous de jouer! 3 groupes Faire un retour d expérience en se basant sur les éléments listés. Les relations entre personnes: un élement pour l E/M/R? Sensibiliser votre hiérarchie à l E/M/R.