Structures de données IFT-10541

Structures de données IFT-10541
Abder Alikacem Types de données abstraites (1) Semaine 1 Édition Septembre 2009 Département d’informatique et de génie logiciel

Plan Introduction Analyse et abstraction Modélisation
02/04/2017 Plan Introduction Analyse et abstraction Modélisation Types de données abstraits Spécifications Implantation Plan et modalités du cours Vice-rectorat à la recherche / octobre 2005

Viny, la mascotte du cours!!
02/04/2017 Vice-rectorat à la recherche / octobre 2005

Conventions de représentation
02/04/2017 Conventions de représentation Conventions de représentation de l’information(Interface): integer  idem pour tout programme sur un même ordinateur, utilisant le même langage: int x; Conventions d’utilisation (Opérateurs): integer  pas de décimales: x = 5/2; D’une 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 Vice-rectorat à la recherche / octobre 2005

02/04/2017 Conventions de représentation 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 l’interface} Modèles internes bit de signe complément à 1: C1 complément à 2: C2 Vice-rectorat à la recherche / octobre 2005

02/04/2017 Conventions de représentation main() 1 +3 (x) +1 y = x – 1; - Bit de signe Complément à 2 1 +3 (x) -1 +2 + 1 +3 (x) -1 +2 + Vice-rectorat à la recherche / octobre 2005

Opérateurs de haut niveau
02/04/2017 Opérateurs de haut niveau Opérateurs de plus haut niveau (plus abstraits) : post/pré-incrémentation: x++; ++x; post/pré-décrémentation: x--; --x; donnent une facilité de manipulation Vice-rectorat à la recherche / octobre 2005

Conventions transparentes
02/04/2017 Conventions transparentes Transparence des types de base: int x; y = x++; 1 …. Vice-rectorat à la recherche / octobre 2005

Types de base Types de base: en C/C++:
02/04/2017 Types de base Types de base: en C/C++: int, float, char, double, long, short tableaux, string, etc. en Pascal: set en SmallTalk: dictionnaires: {<clé,élément>} Vice-rectorat à la recherche / octobre 2005

Types structurés types de base  modélisation de base
02/04/2017 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 d’objets enregistrements (étudiants, cours, BD, …)  modélisation orientée objet (OO) types structurés = agrégation d’éléments de base Vice-rectorat à la recherche / octobre 2005

Source: US Gov. Accounting Report, (in B. Cox, OO Prog.)
02/04/2017 Problématique Les méthodologies TDA et OO s'adresse au problème du développement de logiciel Coûts logiciels / résultats Source: US Gov. Accounting Report, (in B. Cox, OO Prog.) 29% 19% 2% 3% 47% Delivered but not used Abandoned or reworked Paid for but not delivered Used after rework Used as delivered Vice-rectorat à la recherche / octobre 2005

Besoin de types plus complexes!
02/04/2017 Besoin de types plus complexes! Caractéristiques d’un 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) C’est la modélisation! Vice-rectorat à la recherche / octobre 2005

Pourquoi modéliser les données ?
02/04/2017 Pourquoi modéliser les données ? L’élaboration d’un algorithme est grandement facilité par l’utilisation 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 l’algorithme 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 Vice-rectorat à la recherche / octobre 2005

Programme = Algorithme + données
02/04/2017 Programme = Algorithme + données Programmes et informations input output information intermédiaire Vice-rectorat à la recherche / octobre 2005

Principe de la modélisation
02/04/2017 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 d’information. Information hiding. Encapsulation Regrouper (enclosure) ensemble des attributs et méthodes qui logiquement ont une affinité (coupling & cohesion). Masquage d’information Cacher les secrets d’une 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. Vice-rectorat à la recherche / octobre 2005

Encapsulation vs Masquage d’information
02/04/2017 Encapsulation vs Masquage d’information Encapsulation Regrouper (enclosure) ensemble des attributs et méthodes qui logiquement ont une affinité (coupling & cohesion). Masquage d’information Cacher les secrets d’une implémentation. Un n’implique pas nécessairement l’autre, mais dans l’usage courant, les deux concepts sont souvent interchangés. Avec le temps, ils sont devenus des synonymes. Vice-rectorat à la recherche / octobre 2005

Encapsulation vs Masquage d’information
02/04/2017 Encapsulation vs Masquage d’information L’encapsulation 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 d’exemple, le mot-clé Java correspondant) pour les différents composants d’une classe (variables d’instance et méthodes): publique (public) : visible de partout protégée (protected) : visible à l’inté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. Vice-rectorat à la recherche / octobre 2005

Construction d’un modèle
Modélisation: Réalité  Modèle

Modélisation: Réalité  Modèle 

Modélisation: Réalité  Modèle  

Modélisation: Réalité  Modèle x   

02/04/2017 Construction d’un modèle Modélisation: Réalité  Modèle x    float x; Vice-rectorat à la recherche / octobre 2005

02/04/2017 Construction d’un modèle Modélisation: Réalité  Modèle x    struct Pt { float x; float y; float z; } ;  float x; Vice-rectorat à la recherche / octobre 2005

02/04/2017 Construction d’un modèle Modélisation: Réalité  Modèle x    struct Pt { float x; float y; float z; } ; struct Plan { pt p[4]; } ;   float x; Vice-rectorat à la recherche / octobre 2005

02/04/2017 Construction d’un modèle Modélisation: Réalité  Modèle x    struct Pt { float x; float y; float z; } Pt; struct Boite { Plan pl[6]; }; struct Plan { Pt p[4]; };    float x; Vice-rectorat à la recherche / octobre 2005

02/04/2017 Construction d’un modèle Modélisation: Réalité  Modèle x    struct Pt { float x; float y; float z; }; struct Boite { Plan pl[6]; }; struct Plan { Pt p[4]; }; Boite b1;     float x; Vice-rectorat à la recherche / octobre 2005

Modélisation = transfert
02/04/2017 Modélisation = transfert Modélisation: Réalité  Modèle  Boite b1; … b1.rotation(b1,45); Vice-rectorat à la recherche / octobre 2005

Création d’un modèle Modélisation: modèle près de la réalité
02/04/2017 Modélisation: modèle près de la réalité modèle distant des détails d’implantation Boite b1; … b1.rotation(b1,45); struct boite { Plan pl[6]; }; struct Plan { Pt p[4]; }; struct Pt { float x; float y; float z; }; float x; Vice-rectorat à la recherche / octobre 2005

Les types de données abstraites (TDA)
02/04/2017 Les types de données abstraites (TDA) Modélisation: modèle près de la réalité modèle distant des détails d’implantation boîte noire Boite b1; … b1.rotation(b1,45); typedef struct { plan pl[6]; } boite; typedef struct { pt p[4]; } plan; typedef struct { float x; float y; float z; } pt; float x; Vice-rectorat à la recherche / octobre 2005

Programme indépendant de l’implantation 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! Un type de données abstrait modélise l’« ensemble des services » désirés plutôt que l’organisation intime des données (détails d’implémentation). Il est caractérisée par : son contenu les interactions possibles (manipulation, accès, ...)

Un type abstrait: est défini uniquement par ses conventions d’utilisation 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 d’implantation choisi sert à isoler les programmes des données (structuration interne) crée une indépendance des applications face aux modèles d’implantation (continuité de la programmation structurée) permet l’encapsulation de la définition d’un type

02/04/2017 Les types de données abstraites (TDA) Un type abstrait: C’est un objet créée à partir d’un ensemble de données organisé et reliées logiquement pour que: les spécifications de cet objet et des opérations associées soient séparées de leur représentation interne et de la mise en œuvre des opérations. La notion de type de données abstrait (T.D.A.) est indépendante de tout langage de programmation. Les TDA généralisent les types prédéfinis Nés de préoccupation de génie logiciel abstraction encapsulation vérification de types Vice-rectorat à la recherche / octobre 2005

02/04/2017 Les types de données abstraites (TDA) Préoccupation de génie logiciel se placer à un niveau d'abstraction élevé é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 (l’interface) pas la représentation interne Indépendance programmes/données Vice-rectorat à la recherche / octobre 2005

Indépendance programmes/données:

Indépendance programmes/données: modularité de développement

Indépendance programmes/données: modularité de développement facilité d’assemblage de modules

Indépendance programmes/données: modularité de développement facilité d’assemblage de modules validation modulaire et continue

Indépendance programmes/données: modularité de développement facilité d’assemblage de modules validation modulaire et continue Réutilisation

Indépendance programmes/données: modularité de développement facilité d’assemblage de modules validation modulaire et continue Réutilisation Évolution

Indépendance programmes/données: modularité de développement facilité d’assemblage de modules validation modulaire et continue Réutilisation Évolution coût d’entretien

Préoccupation de génie logiciel
02/04/2017 Préoccupation de génie logiciel Qualités d’un logiciel valide : réalise exactement les tâches définies par la spécification robuste : fonctionne même dans des conditions anormales fiable : valide + robuste extensible : s'adapte aux changements de spécification réutilisable : en tout ou en partie dans de nouvelles applications, par d’autres compatible : peut être combiné avec d'autres autres : efficace, portable, vérifiable, facile d'utilisation Vice-rectorat à la recherche / octobre 2005

02/04/2017 Préoccupation de génie logiciel Maintenance Partie immergée de l'iceberg Estimation adaptation à l'évolution des besoins (42 %) modification des formats de données (17 %) corrections d'erreurs urgentes (12 %) corrections d'erreurs mineures (9 %) modification de matériel (6 %) documentation (5 %) amélioration de l'efficacité (4 %) Vice-rectorat à la recherche / octobre 2005

02/04/2017 Préoccupation de génie logiciel Programmer aujourd’hui Bidouilleur génial isolé quelque fois utile souvent considéré comme une calamité en un mot : ringard Membre d'une équipe doit maintenir ou faire évoluer ou réutiliser du code écrit par d'autres doit s'adapter aux utilisateurs doit choisir et utiliser sur des gros projets des bibliothèques de code déjà écrit des ateliers de génie logiciel des normes de qualité, guides de style, "design patterns" Vice-rectorat à la recherche / octobre 2005

02/04/2017 Préoccupation de génie logiciel Programmer aujourd’hui Règle empirique des (80-20) Un programmeur passe 90 % de son temps sur 10 % du code. Sur ces 10 % l'efficacité est cruciale : chercher à optimiser le code s'intéresser à la représentation interne Pour le reste du programme les autres critères sont primordiaux : lisibilité, maintenance etc. rester à un niveau d'abstraction élevé. Vice-rectorat à la recherche / octobre 2005

Spécifications des types de données abstraits
02/04/2017 Spécifications des types de données abstraits Du point de vue informatique, un type de données abstraite peut être spécifié à deux niveaux : niveau fonctionnel / logique : spécification formelle des données et des algorithmes de manipulation associés niveau physique (programmation) : comment est implémentée le type de données abstraite dans la mémoire de la machine déterminant pour l’efficacité des programmes utilisant ces données. Vice-rectorat à la recherche / octobre 2005

02/04/2017 Spécifications des types de données abstraits Au niveau formel (modèle), on veut généraliser cette idée « d’objets » manipulables par des opérateurs propres, sans forcément en connaître la structure interne et encore moins l’implémentation. Par exemple, vous ne pensez pas un int comme une suite de 32 bits, mais bien comme un « entier » (dans un certain intervalle) avec ses opérations propres : +, -, *, / Une structure de données abstraite définit une abstraction des données et cache les détails de leur implémentation. Abstraction : identifier précisément les caractéristiques de l’entité (par rapport à ses applications), et en décrire les propriétés. Vice-rectorat à la recherche / octobre 2005

02/04/2017 Spécifications des types de données abstraits On identifie usuellement 4 types de « services » : 1. les modificateurs, qui modifient le T.D.A. 2. les sélecteurs, qui permettent « d’interroger » le T.D.A. 3. les itérateurs, qui permettent de parcourir la structure 4. les constructeurs (que l’on verra plus tard) Exemple : tableau dynamique modifieur : affectation d’un élément (t[i]=a) sélecteur : lecture d’un élément (t[i]) sélecteur : le tableau est-il vide ? (t.size() == 0) itérateur : index d’un élément ([i] ci-dessus) Vice-rectorat à la recherche / octobre 2005

Incarnation d’un TDA L’interface (fichier .h)
02/04/2017 Incarnation d’un 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. L’interface (fichier .h) Et la définition (i.e le code) des opérations primitives dans un langage particulier L’implé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. Vice-rectorat à la recherche / octobre 2005

L’interface main() Communication programmes/données: programme données

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

L’interface main() Avec des types structurés: interface programme
données boite b1; rotation(b1,45); interface Boite b1; rotation, poseSur, ...

L’interface main() données programme Interface =
int x, y; y = x + 1; Interface = ensemble de fonctions de manipulation d’objets d’un type abstrait (convention + comportement) { prototypes} + spécifications formelles

Programmation d’un type abstrait
programme données choix d’un modèle d’implantation interface spécification formelle d’un type abstrait indépendants!!!

Spécifications « langage C »
L  L +i x prototype de la fonction implantant l’opé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 l’application (correcte) de l’opé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 l’application de l ’opérateur: l mise à jour ou l inchangée en cas d'erreurs

Spécifications « C++ » prototype de la méthode implantant l’opérateur:
L  L +i x prototype de la méthode implantant l’opé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 l’application (correcte) de l’opé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 d’un problème si L est pleine, si i  [1,|L|+1] valeur retournée en output de l’application de l ’opérateur: aucune

Spécifications version dOxygen
L  L +i x prototype de la méthode implantant l’opérateur: void ajouterListe(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 */

Modèles d’implantation
Choix d’un modèle d’implantation: Besoins de l’application: temps de réponse volume de données volatilité des données Ressources disponibles: temps CPU espace-mémoire systèmes d’exploitation et architecture du système complexité: temps de développement, d’implantation et de mise à jour

Utilisation d’un type abstrait
Interface de communication Interface explicite (publique) Masquage des informations Offrir des opérateurs sans connaître les détails de l’implémentation Factoriser le code de l’implémentation des opérateurs: fonctions privées. Fonctions main() Interface Données

Utilisation d’un type abstrait
Quand on développe une structure, on doit le considérer comme un « type abstrait », c’est-à-dire dont la spécification ne dépend pas de l’implémentation. Pour établir cette spécification (qui risque moins de changer que l’implé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 d’employer une convention sur la façon de documenter les fonctions. La convention de documentation la plus utilisée à l’heure actuelle est sans doute celle employée par l’utilitaire Doxygen Doxygen permet de générer automatiquement, à partir du code, une documentation dans un format pratique (le plus souvent html).

Avantages des TDA Écriture de programmes en couches :
02/04/2017 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 Vice-rectorat à la recherche / octobre 2005

Avantages des TDA Théorie du contrat Respect de la théorie du contrat
02/04/2017 Avantages des TDA Respect de la théorie du contrat Théorie du contrat Non-respect de la théorie du contrat // Nombres.h #define MAX 1000 typedef struct { float t[MAX]; int nb; } Nombres; // SuperProg.c #include ‘’Nombres.h’’ int main() Nombres mes_nombres; mes_nombres.nb=3; mes_nombres.t[0]=33.12f; mes_nombres.t[1]=2537.6f; mes_nombres.t[1]=302.5f; return 0; } Vice-rectorat à la recherche / octobre 2005

Avantages des TDA Code changé pour un tableau dynamique Code originel
02/04/2017 Avantages des TDA Code originel Code changé pour un tableau dynamique Vice-rectorat à la recherche / octobre 2005

Avantages des TDA Non-respect de la théorie du contrat
02/04/2017 Avantages des TDA Non-respect de la théorie du contrat 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 d’une structure devient impossible dès que le logiciel prend de l’envergure. L’idé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 l’existence de tel membre. Plus difficile à réaliser pour un débutant. Ça facilite les changements de conception de structures. Vice-rectorat à la recherche / octobre 2005

02/04/2017 Théorie du contrat Cela est peu convaincant avec un si petit exemple, mais lorsque le programme devient un peu plus grand, cela a un impact majeur sur la réussite d’un projet. On doit toujours favoriser la simplicité et la durée de vie du code qui utilise les structures, et non pas du code qui implémente ces structures. Vice-rectorat à la recherche / octobre 2005

Théorie du contrat en C++
02/04/2017 Théorie du contrat en C++ À quoi bon retourner un code d’erreur quand la fonction retourne toujours le même? CodeErreur initNombres(Nombres *nombres) { nombres->nb=0; return OK; } C’est pour préparer un éventuel changement pour une implémentation où on pourrait imaginer qu’une erreur survienne (un manque de mémoire par exemple) à l’initialisation. Vice-rectorat à la recherche / octobre 2005

02/04/2017 Théorie du contrat en C++ À quoi bon faire une fonction de destruction vide? CodeErreur detruireNombres(Nombres *nombres) { return OK; } C’est pour préparer une éventuelle implémentation où on aurait vraiment quelque chose à faire (libérer de la mémoire, sans doute) lorsque l’objet n’est plus utilisé. Vice-rectorat à la recherche / octobre 2005

02/04/2017 Théorie du contrat en C++ Le langage C++ permet de faire en sorte que le compilateur interdisse l’utilisation de certains membres de structures, par le mot-clé « private ». Aussi, les fonctions peuvent être placées à l’intérieur-même de la structure, évitant ainsi d’avoir à passer un paramètre supplémentaire à chaque fonction. Vice-rectorat à la recherche / octobre 2005

02/04/2017 En C++ Vice-rectorat à la recherche / octobre 2005

02/04/2017 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. Vice-rectorat à la recherche / octobre 2005

Les types abstraits n ’y a-t-il pas d’opérations contradictoires ?
02/04/2017 Les types abstraits On doit également toujours se poser les deux questions suivantes dans la conception d’un type abstrait : n ’y a-t-il pas d’opérations contradictoires ? consistance a-t-on donné un nombre suffisant d’opérations pour décrire toutes les propriétés du type abstrait que l’on voulait spécifier au départ ? complétude Vice-rectorat à la recherche / octobre 2005

Types Abstraits et l’Orienté-Objet
02/04/2017 Types Abstraits et l’Orienté-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 Vice-rectorat à la recherche / octobre 2005

Cours de structures de données
interface données programme spécification formelle d’un type abstrait choix d’un modèle d’implantation Programmeur d’application Gestionnaire de données Cours de structures de données

Tâches à maîtriser interface données programme spécification formelle
d’un type abstrait choix d’un modèle d’implantation Programmeur d’application Gestionnaire de données

Tâches à maîtriser interface données programme 1
spécification formelle d’un type abstrait choix d’un modèle d’implantation Programmeur d’application Gestionnaire de données 1 Analyse: -besoins -contraintes

Tâches à maîtriser interface données programme 1 2
spécification formelle d’un type abstrait choix d’un modèle d’implantation Programmeur d’application Gestionnaire de données 1 Analyse: -besoins -contraintes 2 Conception: -choisir un modèle d ’implantation -réaliser l’implantation

Tâches à maîtriser interface données programme 2.1 1 2
spécification formelle d’un type abstrait choix d’un modèle d’implantation Programmeur d’application Gestionnaire de données 2.1 1 Analyse: -besoins -contraintes 2 Conception: -choisir un modèle d ’implantation -réaliser l’implantation

Tâches à maîtriser interface données programme 2.2 2.1 1 2
spécification formelle d’un type abstrait choix d’un modèle d’implantation Programmeur d’application Gestionnaire de données 2.2 2.1 1 Analyse: -besoins -contraintes 2 Conception: -choisir un modèle d ’implantation -réaliser l’implantation

Construction d’une structure de données (TDA)
//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.. Interface en C++ // Fichier Liste.h #include <iostream> using namespace std; #ifndef _LISTEC__H #define _LISTEC__H #define MAX_LISTE 100 class Liste { private: int tab[MAX_LISTE]; int cpt; public: Liste(); //constructeur ~Liste(); //destructeur void ajouter (int x, int pos) throw(range_error, length_error); int taille() const ; bool estVide() const; //etc… }; #endif Interface en C++

Synthèse

Types de données abstrait
Type Abstrait Opérations ou Services fournies sur des structures de données convention, contraintes, domaine de valeurs) + {opérateurs} Permet d ’obtenir les qualités attendues d ’un logiciel d’aujourd’hui (extensibilité, réutilisabilité, compatibilité) Donner des garanties Réduire la complexité Faire de grands programmes en équipe L’idée : si un programme marche avec une abstraction de données, il pourrait marcher avec une autre, si l’autre a la même interface.

Mais pas nécessairement par les mêmes personnes
Le type abstrait Un type abstrait peut être : Défini Implanté Utilisé Mais pas nécessairement par les mêmes personnes

Le type abstrait Un type abstrait peut être : Défini
L’analyse du problème mène à définir un type abstrait. La définition se fait sans penser à l’implantation (indépendance de l’implantation) Les spécifications formelles. Implanté Utilisé

Le type abstrait Un type abstrait peut être : Défini Implanté
Il y a différente façon d’implanter, le choix dépend de plusieurs facteurs (besoins, ressources, …) Les commentaires d’implémentation. Utilisé

Le type abstrait Un type abstrait peut être : Défini Implanté Utilisé
L’utilisateur n’a pas à connaître le choix d’implantation. L’utilisateur a accès uniquement aux spécifications formelles du type abstrait.

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 d’algorithmes (notation asymptotique) Écriture de programmes lisibles et efficaces (complexité) Nous ne traiterons pas les problèmes d’optimisation de code

Discussion sur le plan de cours
Contenu du cours Évaluations Compilateurs, OS Manuel, site Web, liste de diffusion, forum, courriel Laboratoires, autres exercices SVN, dOxygen, Eclipse sous Linux Conseils..

Le point sur les normes de programmation
Commentaires d’interface Commentaires d’implémentation Découpage logique d’un programme La gestion des exceptions Style de programmation

Commentaires d’interface (style Doxygen) /** * \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 out_of_range si la position est erronée * \exception length_error si pas assez de mémoire */ void ajouter(…,int x, int pos) throw(out_of_range, length_error);

Commentaires d’implémentation (style Doxygen) /** * \fn void ajouter (…, int x, int pos) * * \param[in] x Élément à ajouter * \param[in] pos Position où insérer l'élément */ void ajouter(…,int x, int pos) throw(out_of_range, length_error) { … }

Structures de données IFT-10541

Présentations similaires

Présentation au sujet: "Structures de données IFT-10541"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Structures de données IFT-10541

Présentations similaires

Présentation au sujet: "Structures de données IFT-10541"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back