Module IF225 - Génie Logiciel - Filière SEE

Transcription

1 Module IF225 - Génie Logiciel - Filière SEE Georges Eyrolles 2 e séance 1 / 27

2 Deux Critères de qualité Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Objectif Comment produire et maintenir des logiciels modifiables? Deux critères internes de qualité : Flexibilité et Réutilisabilité. Respect de ces critères Dans le cadre de la conception et des techniques orientées objets. 2 / 27

3 Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Pour atteindre les deux qualités internes Quatre principes généraux : Séparation des préoccupations : Traiter les différents aspects séparément. Modularité : Découper le logiciel en parties indépendantes. Abstraction / généralité : Séparer l utilisation de la réalisation et masquer la réalisation. Anticiper les évolutions : Un logiciel évolue, ces modifications ne doivent pas être intrusive 3 / 27

4 Retour d expérience Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Découpage Création de dépendance d utilisation entre les classes. Si une classe A utilise une classe B. La classe A depend de la classe B. La classe A est cliente de la classe B. Association La dépendance d utilisation de base entre deux classes est l association ou lien a-un. 4 / 27

5 Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Dépendance d utilisation et indépendance. Indépendance L indépendance se fait vis à vis de la réécriture du code client. Dépendance et modification Les dépendances sont cataloguées en faible ou forte par rapport à une modification. 5 / 27

6 Dépendance faible/forte. Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Abstraction Faire de l abstraction est un moyen d avoir une dépendance faible entre deux classes. cohésion et couplage Cohésion : dépendance interne d une classe. Chercher des dépendances fortes dans la cohésion d une classe. Couplage : dépendance externe d une classe. Chercher avec des dépendances faibles dans le couplage entre deux classes. 6 / 27

7 D.R.Y. Principes de conception Précédemment Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Le principe DRY ( Don t Repeat Yourself ) Ne vous répétez pas est un principe de programmation qui encourage à éviter la duplication de code. Dupliquer du code correspond à une dépendance forte par rapport à la modification du code dupliqué. 7 / 27

8 Retour d expérience Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Factorisation Il est possible de factoriser le code avec une relation d association entre deux objets (deux classes). La factorisation rend visible la dépendance d utilisation et permet de la cataloguer en dépendance faible ou forte par rapport à la modification du code factorisé. 8 / 27

9 O.C.P. Principes de conception Précédemment Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Principe d ouverture/fermeture ( Open/Close Principle ) Tout module (package, classe, méthode) doit être ouvert aux extensions mais fermé aux modifications [Bertand Meyer (1988)]. 9 / 27

10 Retour d expérience Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Abstraction Introduction d une abstraction utilisée par le client pour masquer les classes de réalisation. Cette abstraction est définie par une classe sans réalisation : interface ou classe abstraite pure. Substitution d objet ou Polymorphisme À l exécution, substitution des instances des classes de réalisation dans le code client. Pour cela il faut introduire deux mécanisme : une relation de type/sous-type entre classe (lien est-un ) ; une liaison dynamique ou retardée. 10 / 27

11 Approche Orientée Objet Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet L approche objet offre des mécanismes permettant de respecter plus facilement le principe d ouverture/fermeture. Encapsulation : Un objet regroupe donnée et traitement en assurant un masquage d information de la réalisation (principe d abstraction). Pour permettre la substitution, un objet doit être manipulé par son adresse. Héritage : Mis en œuvre de la relation de type/sous-type (ou lien est-un ) sur les classes pour mettre en relation une abstraction et ses réalisations (en permettant aussi de partager du code). liaison dynamique ou retardée : L adresse des méthodes est déterminée à l exécution (avec le mot-clé virtual en C++). 11 / 27

12 Conception Précédemment Critères de qualité Dépendances d utilisation et indépendance Principes de conception Approche Orientée Objet Formaliser la conception d un logiciel. Péréniser l expérience de conception et prendre du recul sur le langage de programmation. 12 / 27

13 Unified Modeling Language Aide à la formalisation d un système orienté objet. UML a été créé et adopté comme standard au milieu des années En 2000, il est accepté par le comité ISO (1997 version 1.1 et 2015 version 2.5). UML permet de spécifier, concevoir, modéliser, documenter tous les aspects d un logiciel en restant indépendant du langage de programmation. UML est centré sur l approche objet. UML est un langage formel extensible (notion de modèle, de méta-model). 13 / 27

14 Unified Modeling Language UML inclut une notation graphique. UML sert de support de communication avec 14 diagrammes : 7 pour l aspect structurel/statique ; comme par exemple le diagramme de classes pour les relations entre classes. 7 pour l aspect dynamique/interaction ; comme par exemple le diagramme de séquence pour la communication entre objets (l appel de méthodes). 14 / 27

15 UML Notation graphique Précédemment Ressources en anglais pour la notation graphique : Sur le site de l O.M.G. ( Un résumé des représentations graphiques maintenu par Allen Holub ; un guide maintenu par Kirill Fakhroutdinov ; UML sur wikipédia 15 / 27

16 UML Le diagramme de classes est le plus connu et le plus important des diagrammes pour la phase de conception. C est une vue structurelle, statique du logiciel. classe : concrète, abstraite, interface (abstraite pure) ; attribut : type, variable d instance, variable de classe ; méthode : prototype, méthode abstraite, méthode d instance, méthode de classe ; portée/visibilité : privée, publique, protégée ; 16 / 27

17 UML Les différentes relations entre classes : Association (association unidirectionnelle, cardinalité, agrégation, composition) ; Relation de type/sous-type : Généralisation : entre deux classes (ou deux interfaces) ; Réalisation : entre une classe et une interface ; Dépendance (paramètre ou variable locale). 17 / 27

18 Notre cas d école De la modélisation à la réalisation Exercice : Charniere Construire le diagramme de classe pour notre petit cas d école. Formalisons notre problème de dépendances à l aide d un diagramme de classes. Interprétons ce diagramme = substitution d objets. Réalisons le code en langage C++. Pour la construction du diagramme de classes, nous utilisons un outil de modélisation UML : argouml (écrit en java sous licence libre, argouml.tigris.org). 18 / 27

19 Notre petit cas d école Récupérer et exécuter ArgoUML Exercice : Charniere À partir du lien suivant : Dans le répertoire seance2, récupérez le fichier archive du logiciel argouml-0.34.tar ; et une sauvegarde du projet de notre cas d école sous argouml casdecole1.zargo. Décompresser le fichier archive d argouml-0.34.tar et exécuter le script argouml.sh. 19 / 27

20 Exercice : Charniere Compléter le diagramme de classes Exercice : Charniere À partir du projet de notre cas d école casdecole1.zargo, compléter le diagramme de classes : 1 Ajouter la classe Charniere avec attributs, méthodes, et constructeurs. 2 Regarder le code source généré. 3 Ajouter la relation d association entre Telecommande et Charniere. 20 / 27

21 Respecter OCP Relation de Type/Sous-Type Précédemment Pour respecter le Principe Ouverture/Fermeture, utiliser la relation de Type/Sous-Type Type/Sous-type Un sous-type contient les opérations déclarées dans le type de base. Une variable du type de base peut accepter sans problèmes des instances des sous-types (Héritage de type). 21 / 27

22 Définir une abstraction la relation entre les réalisations et une abstraction Une abstraction est représentée par la notion d interface en UML : Une classe sans réalisation (indiqué par le stéréotype <<interface>>) Pour indiquer qu une classe est une réalisation d une abstraction, il faut utiliser le lien réalisation (c est une relation de type/sous-type). 22 / 27

23 Exercice Précédemment 1 Ajouter l interface IPorte (classe abstraite pure). 2 Mettre les bonnes relations : association et réalisation. 3 Générer le code. 23 / 27

24 Exercice : VerrouCharniere L héritage (la généralisation en UML) est une relation de type/sous-type avec factorisation du code. Définir le classe VerrouCharniere en héritant de la classe Charniere. Dans la classe dérivée, il est possible de redéfinir le code d une méthode (virtuelle) héritée et de faire appel à la méthode de la classe de base. Par contre aucune modification des attributs de la classe de base n est possible. 24 / 27

25 Récupérer le fichier contenu dans le répertoire magicien-c++. Ce fichier définit les deux classes Magicien et Spectacle et un programme principale. Quel relation UML exite-t-il entre ces deux classes? L instruction Magicien m(30) crée-t-elle un apprenti ou un mage? Pourquoi le principe O.C.P. n est-il pas respecté dans la classe Magicien? Donner le diagramme de classes d une solution qui respecte O.C.P. 25 / 27

26 Récupérer la classe magicdoor contenue dans le répertoire magicdoor. Nous voulons utiliser les instances de la classe MagicDoor dans la classe Telecommande. Le plus simple est de faire hériter MagicDoor de l interface IPorte mais nous ne voulons pas modifier la classe MagicDoor. Il y a deux solutions pour inclure MagicDoor dans cette architecture sans modifier la classe MagicDoor. Donner le diagramme de classes des solutions. 26 / 27

27 Récupérer les fichiers contenus dans le répertoire canards-2.0-c++. Donner le diagramme de classes. Indiquer les classes abstraites et les méthodes abstraites. L utilisation de la généralisation/l héritage peut aboutir à la duplication de code : ici celui de la méthode cancanner(). Donner le diagramme de classe qui respecte D.R.Y. 27 / 27