Structures de données IFT-2000 Abder Alikacem Introduction au cours Semaine 1 Département dinformatique et de génie logiciel Édition Septembre 2009.

Présentation au sujet: "Structures de données IFT-2000 Abder Alikacem Introduction au cours Semaine 1 Département dinformatique et de génie logiciel Édition Septembre 2009."— Transcription de la présentation:

1 Structures de données IFT-2000 Abder Alikacem Introduction au cours Semaine 1 Département dinformatique et de génie logiciel Édition Septembre 2009

2 Plan Introduction Analyse et abstraction Modélisation Types de données abstraits Spécifications Implantation Plan et modalités du cours

3 Viny, la mascotte du cours!!

4 Conventions de représentation Conventions de représentation de linformation(Interface): integer idem pour tout programme sur un même ordinateur, utilisant le même langage: int x; Conventions dutilisation (Opérateurs): integer pas de décimales: x = 5/2; Dune manière générale, pour définir un type de données, on a besoin de décrire éventuellement: son nom (syntaxe); sa sémantique; son domaine de valeurs; ses contraintes; etc.. + son comportement: { opérateurs } Interface publique

5 Conventions de représentation 0000 00±00 ± bit de signe complément à 1: C 1 complément à 2: C 2 Structuration de base = types simples (ex. le type int) convention de représentation interne (Modèle interne): int x, y; choix de représentation interne {implantation de linterface} Modèles internes

6 Conventions transparentes Transparence des types de base: 00011101010101 00010101010101 00101010100001 11111100000101 …. 00011 int x; y = x++;

7 Types de base Types de base: en C/C++: int, float, char, double, long, short tableaux, string, etc. en Pascal: set en SmallTalk: dictionnaires: { }

8 Types structurés types de base modélisation de base traitement numérique (appl. scientifiques) traitement de texte (caractères) types structurés modélisation dobjets enregistrements (étudiants, cours, BD, …) modélisation orientée objet (OO) types structurés = agrégation déléments de base

9 Besoin de types plus complexes! Caractéristiques dun système sont souvent difficiles à être représentées directement dans un ordinateur. Existences de distances conceptuelles. Comment réduire ces distances? Analyse (descendante) du domaine Abstraction (à partir des objets informatique de base jusquà une possible représentation du réel) Cest la modélisation!

10 Modélisation des données Lélaboration dun algorithme est grandement facilité par lutilisation de types ou structures de données abstraites de plus haut niveau, et de fonctions de manipulations associées. Une structure de données doit modéliser au mieux les informations à traiter pour en faciliter le traitement par lalgorithme considéré. Choisir les bons modèles de données est aussi important que le choix de bons algorithmes. Algorithme et structure de données abstraite sont intimement liés : Programme = algorithme + données

11 Programmes et informations information intermédiaire outputinput Programme = Algorithme + données

12 Construction dun modèle Modélisation: Réalité Modèle

13 Principe de la modélisation Hiérarchie Relation entre plusieurs petites composantes. Décomposition. Réduire le système en plusieurs plus petits systèmes plus faciles à modéliser. Divide & conquer. Assurer la collaboration pour créer un système qui effectuera les fonctionnalités désirées. Masquage dinformation. Information hiding. Encapsulation Regrouper (enclosure) ensemble des attributs et méthodes qui logiquement ont une affinité (coupling & cohesion). Masquage dinformation Cacher les secrets dune implémentation. Abstraction Permet de négliger les détails moins importants. Permet de se concentrer sur les aspects les plus importants du système à modéliser.

14 Modélisation: Réalité Modèle Construction dun modèle

15 Modélisation: Réalité Modèle Construction dun modèle

16 x Modélisation: Réalité Modèle Construction dun modèle

17 x Modélisation: Réalité Modèle float x; Construction dun modèle

18 struct Pt { float x; float y; float z; } ; float x; x Modélisation: Réalité Modèle Construction dun modèle

19 struct Pt { float x; float y; float z; } ; struct Plan { pt p[4]; } ; x Modélisation: Réalité Modèle float x; Construction dun modèle

20 struct Boite { Plan pl[6]; }; struct Pt { float x; float y; float z; } Pt; x Modélisation: Réalité Modèle float x; struct Plan { Pt p[4]; }; Construction dun modèle

21 struct Pt { float x; float y; float z; }; Boite b1; x Modélisation: Réalité Modèle float x; struct Plan { Pt p[4]; }; struct Boite { Plan pl[6]; }; Construction dun modèle

22 Modélisation = transfert Boite b1; … b1.rotation(b1,45); … Modélisation: Réalité Modèle

23 Création dun modèle struct boite { Plan pl[6]; }; struct Pt { float x; float y; float z; }; struct Plan { Pt p[4]; }; float x; Boite b1; … b1.rotation(b1,45); … Modélisation: modèle près de la réalité modèle distant des détails dimplantation

24 typedef struct { plan pl[6]; } boite; typedef struct { float x; float y; float z; } pt; typedef struct { pt p[4]; } plan; float x; Boite b1; … b1.rotation(b1,45); … boîte noire Modélisation: modèle près de la réalité modèle distant des détails dimplantation Les types de données abstraites (TDA)

25 Programme indépendant de limplantation du type Boite: Boite b1, b2, b3; b1.creer(…); b2 = b1; b3 = b2; b1.rotation(45); b2.poseSur(b3); Boite est alors un type abstrait! Les types de données abstraites (TDA)

26 Encapsulation vs Masquage dinformation Lencapsulation et le masquage dinformation sont la base de la modélisation de données et de la création des types abstraits. Encapsulation Regrouper (enclosure) ensemble des attributs et méthodes qui logiquement ont une affinité (coupling & cohesion). Masquage dinformation Cacher les secrets dune implémentation. Un nimplique pas nécessairement lautre, mais dans lusage courant, les deux concepts sont souvent interchangés. Avec le temps, ils sont devenus des synonymes.

27 Lencapsulation des données est différente suivant les langages et dépend des règles de visibilité adoptées par défaut par ces langages. On distingue généralement 3 règles de visibilité (on donnera, à titre dexemple, le mot-clé Java correspondant) pour les différents composants dune classe (variables dinstance et méthodes): publique (public) : visible de partout protégée (protected) : visible à lintérieur de la classe et des sous-classes privée (private) : visible que pour les méthodes de la classe Dans certains langages, il y a aussi une notion de composant friend visible par toutes les autres méthodes des classes définies dans le même fichier ou package. Encapsulation vs Masquage dinformation

28 Un type de données abstrait modélise l« ensemble des services » désirés plutôt que lorganisation intime des données (détails dimplémentation). Il est créée à partir dun ensemble de données organisé et reliées logiquement. Il est caractérisée par : son contenu les interactions possibles (manipulation, accès,...) est défini uniquement par ses conventions dutilisation par le comportement des objets de ce type (i.e., par les méthodes applicables sur les objets de ce type) ne décrit pas le modèle dimplantation choisi sert à isoler les programmes des données (structuration interne) crée une indépendance des applications face aux modèles dimplantation (continuité de la programmation structurée) permet lencapsulation de la définition dun type Les types de données abstraites (TDA)

29 La notion de type de données abstrait (T.D.A.), née dune préoccupation du génie logiciel, est indépendante de tout langage de programmation. Elle généralise les types prédéfinis: on veut généraliser cette idée dobjets manipulables par des opérateurs propres, sans forcément en connaître la structure interne et encore moins limplémentation. Permet d obtenir les qualités attendues d un logiciel daujourdhui: extensibilité réutilisabilité compatibilité

30 Les types de données abstraites (TDA) Préoccupation de génie logiciel se placer à un niveau d'abstraction élevé, identifier précisément les caractéristiques de lentité (par rapport à ses applications), et en décrire les propriétés éviter les erreurs de conception programmer avec des opérations de haut niveau qui ne dépendent pas de la représentation interne qui permettent de changer de représentation qui permettent à l'utilisateur de se concentrer sur les problèmes de conception en ignorant les détails de réalisation encapsuler les données n'accéder à la représentation interne que via des fonctions l'utilisateur ne voit que les services (linterface) pas la représentation interne Indépendance programmes/données

31 Indépendance programmes/données: modularité de développement facilité dassemblage de modules validation modulaire et continue Réutilisation Évolution coût dentretien Les types de données abstraites (TDA)

32 Incarnation dun TDA Une incarnation (une réalisation, une mise en œuvre, une « implémentation ») d'un TDA est la déclaration des structures de données particulières et la définition des opérations primitives retenues pour représenter le TDA. Linterface (fichier.h) Et la définition (i.e le code) des opérations primitives dans un langage particulier Limplémentation (fichier.cpp) les programmeurs ont deux casquettes: le concepteur du TDA qui met en œuvre les primitives et doit connaître la représentation interne adoptée. On parle de programmation de bas niveau. l'utilisateur du TDA qui ne connaît que les services (les opérations) et n'accèdent jamais à la représentation interne. On parle de programmation de haut niveau.

33 Interface de communication Interface explicite (publique) Masquage des informations Offrir des opérateurs (du service) sans connaître les détails de limplémentation Factoriser le code de limplémentation des opérateurs: fonctions privées. Interface Données Fonctions main() Linterface

34 Avec les types de données de base: donnéesprogramme interface int x, y; y = x + 1; int x, y; =, +, -, ++, --, *, /,... Linterface main()

35 Avec des types structurés: donnéesprogramme interface boite b1; rotation(b1,4 5); Boite b1; rotation, poseSur,... Linterface main()

36 Linterface main() Remarque. On identifie généralement 4 types de « services » : 1. les modificateurs, qui modifient le T.D.A. 2. les sélecteurs, qui permettent « dinterroger » le T.D.A. 3. les itérateurs, qui permettent de parcourir la structure 4. les constructeurs (que lon verra plus tard) Exemple : tableau (structure de données élémentaire) modifieur : affectation dun élément (t[i]=a) sélecteur : lecture dun élément (t[i]) sélecteur : le tableau est-il vide ? (t.size() == 0) itérateur : index dun élément ([i] ci-dessus)

37 //Fichier ModeleImplantationListe.h #ifndef _LISTEC__H #define _LISTEC__H #define MAX_LISTE 100 typedef enum {FAUX, VRAI} Bool; typedef struct { int tab[MAX_LISTE]; int cpt; } Liste; #endif //Fichier Liste.h #include "ModeleImplantationListe.h" #include "CodesErreur.h" Liste initListe(int * err); /**/ int tailleListe(Liste l, int *err); /**/ Bool estVideListe(Liste l, int *err); /**/ Liste ajouterListe(Liste l, int x, int pos, int *err); /**/ // etc.. // Fichier Liste.h #include #ifndef _LISTEC__H #define _LISTEC__H class Liste { public: Liste(); //constructeur ~Liste(); //destructeur void ajouter (int x, int pos) throw(range_error, length_error); int taille() const ; bool estVide() const; //etc… private: static const int MAX_LISTE = 100; int tab[MAX_LISTE]; int cpt; }; #endif Interface en C++ Interface en C Exemple dune interface dun type abstrait Cest la partie publique

38 Exemple dune implémentation en C /******************************************************************** Fichier Liste.c Version 1.0 Janvier 2007 (c) IFT-10541 Structures de données ********************************************************************/ #include "Liste.h" Liste ajouterListe (Liste l, TypeEl x, int pos, int *err) { /*objectif:ajouter l'élément x à la liste l en position pos méthode:décaler vers la droite tous les éléments à partir de la fin de la liste, jusqu'à ce que pos soit atteint besoins:La liste l, l'élément x, l'indice d'insertion pos et MAX_LISTE, la taille maximale de la liste connu:MAX_LISTE entrée: l, x, pos sortie:La liste l mise à jour (si *err = OK), la liste l inchangée sinon. résultat:*err=OK si les pré sont respectées, PAM si pas assez de place, PERR si la position est erronée hypothèses: pos est compris entre 1 et la taille de la liste + 1 (|L| + 1) inclusivement, il y a assez de place pour ajouter x. */ …

39 Exemple dune implémentation en C (suite) Liste ajouterListe (Liste l, TypeEl x, int pos, int *err) {… if (l.cpt >= MAX_LISTE) { /* La liste est pleine. */ *err = PAM; return l; } /*A: La liste n'est pas pleine */ if ((pos (l.cpt + 1))) { /* Les paramètre fournis sont invalides. */ *err = PERR; return l; } /*A: pos >= 1 et pos <= taille de la liste + 1 */ *err = OK; //etc... return l; }

40 Exemple dune implémentation en C++ /**Commentaire style Doxygen * \file Liste.cpp * \brief Le code des opérateurs de la liste. * \author Abder * \version 0.1 * \date septembre 2009 * * Implémentation de la classe générique Liste. * */ #include "Liste.h"

41 Exemple dune implémentation en C++ void Liste::ajouter (int x, int pos) throw(out_of_range, length_error){ if (cpt==MAX_LISTE) throw length_error("Ajouter:La liste est pleine"); if (pos this->taille() +1) throw out_of_range("Ajouter:Position d'ajout erronée"); //etc… } #include "Liste.h" int main() { Liste l; try //on essaie un ajout{ l.ajouter(1,1); l.ajouter(2,2); l.ajouter(4,8); // erreur.. //… } catch(exception& e) { cerr<<"ERREUR: " <<e.what(); …; }.... return 0; } /** Commentaire style Doxygen * \fn void Liste:: ajouter (int x, int pos) * * \param[in] x Élément à ajouter * \param[in] pos Position où insérer l'élément * */ Un main de test: Fichier Main.cpp

42 Interface = ensemble dopérations ou servies fournies sur un type abstrait = (conventions et contraintes + comportement) = { prototypes des opérateurs} + spécifications formelles données programme int x, y; y = x + 1; Spécifications dune interface main()

43 donnéesprogramme interface spécification dun type abstrait choix dun modèle dimplantation indépendants!!! Lidée : si un programme marche avec une abstraction de données, il pourrait marcher avec une autre, si lautre a la même interface et surtout la même spécification. Spécifications dune interface

44 Spécifications « langage C » Exemple: ajout dans une liste ordonnée L L + i x prototype de la fonction implantant lopérateur: Liste ajouterListe(Liste l, TypeEl x, int i, int *err); préconditions conditions devant être vraies au départ pour assurer le bon fonctionnement de l opérateur l ne doit pas être pleine et i [1,|L|+1] postconditions conditions étant vraies (observables) après lapplication (correcte) de lopérateur l contient x et *err = OK si les préconditions sont respectées l est inchangée sinon et *err contient: PAM si L est pleine, PERR si i [1,|L|+1] valeur retournée en output de lapplication de l opérateur: l mise à jour ou l inchangée en cas d'erreurs

45 Spécifications « C++ » Exemple: ajout dans une liste ordonnée L L + i x prototype de la méthode implantant lopérateur: void ajouter(TypeEl x, int i) throw(range_error, length_error); préconditions conditions devant être vraies au départ pour assurer le bon fonctionnement de l opérateur La liste ne doit pas être pleine et i [1,|L|+1] postconditions conditions étant vraies (observables) après lapplication (correcte) de lopérateur La liste contient x si les préconditions sont respectées La liste est inchangée sinon et : Exceptions les exceptions lancées par la méthode lors dun problème si L est pleine, si i [1,|L|+1] valeur retournée en output de lapplication de l opérateur: aucune

46 Spécifications version dOxygen Exemple: ajout dans une liste ordonnée L L + i x prototype de la méthode implantant lopérateur: void ajouter(TypeEl x, int i) throw(range_error, length_error); /** * \brief Ajouter un nouvel élément dans la liste * * \pre il y a assez de mémoire pour ajouter l'élément x * \pre la position d'ajout, pos, est comprise entre 1 et |L|+1 * * \post la liste comprend un élément de plus * \post la liste est inchangée sinon * * \exception range_error si la position est erronée * \exception length_error si pas assez de mémoire * */

47 Spécifications version dOxygen (dans une classe) // Le type Liste class Liste{ public://L'interface... /** * \brief Ajouter un nouvel élément dans la liste * * \pre il y a assez de mémoire pour ajouter l'élément x * \pre la position d'ajout, pos, est comprise entre 1 et |L|+1 * * \post la liste comprend un élément de plus * \post la liste est inchangée sinon * * \exception range_error si la position est erronée * \exception length_error si pas assez de mémoire */ void ajouter(int x, int pos) throw(range_error, length_error);... private:...//Modèle d'implantation }; Fichier Liste.h

48 Quand on développe une structure, on doit donc le considérer comme un « type abstrait », cest-à-dire dont la spécification ne dépend pas de limplémentation. On parle également de théorie de contrat. Pour établir cette spécification (qui risque moins de changer que limplémentation), il faut avoir recours à une documentation complète de chacune des fonctions qui permettent de manipuler les objets du type en question. La meilleure façon de procéder est demployer une convention sur la façon de documenter les fonctions. La convention de documentation la plus utilisée à lheure actuelle est sans doute celle employée par lutilitaire Doxygen http://doxygen.orghttp://doxygen.org Doxygen permet de générer automatiquement, à partir du code, une documentation dans un format pratique (le plus souvent html). Spécifications dun type abstrait

49 Modèles dimplantation Choix dun modèle dimplantation: Besoins de lapplication: temps de réponse volume de données volatilité des données Ressources disponibles: temps CPU espace-mémoire systèmes dexploitation et architecture du système complexité: temps de développement, dimplantation et de mise à jour

50 //Fichier ModeleImplantationListe.h #ifndef _LISTEC__H #define _LISTEC__H #define MAX_LISTE 100 typedef enum {FAUX, VRAI} Bool; typedef struct { int tab[MAX_LISTE]; int cpt; } Liste; #endif // Fichier Liste.h #include using namespace std; #ifndef _LISTEC__H #define _LISTEC__H class Liste { public: … //linterface publique private: static const int MAX_LISTE = 100; int tab[MAX_LISTE]; int cpt; }; #endif En C++ En C Exemple de modèle dimplantation Cest la partie privée

51 Avantages des TDA Écriture de programmes en couches : la couche supérieure traite le problème dans les termes du domaine de problèmes Empiler (x, P) la couche inférieure entre dans les détails du langage de programmation tab[sp++] = x Séparation claire des offres de service du codage Et.. facilité de compréhension et d'utilisation des modules de codes prise en compte de types complexes briques d'une structuration modulaire rigoureuse introduction à la programmation objet Théorie du contrat

52 Non-respect de la théorie du contrat On modifie sauvagement les données dans structures à tous les endroits où on a besoin des structures. On considère que tous les membres de la structure sont accessibles. Ça semble plus facile à faire pour un débutant. Un changement de conception dune structure devient impossible dès que le logiciel prend de lenvergure. Respect de la théorie du contrat Lidée est de préparer le logiciel à un changement radical du contenu de la structure. On passe obligatoirement par des fonctions pour accéder aux membres structures. On ne fait jamais de supposition sur lexistence de tel membre. Plus difficile à réaliser pour un débutant. Ça facilite les changements de conception de structures. Avantages des TDA

53 struct Boite { int taille; int direction; } ; /*définition dun modèle interne pour un type Boite*/ /*Les opérateurs du type Boite*/ int getTailleBoite(Boite b);/* Retourne la taille de b*/ Boite setTailleBoite(Boite b, int nouvelleTaille); /*Assigne une nouvelle taille à b*/ Boite augmenterTailleBoite(Boite b, int i); /*Augmente la taille de b dune valeur égale à i */ Ce programme brise lencapsulation, à la ligne 4: il y a non respect de la théorie du contrat. int main() { Boite b; // ligne 1 int t; // ligne 2... // ligne 3 t = b.taille; // ligne 4 t = t+5; // ligne 5 b=setTailleBoite(b,t); // ligne 6... } Exemple

54 Inconvénients des TDA L'utilisateur d'un TDA connaît les services mais ne connaît pas leur coût. Le concepteur du TDA connaît le coût des services mais ne connaît pas leurs conditions d'utilisation. Le choix des primitives est quelque fois difficile à faire.

55 Les types abstraits On doit également toujours se poser les deux questions suivantes dans la conception dun type abstrait : n y a-t-il pas dopérations contradictoires ? ð consistance a-t-on donné un nombre suffisant dopérations pour décrire toutes les propriétés du type abstrait que lon voulait spécifier au départ ? ð complétude

56 Types Abstraits et lOrienté-Objet « La conception par objets est la construction de systèmes logiciels prenant la forme de collections structurées d implémentations de types de données abstraits » B. Meyer

57 Gestionnaire de données Programmeur dapplication interface donnéesprogramme spécification formelle dun type abstrait choix dun modèle dimplantation Cours de structures de données

58 Tâches à maîtriser Gestionnaire de données Programmeur dapplication interface donnéesprogramme spécification formelle dun type abstrait choix dun modèle dimplantation

59 Analyse: -besoins -contraintes 1 Tâches à maîtriser Gestionnaire de données Programmeur dapplication interface donnéesprogramme spécification formelle dun type abstrait choix dun modèle dimplantation

60 Analyse: -besoins -contraintes Conception: -choisir un modèle d implantation -réaliser limplantation 1 2 Tâches à maîtriser Gestionnaire de données Programmeur dapplication interface donnéesprogramme spécification formelle dun type abstrait choix dun modèle dimplantation

61 Analyse: -besoins -contraintes Conception: -choisir un modèle d implantation -réaliser limplantation 2.1 1 2 Tâches à maîtriser Gestionnaire de données Programmeur dapplication interface donnéesprogramme spécification formelle dun type abstrait choix dun modèle dimplantation

62 Analyse: -besoins -contraintes Conception: -choisir un modèle d implantation -réaliser limplantation 2.1 1 2 Tâches à maîtriser Gestionnaire de données Programmeur dapplication interface donnéesprogramme spécification formelle dun type abstrait choix dun modèle dimplantation 2.2

63 Tâches à maîtriser Conception dun type abstrait : Définition Implantation Utilisation Mais pas nécessairement par les mêmes personnes

64 Tâches à maîtriser Conception dun type abstrait : Définition Définition Lanalyse du problème mène à définir un type abstrait. La définition se fait sans penser à limplantation (indépendance de limplantation) Les spécifications formelles. Implantation Utilisation

65 Tâches à maîtriser Conception dun type abstrait : Définition Implantation Implantation Il y a différente façon dimplanter, le choix dépend de plusieurs facteurs (besoins, ressources, …) Les commentaires dimplémentation. Utilisation

66 Tâches à maîtriser Conception dun type abstrait : Définition Implantation Utilisation Utilisation Lutilisateur na pas à connaître le choix dimplantation. Lutilisateur a accès uniquement aux spécifications formelles du type abstrait.

67 Objectifs du cours Programmation des structures de données et des algorithmes qui les manipulent. Concepts : abstraction, généricité, encapsulation, programmation orienté objet Techniques : la manipulation des pointeurs, la gestion de la mémoire dynamique Structures de données Listes, Piles, Files, Arbres, Graphes, Tables de dispersion Tris Choix : Présentation sous forme de Types de Données Abstraits Analyse dalgorithmes (notation asymptotique) Écriture de programmes lisibles et efficaces (complexité)

68 Discussion sur le plan de cours Contenu du cours Évaluations Apprentissage du langage C++ Compilateurs, OS Manuel, site Web, liste de diffusion, forum, courriel Laboratoires, autres exercices SVN, dOxygen, Eclipse, VS 2008 Les équipes dans les TPs Conseils..

69 Le point sur les normes de programmation Normes de programmation: Commentaires dinterface Commentaires dimplémentation Découpage logique dun programme La gestion des exceptions Style de programmation Voir sur le site Web du cours, section Documentations/Normes de programmation: NormesProgrammation.pdf Resume.h (à propos des commentaires Doxygen)