2 e séance
Deux Critères de qualité 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.
Pour atteindre les deux qualités internes Trois principes généraux : 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
Retour d expérience : Découpage Définition d une relation d association entre deux classes. L association est une relation entre deux objets. Retour d expérience : Indépendance Indépendance vis à vis de la modification (réécriture) du code. Utiliser l abstraction pour assurer cette indépendance entre classes.
Conception de logiciels flexibles O.C.P. 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)].
Retour d expérience Définition d une abstraction utilisée par le client ; À l exécution, substitution des réalisations (données et traitement) dans ce code client.
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 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.
Conception de logiciels flexibles D.R.Y. 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.
Retour d expérience Il est possible de factoriser le code avec une relation d association entre deux objets (deux classes).
Conception Formaliser la conception d un logiciel. Péréniser l expérience de conception et prendre du recul sur le langage de programmation.
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 1990. 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).
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).
UML Notation graphique Approche Orientée Objet Ressources en anglais pour la notation graphique : Sur le site de l O.M.G. (www.uml.org/). Un résumé des représentations graphiques maintenu par Allen Holub ; www.holub.com/goodies/uml/ un guide maintenu par Kirill Fakhroutdinov ; www.uml-diagrams.org/ UML sur wikipédia
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 ;
UML Les différentes relations entre classes : Association (association unidirectionnelle, agrégation, composition) Relation de type/sous-type : Généralisation : entre deux classes. Réalisation : entre une interface et une classe. Dépendance (paramètre ou variable locale).
De la modélisation à la réalisation 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).
Récupérer et exécuter ArgoUML À partir du lien suivant : https://georgy.vvv.enseirb-matmeca.fr/see-if225 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.
Exercice : Charniere Compléter le diagramme de classes À 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.
Respecter OCP Relation de Type/Sous-Type 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).
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).
Exercice 1 Ajouter l interface IPorte (classe abstraite pure). 2 Mettre les bonnes relations : association et réalisation. 3 Générer le code.
Exercice : Un service de verrou en utilisant la classe Charniere Ajouter la classe Verrou : un attribut estverrouille, deux méthodes bloquer(), debloquer(), modifier la méthode ouvrir (). La classe Verrou utilise le code de la classe Charniere. Quelle relation choisir : généralisation ou association?
Exercice Par généralisation/héritage Définir le classe VerrouCharniere avec une relation de généralisation (héritage) à partir de la classe Charniere. Utilisation de l héritage de code (en plus de la relation de type/sous-type).
Généralisation/Héritage Redéfinition d une méthode Le code hérité de la méthode ouvrir () doit être adapté dans la classe VerrouCharniere. Notion de redéfinition du code d une méthode. et appel de la méthode de la classe de base. La redéfinition implique une liaison dynamique (retardée).
Généralisation/Héritage La généralisation (l héritage ) est une relation de type/sous-type avec factorisation du code. D où la possibilité de redéfinir le code d une méthode (par contre pas de modification des attributs de la classe de base).
Généralisation/héritage Il est possible d utiliser les instances (objets) de VerrouCharniere dans un objet de Telecommande. Par contre, la classe Telecommande ne peut pas utiliser la méthode verrouiller () de la classe VerrouCharniere.
Modifier le diagramme de classes pour : permettre à un client d utiliser le service de verrou sans modifier l interface IPorte. Pourquoi faut-il éviter de modifier une interface/abstraction?
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.
Récupérer les fichiers contenus dans le répertoire canards-2.0-c++. Donner le diagramme de classes. L utilisation de la généralisation/l héritage peut aboutir à la duplication de code : ici celui de la méthode cancanner(). Comment éviter cette duplication de code? Étudier les deux solutions qui respectent D.R.Y.