1 / 172

Modélisation et Génie logiciel

Modélisation et Génie logiciel. 4 TC Frédérique Laforest, Frédéric Le Mouël. Objectifs du cours. Connaître les principes du génie logiciel et leurs intérêts, connaitre les outils du génie logiciel Connaître les principes objet

Download Presentation

Modélisation et Génie logiciel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Modélisation et Génie logiciel 4 TC Frédérique Laforest, Frédéric Le Mouël Frédérique Laforest, Télécommunications, Services & Usages

  2. Objectifs du cours • Connaître les principes du génie logiciel et leurs intérêts, connaitre les outils du génie logiciel • Connaître les principes objet • Savoir lire et mener une conception de système d’information avec les modèles d’UML • Connaître les principes des Design Patterns, leur intérêt ainsi que les plus reconnus Frédérique Laforest, Télécommunications, Services & Usages

  3. Plan global • Introduction • Génie logiciel • UML • Design Patterns Frédérique Laforest, Télécommunications, Services & Usages

  4.  Outils Partie faite par F Le Mouël Frédérique Laforest, Télécommunications, Services & Usages

  5.  Génie logiciel 1 Introduction 2 Cycle de vie, prototype 3 Normalisation 4 Tests 5 Refactoring Frédérique Laforest, Télécommunications, Services & Usages

  6. 1- Introduction : Caractéristiques du logiciel • Produit unique • conçu et fabriqué une seule fois, reproduit • Inusable • défauts pas dus à l'usure mais proviennent de sa conception • Complexe • le logiciel est fabriqué pour soulager l'humain d'un problème complexe ; il est donc par nature complexe • Invisible • Fabrication du logiciel=activité purement intellectuelle • difficulté de perception de la notion de qualité du logiciel • Technique non mature • encore artisanal malgré les progrès Frédérique Laforest, Télécommunications, Services & Usages

  7. Constats • Le coût du développement du logiciel dépasse souvent celui du matériel, • Les coûts dans le développement du logiciel : • 20% pour le codage et la mise au point individuelle, • 30% pour la conception, • 50% pour les tests d'intégration, • Durée de vie d'un logiciel de 7 à 15 ans, • Le coût de la maintenance évolutive et corrective constitue la part prépondérante du coût total , • Plus de la moitié des erreurs découvertes en phases de tests proviennent d'erreurs introduites dans les premières étapes, • La récupération d'une erreur est d'autant plus coûteuse que sa découverte est tardive. Frédérique Laforest, Télécommunications, Services & Usages

  8. Les plaintes classiques des clients • Non respect du cahier des charges, • Délais et coûts dépassant les prévisions, • Maintenance corrective et évolutive difficiles, • Non respect des performances, • Documentations absentes ou peu claires, • Fiabilité discutable. • QUALITE du logiciel, Génie logiciel Frédérique Laforest, Télécommunications, Services & Usages

  9. Génie logiciel • Ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi. Arrêté ministériel du 30/12/1983 • Procédures, méthodes, langages, ateliers, imposés ou préconisés par les normes, adaptés à l'environnement d'utilisation afin de favoriser la production et la maintenance de composants logiciels de qualité. P. Jaulent Frédérique Laforest, Télécommunications, Services & Usages

  10. Concevoir un SI • Concevoir : se représenter par la pensée, comprendre • La conception : mélange de problèmes • conceptuels (modèles, formalismes), • organisationnels (structure de l'entreprise), • techniques (matériel, logiciel), • économiques (coûts, gains), • sociaux (changement d'emploi, technicité, formation…) • En plus, l'entreprise ne s'arrête pas : • concevoir dans une organisation • en fonctionnement, • en perpétuelle évolution. Frédérique Laforest, Télécommunications, Services & Usages

  11. Concevoir un SI • C’est utiliser une démarche bien gérée • Pas de travail empirique • Mais un projet à conduire • Utiliser une méthode • Méthode = réponse aux questions : • que faire ? • quand ? • où ? • avec qui ? • comment ? Frédérique Laforest, Télécommunications, Services & Usages

  12. Modèles, méthodes et outils pour les SI • Modèles : • ensemble de concepts permettant de construire une représentation de l'entreprise • Démarche (Méthode) : • ensemble coordonné de règles opératoires qui permet de résoudre un problème en accord avec les modèles • découpe le projets en étapes à suivre : spécifier, concevoir, développer, tester, implanter, maintenir • Outils logiciels : • ensemble des aides (logiciels) que l'ordinateur fournit dans le processus de conception : on parle d'Atelier Génie Logiciel (AGL) ou Computer Aided System Engineering (CASE) Frédérique Laforest, Télécommunications, Services & Usages

  13. 2- Cycle de vie : les étapes du logiciel Compréhension du problème et des besoins Analyse (spécification des besoins) Description de ce que le système doit faire : Le que faire conception préliminaire (spécifications) Le comment faire : algorithmes... conception détaillée Développement des sources et tests des portions Codage et tests unitaires Assemblage planifié des portions, conformité par rapport aux besoins Intégration et validation Vérification de réponse aux spécifications, performances… Recette Exploitation et maintenance Utilisation du logiciel, maintenance corrective et évolutive Frédérique Laforest, Télécommunications, Services & Usages

  14. Cycle de vie en cascade Analyse conception Codage Tests Chaque étape validée n'est plus remise en cause Ne prend pas en compte l'intégralité du cycle de vie Frédérique Laforest, Télécommunications, Services & Usages

  15. Modèle en V Spécification du système et des besoins Livraison du système Modèle utilisateur Conception du système Test du système Modèle architectural Spécification des sous-systèmes Test des sous-systèmes Conception des modules Test des modules Construction Modèle d'implantation Frédérique Laforest, Télécommunications, Services & Usages

  16. Modèle de la fontaine Maintenance Développements ultérieurs Utilisation Test du logiciel Codage Conception Spécification caractéristiques Spécification besoins Analyse besoins Processus incrémental et itératif Chaque étape peut fournir des résultats modifiant le résultats des précédentes Frédérique Laforest, Télécommunications, Services & Usages

  17. Modèle en spirale Prototype incrémental Coût cumulatif Déterminer les objectifs, les alternatives, les contraintes Evaluer les alternatives Identifier et éviter les risques Analyse des risques Revue critique Proto opérationnel proto3 proto2 proto1 Progresser par étapes Prévision besoins projet Concevoir opérations Simul. Modèles Benchmarks Organisation développement Spec. besoins Conception Conception détaillée Intégration et test de l'organisation du projet Valider conception Codage Tests Organiser les phases suivantes Accepter tests Développer et vérifier le prochain niveau du produit Frédérique Laforest, Télécommunications, Services & Usages

  18. Prototype Des buts différents : • fabrication incrémentale du produit • partir d'une version très allégée • progressivement ajouter des fonctionnalités • prototype "produit" • démonstration de la faisabilité • implanter une partie des fonctionnalités • montrer que possible • prototype "jetable" • NB : maquette • présentation de l'interface utilisateur, ne fonctionne pas Frédérique Laforest, Télécommunications, Services & Usages

  19. 3- Normalisation • A de nombreux niveaux • Nommage des variables, classes, packages • Plan-type des documents rédigés (specs, dev, tests…) • Numérotation des versions (releases) • … • But : pérenniser le travail effectué, gagner du temps par la suite • Savoir où chercher quelle info • Comprendre la structure à partir des libellés (noms de classes, variables, titres de chapitres…) • Chaque organisation / projet a sa norme Frédérique Laforest, Télécommunications, Services & Usages

  20. Exemple : numérotation releases • Pour le noyau Linux (qui sert souvent de modèle) :http://en.wikipedia.org/wiki/Linux_kernel#VersionsVersion.Majeure.Mineure.Révision • Fev 06 : 2.6.15.4 • Changement de • Version : modification radicale de la conception. • Majeure : incompatibilité arrière (gros changements). De plus, n° pair = version stable et n° impair = version de dev. • Mineure : modifications du code source comme ajout de fonctionnalité, correction de bugs, etc. • Révision : modification mineure qui ne nécessite pas forcément une maj. Frédérique Laforest, Télécommunications, Services & Usages

  21. Exemple : numérotation releases • packages Gentoo, la Révision correspond au -rXX $ eix firefox-bin     * www-client/mozilla-firefox-bin         Available versions:   1.0.7   ~1.5-r2   ~1.5.0.1 • NB : Gentoo remplace peu à peu les -rXX par un 4e chiffre, comme pour le noyau Linux. • NB2 : ~ signifie instable ; parfois [M] pour masked (en cours de dev!) • Chez d'autres projets, il n'y a qu'un numéro pour Version + Majeure :$ eix emacs -a -C app-editors     * app-editors/emacs         Available versions:   ~18.59   21.4-r1 • Chez d'autres encore, il n'y a qu'un numéro tout court :$ eix xterm     * x11-terms/xterm         Available versions:   204   207   ~208 Frédérique Laforest, Télécommunications, Services & Usages

  22. Mesurer la qualité d’un logiciel • Il faut définir des « choses » à mesurer • Les mesures peuvent être qualitatives ou quantitatives • Elles doivent être explicites! • Approche de Mc Call • Plan assurance qualité Frédérique Laforest, Télécommunications, Services & Usages

  23. Approche de Mc Call : assurance qualité • Facteurs (11) : qualité vue de l'utilisateur • Critères (23) : qualité vue du réalisateur • Mesures (176) : qualité vue du contrôle • Liaisons (facteur -> critères -> mesures) intuitives • Exemple • facteur : fiabilité • critères : cohérence, robustesse simplicité • mesures : présence d'une administration des données, couverture des tests, taux de panne... Frédérique Laforest, Télécommunications, Services & Usages

  24. Facteurs de Mc Call • Conformité • Fiabilité • Intégrité • Maniabilité • Maintenabilité • Testabilité • Evolutivité • Réutilisabilité • Portabilité • Efficacité • Couplabilité On pourrait ajouter (France Télécom) confidentialité auditabilité intégrabilité Frédérique Laforest, Télécommunications, Services & Usages

  25. Critères de Mc Call Autodescription Standardisation des données Standardisation des interfaces Généralité Clarté Concision Complétude Extensibilité Facilité d'apprentissage Facilité d'utilisation Homogénéité Indépendance vis à vis du système Indépendance vis à vis du matériel Instrumentation (traces fonctionnement) Efficacité de stockage Modularité Précision Contrôle des accès Rapidité Tolérance aux pannes Simplicité Traçabilité Vérification des accès Frédérique Laforest, Télécommunications, Services & Usages

  26. Plan assurance qualité logicielle • Document "contractuel" énonçant les modes opératoires, les ressources, la séquence des activités liées à la qualité, se rapportant à un produit, service, contrat ou projet particulier. • Préciser les responsabilités des différents partenaires • Différentes actions d'assurance et de contrôle de qualité • Déterminer les produits attendus et les critères d'acceptation du logiciel • Prévoir l'organisation de la recette des sous-produits • Définir les rôles et les responsabilités des experts internes et externes (audit, sécurité, ergonomie…) • ... Frédérique Laforest, Télécommunications, Services & Usages

  27. 4- Tests du logiciel • Test = technique de contrôle consistant à s'assurer, grâce à l'exécution d'un programme, que son comportement est conforme à un comportement de référence préalablement formalisé dans un document • Le test sert à prouver l'existence d'erreurs plutôt que leur absence! Frédérique Laforest, Télécommunications, Services & Usages

  28. E-mail de M. Arnoldi à K. Beck (traduit) • « Malheureusement, pour moi en tout cas (et pas seulement pour moi), les tests vont à l’encontre de la nature humaine. Quand on lâche le porc qu’on a en soi, on s’aperçoit qu’on est capable de programmer sans tests. Ce n’est qu’au bout d’un moment que notre côté rationnel regagne le dessus, et qu’on commence à écrire des tests. […] la programmation en binômes réduit la probabilité que les deux partenaires lâchent leur porc respectif au même moment. » Frédérique Laforest, Télécommunications, Services & Usages

  29. Tests dans le cycle de vie • Les tests sont écrits lors de la rédaction des spécifications! • Spécification fonctionnelle -> tests de validation • Conception préliminaire -> tests d'intégration • Conception détaillée -> tests unitaires (par module) Frédérique Laforest, Télécommunications, Services & Usages

  30. Spécifier une fonction • Ne pas regarder comment elle fait • Mais préciser : • QUOI elle doit faire (description) • Dans quel contexte (pré-conditions) • Avec quel résultat (post-conditions) • On peut donc, avant de réfléchir au comment faire • Donner l’ensemble des cas d’utilisation • En déduire la liste des tests à faire et les coder • « les tests me donnent une occasion de réfléchir à ce que je veux obtenir sans considération de la façon dont je vais implémenter » Frédérique Laforest, Télécommunications, Services & Usages

  31. Types de tests • Unitaires : ceux du programmeur • Tests fonction par fonction • doivent être positifs à 100% sur le code passé et courant • Tests d’intégration : ceux du concepteur • groupent plusieurs fonctions • Tests fonctionnels : ceux du client • Tests scénario par scénario • Tant que produit non fini, pas forcément positif à 100% Frédérique Laforest, Télécommunications, Services & Usages

  32. Types de tests • Autres • Tests parallèles : valider que la nouvelle version fait exactement comme la précédente • Tests en charge • Tests du singe : un ingénu (naive in english) se sert du système et fait n’importe quoi • Boîte noire ou boîte blanche? • Test boîte noire : test fonctionnement : sans aller voir à l'intérieur, répond-il au besoin? • Test boîte blanche : test structurel : en allant voir sa composition, répond-il Bien au besoin? Frédérique Laforest, Télécommunications, Services & Usages

  33. Classes de tests • Test des cas normaux • utilisation normale du logiciel • Test des cas anormaux • exemples : • vérification des données en entrée • validation des procédures de reprise • Cas limites et valeurs spéciales • exemples : • table pleine , table vide • fichier inexistant Frédérique Laforest, Télécommunications, Services & Usages

  34. S’organiser pour tester • Certains langages fournissent des bibliothèques de fonctions pour automatiser le lancement des tests et la gestion des résultats • Java Junit par exemple • Faire des tests indépendants les uns des autres • Pas de tests imbriqués • Un test qui échoue ne fait pas échouer les tests suivants • Faire des tests automatisés • Non équivoques • Pas de saisie de l’utilisateur, tout en dur • Faire un makefile /ant pour compiler et lancer automatiquement tous les tests Frédérique Laforest, Télécommunications, Services & Usages

  35. Conclusion tests • Prévoir les tests et les rédiger avant de coder chaque fonction • Faire des tests unitaires, puis des tests d’intégration, puis des tests fonctionnels • Utiliser un environnement de tests pour aller plus vite • Réutiliser les tests et leurs résultats comme documentation Frédérique Laforest, Télécommunications, Services & Usages

  36. 5- Refactoring • Martin Fowler "... process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." Just cleaning up code. • Kent Beck "Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow." • Don Roberts"The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor." http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html Frédérique Laforest, Télécommunications, Services & Usages

  37. Refactoring • Pourquoi? • Améliorer la conception et la structure du code • Plus facile à maintenir • Plus facile à comprendre • Plus facile à modifier • Plus facile d’ajouter des nouvelles fonctionnalités • Un élément-clef de l'eXtreme Programming, où par définition le programme peut et doit être constamment remanié pour améliorer sa structure sans modifier son comportement. Frédérique Laforest, Télécommunications, Services & Usages

  38. Refactoring sous Eclipse • menu Refactor du menu principal, ou du menu contextuel de la zone de code à modifier. • les fonctions proposées dépendent du code sélectionné. • une vingtaine de fonctions de refactoring. • Extract Method : Crée une nouvelle méthode encapsulant les éléments sélectionnés, et remplace toutes les références à ces éléments (même ailleurs dans le code), par un appel vers cette méthode. • Rename : Renomme l'élément sélectionné. • Move : Déplace l'élément sélectionné, par exemple enlever la classe du paquetage actuel, et la place dans un autre paquetage • Change Method Signature • Extract Local Variable : crée une nouvelle variable assignée à l'expression sélectionnée. • Inline : fonction inverse de Extract Local Variable Frédérique Laforest, Télécommunications, Services & Usages

  39. Refactoring sous Eclipse • Convert Local Variable to Field : Transforme une variable locale, définie dans une méthode, en champ de classe. • Push Down / Pull Up : déplace la sélection vers la sous-classe ou la superclasse actuelle. • Introduce Parameter : Remplace une expression par une référence à un nouveau paramètre, et met à jour toutes les expressions faisant appel à cette méthode. • Extract Constant : Crée un champ de classe avec attributs static et final à partir des expressions sélectionnées, et remplace ces dernières par une référence à la constante. • Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifié auparavant tous les emplacements où ce remplacement est possible. Frédérique Laforest, Télécommunications, Services & Usages

  40. Refactoring sous Eclipse • Generalize Type : Présente à l'utilisateur une fenêtre dans laquelle il pourra choisir l'un des supertypes de la référence sélectionnée, celles permettant un changement sans risque de type étant colorées. • Extract Interface : À l'instar des précédentes fonctions de types Extract, celle-ci se charge de prendre les éléments sélectionnes et d'en tirer une classe disposant des méthodes de la classe en cours, et implémente cette interface sur la classe. • Encapsulate Field : Remplace toutes les références à un champ de classe, par des méthodes get et set pour ce champ. • Introduce Factory : Crée une nouvelle méthode de type Factory, en générant pour un constructeur donné la méthode statique appropriée. Frédérique Laforest, Télécommunications, Services & Usages

  41.  UML /Introduction aux objets /Objet, classe /Les modèles d'UML / Etude de cas Frédérique Laforest, Télécommunications, Services & Usages

  42. / Introduction : Objets • Objet • Association de données et traitements dans une même entité • Idée de base (1966, Simula) • cacher structure de données par opérations de manipulation : Types Abstraits de Données (TAD) • Fondement de l'objet (1976, Smalltalk) • ajouter des hiérarchies de généralisation entre les TAD : Classes • (a également été le berceau de l'écran bitmap avec souris) Frédérique Laforest, Télécommunications, Services & Usages

  43. Objets : 3 points de vue • Structurel • objet = instance d'un type avec structure cachée par opérations : Encapsulation • Conceptuel • objet=concept du monde réel qui peut être spécialisé • Acteur • objet=entité autonome qui répond à des messages Frédérique Laforest, Télécommunications, Services & Usages

  44. Objets : motivations • Développement de logiciels complexes • représenter directement les objets réels sans déformation • réutiliser et étendre l'existant • environnements de développement riches • créer rapidement des interfaces homme-machine événementielles • prototypage rapide (implantation partielle) • facilité d'exploitation du parallélisme Frédérique Laforest, Télécommunications, Services & Usages

  45. / Concepts objet : objet • Objet = identité + état + comportement • Identité (OId) • identifiant typiquement interne au système • implantation souvent par pointeurs • Etat • valeur simple ou structurée (comportant valeurs, objets…) • Comportement • ensemble d'opérations applicables à l'objet définies dans sa classe • Par extension, objet = identité + classe + état • représenté dans un rectangle avec texte souligné Frédérique Laforest, Télécommunications, Services & Usages

  46. Concepts objet : classe • Classe = instanciation + attributs + opérations • Instanciation • mécanisme de création d'objets • ensemble des objets instanciés = extension de la classe • Attributs (ou variables d'instance) • structure de la classe • nom + type (simple ou classe) • Opérations (méthodes) • opérations qui peuvent être appliquées aux instances • représentée dans un rectangle Frédérique Laforest, Télécommunications, Services & Usages

  47. Concepts objet : identité et égalité, visibilité • Identité et égalité • Deux objets sont identiques • OId identiques • Deux objet sont égaux • même état • Liens entre objet = références aux OId • Visibilité • Membre public • fait partie de l'interface de la classe • Membre privé • fait partie de l'implantation de la classe • sert uniquement à développer la classe Frédérique Laforest, Télécommunications, Services & Usages

  48. Bicyclette Médecin ... Roue Guidon Cadre 1..n Patient Rayon Jante Pneu Concepts objet : agrégation • Des objets complexes comprenant d'autre objets • traduction du verbe avoir • composition : si je détruis l'objet complexe, je détruis ses composants • référence : si je détruis l'objet complexe, je ne détruis pas ceux reliés • Exemple type : la nomenclature Frédérique Laforest, Télécommunications, Services & Usages

  49. Concepts objet : associations entre classes • On utilise souvent les associations binaires • Les associations peuvent être aussi traduites par des objets Appartient Voiture Propriétaire Elève Professeur Enseignement Frédérique Laforest, Télécommunications, Services & Usages

  50. Concepts objet : généralisation • Lorsque tous les objets d'une classe appartiennent aussi à une autre classe plus générale • traduction du verbe être • la sous-classe possède toutes les propriétés et méthodes de la surclasse en plus des siennes propres • Exemple : • La classe C (Carré) et la classe L (Losange) • On dit que L généralise C et que C spécialise L • C est une sous-classe de L, L est une sur-classe de C Losange Carré Frédérique Laforest, Télécommunications, Services & Usages

More Related