180
INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE OBJET Chapitre 5 : TYPES ABSTRAITS DE DONNEES Chapitre 6 : LA STRUCTURE STATIQUE: LES CLASSES Chapitre 7 : LA STRUCTURE A L'EXECUTION: LES OBJETS Chapitre 8 : GENERICITE Chapitre 9 : CONSTRUIRE DU LOGICIEL FIABLE Chapitre 10 : INTRODUCTION A L'HERITAGE

INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Embed Size (px)

Citation preview

Page 1: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

INTRODUCTION A LA METHODOLOGIE OBJET

Chapitre 1 : LA QUALITE DU LOGICIEL

Chapitre 2 : MODULARITE

Chapitre 3 : REUTILISABILITE

Chapitre 4 : VERS LA TECHNOLOGIE OBJET

Chapitre 5 : TYPES ABSTRAITS DE DONNEES

Chapitre 6 : LA STRUCTURE STATIQUE: LES CLASSES

Chapitre 7 : LA STRUCTURE A L'EXECUTION: LES OBJETS

Chapitre 8 : GENERICITE

Chapitre 9 : CONSTRUIRE DU LOGICIEL FIABLE

Chapitre 10 : INTRODUCTION A L'HERITAGE

Page 2: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 1 : LA QUALITE DU LOGICIEL

1.1 INTRODUCTION

1.2 FACTEURS EXTERNES

1.3 DE LA MAINTENANCE LOGICIELLE

Page 3: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

1.1 INTRODUCTION

Facteurs internes: perceptibles par les informaticiens

modularité

lisibilité

complexité

Facteurs externes: appréciés par les utilisateurs

Page 4: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

1.2 FACTEURS EXTERNES

Correction: capacité que possède un produit logiciel de mener à bien sa tâche, telle qu'elle a été définie par sa spécification

Validation de la correction par couches4) Système applicatif

4.4) Bibliothèque d'applications4.3) Autres bibliothèques4.2) Bibliothèque de base4.1) Bibliothèque noyau

3) Compilateur2) Système d'exploitation1) Matériel

Page 5: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Robustesse: capacité qu'offrent des systèmes logiciels à réagir de manière appropriée à la présence de conditions anormales

Un cas anormal correspond simplement à un cas qui n'est pas couvert par la spécification

Le système ne peut causer de catastrophes; il doit fournir des messages d'erreur appropriés ou entrer dans un mode appelé "dégradation harmonieuse"

Page 6: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Extensibilité: facilité d'adaptation des produits logiciels aux changements de spécifications

La base de tout logiciel repose sur une intervention humaine et son cortège de caprices. Il faut donc:

simplicité de conception: une architecture simple sera toujours plus facile à adapter aux changements

décentralisation: une modification d'un module aura d'autant moins d'incidence sur les autres modules que celui-ci sera autonome, évitant ainsi le déclenchement d'une réaction en chaîne de changements dans l'ensemble du système.

Page 7: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Réutilisabilité: capacité des éléments logiciels à servir à la construction de plusieurs applications différentes

Les systèmes logiciels suivent souvent les mêmes modèles.

Il devrait être possible d'exploiter ces ressemblances et d'éviter de réinventer des solutions à des problèmes qui se sont déjà posés

Page 8: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Compatibilité: facilité avec laquelle des éléments logiciels peuvent être combinés à d'autres

Parmi les approches possibles, on trouve:

Les formats de fichiers standardisés

Les structures de données standardisées

Les interfaces utilisateur standardisées

Page 9: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Efficacité: capacité d'un système logiciel à utiliser le minimum de ressources matérielles, que ce soit le temps machine, l'espace occupé en mémoire externe et interne, ou la bande passante des moyens de communication

Certains développeurs sont obsédés par les questions de performance, ce qui les pousse à dépenser beaucoup d'efforts dans de soi-disant optimisations.

Mais une autre faction tend à minimiser l'importance de la performance. "Faites bien les choses avant de les faire vite"

Page 10: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Portabilité: facilité avec laquelle des produits logiciels peuvent être transférés d'un environnement logiciel ou matériel à un autre

Une grande partie des incompatibilités entre plate-formes n'est pas justifiée mais elle existe !

Quelle qu'en soit la cause, cette diversité fait que la portabilité reste une préoccupation majeure des développeurs et des utilisateurs de logiciel.

Page 11: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Facilité d'utilisation: facilité avec laquelle des personnes présentant des formations et des compétences différentes peuvent apprendre à utiliser les produits logiciels et à s'en servir pour résoudre des problèmes. C'est aussi la facilité d'installation, d'opération et de contrôle.

D'où, "Ne prétendez pas connaître l'utilisateur; vous ne le connaissez pas"

Page 12: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Fonctionnalité: étendue des possibilités offertes par un système

Le problème le plus difficile est d'éviter d'être tellement obnubilé par les détails que l'on en oublie les autres qualités

Page 13: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Ponctualité: capacité d'un système logiciel à être livré au moment désiré ou avant

Vérifiabilité: facilité à préparer les procédures de recette, en particulier les jeux de tests, ainsi que les procédures permettant de détecter les erreurs

Intégrité: capacité que présentent certains systèmes logiciels à protéger leurs divers composants contre les accès et modifications non autorisés

Réparabilité: capacité à faciliter la réparation des défauts

Economie, cousine de la ponctualité: capacité d'un système à être terminé dans les limites de son budget, ou en deçà

Page 14: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Documentation

externe, qui permet aux utilisateurs de maîtriser la puissance du système et de l'utiliser correctement; c'est une conséquence de la définition de la facilité d'utilisation.

interne, qui permet aux développeurs logiciels de comprendre la structure et l'implémentation du système; c'est une conséquence de l'exigence d'extensibilité.

d'interface de modules, qui permet aux développeurs de comprendre les fonctionnalités offertes par un module sans avoir à en comprendre l'implémentation; c'est une conséquence de l'exigence de réutilisabilité.

Plutôt que de traiter la documentation comme un produit séparé du logiciel, il est préférable de rendre le logiciel aussi auto-documenté que possible

Page 15: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Préoccupations essentielles

 

Toutes les qualités évoquées ci-dessus sont importantes. Mais, dans l'état actuel de l'industrie du logiciel, quatre d'entre elles sont primordiales:

correction et robustesse

extensibilité et réutilisabilité

Page 16: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

1.3 DE LA MAINTENANCE LOGICIELLE

Page 17: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 2 : MODULARITE

2.1 CINQ CRITERES

2.2 CINQ REGLES

2.3 CINQ PRINCIPES

 

Page 18: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

2.1 CINQ CRITERES Une méthode de conception digne d'être appelée "modulaire" devrait répondre à cinq exigences fondamentales:

décomposabilité,

composabilité,

compréhensibilité,

continuité,

protection.

Page 19: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Décomposabilité modulaire: capacité à décomposer facilement un problème logiciel en un petit nombre de sous-problèmes moins complexes, reliés entre eux par une structure simple et suffisamment indépendants pour permettre de travailler séparément sur chacun d'eux.

 

Pour les traitements

Pour les données, donc pas de variables globales

Page 20: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Composabilité modulaire: capacité à produire des éléments logiciels qui peuvent ensuite être combinés librement avec d'autres pour produire de nouveaux systèmes, éventuellement dans un environnement très différent de celui pour lequel ils ont été initialement développés.

 

La composabilité est directement liée à l'objectif de réutilisabilité: le but est de pouvoir transformer le processus de conception du logiciel en un jeu de construction, de telle manière que nous puissions construire des programmes en combinant des éléments préfabriqués standard.

Page 21: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La composabilité est indépendante de la décomposabilité. En fait, ces critères sont souvent contradictoires.

La conception descendante, qui est une technique favorisant la décomposabilité, tend à produire des modules qu'il n'est pas facile de combiner avec des modules provenant d'autres sources.

La méthode suggère, en effet, de développer chaque module pour répondre à un besoin spécifique, correspondant à un sous-problème découvert à un moment précis du processus de raffinement. De tels modules sont souvent étroitement liés au contexte immédiat de leur développement, et donc peu adaptés à d'autres contextes.

Page 22: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Compréhensibilité modulaire: capacité à produire des logiciels dans lesquels un lecteur humain peut comprendre chaque module sans avoir à connaître les autres ou, au pire, après l'examen de quelques uns.

 

L'importance de ce critère découle de son influence sur le processus de maintenance.

Page 23: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Continuité modulaire: si, dans les architectures logicielles, un changement mineur dans la spécification du problème ne déclenche un changement que dans un seul module ou un petit nombre de modules.

 

Ce critère est directement lié à l'objectif général d'extensibilité.

Le terme de "continuité" est tiré d'une analogie avec la notion de fonction continue en analyse mathématique. Une fonction mathématique est continue si (informellement) un petit changement de l'argument entraîne un changement proportionnel dans le résultat.

Page 24: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Protection modulaire: capacité à produire des architectures dans lesquelles l'effet d'une condition anormale se produisant, à l'exécution, dans un module donné sera confiné à ce module ou, au pire, ne se propagera qu'à quelques modules voisins.

 

La question implicite, celle des échecs et des erreurs, est centrale dans le génie logiciel.

Exemple: validation des données à la source. Imposer que chaque module qui utilise des données en entrée soit également responsable de leur validité favorise la protection modulaire.

Page 25: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

2.2 CINQ REGLES

 

Des critères précédents, on déduit cinq règles que nous devons observer pour assurer la modularité:

correspondance directe,

peu d'interfaces,

petites interfaces (couplage faible),

interfaces explicites,

rétention d'information.

Page 26: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Correspondance directe

 

Tout système logiciel cherche à prendre en compte les besoins d'un certain domaine de problèmes. Si vous avez un bon modèle pour décrire ce domaine, c'est une bonne idée de maintenir une correspondance claire entre la structure de la solution, fournie par le logiciel, et la structure du problème, décrite par le modèle. D'où la première règle:

La structure modulaire envisagée lors du processus de construction d'un système logiciel devrait rester compatible avec toute structure modulaire envisagée lors du processus de modélisation du domaine du problème.

Page 27: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Peu d'interfaces

 

La règle de peu d'interfaces restreint le nombre total de canaux de communication entre les modules d'une architecture logicielle:

Chaque module devrait communiquer avec le minimum d'autres modules.

 

Si un système est composé de n modules, le nombre de connexions intermodules devrait rester plus près du minimum, n - l, que du maximum, n (n - 1) /2.

Page 28: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Petites interfaces

 

La règle des petites interfaces, ou "couplage faible", concerne la taille des connexions intermodules plutôt que leur nombre:

Si deux modules communiquent, ils doivent échanger aussi peu d'informations que possible.

Page 29: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Interfaces explicites

Avec la quatrième règle, nous allons un cran plus loin vers la création d'un régime totalitaire dans la société des modules: nous imposons non seulement que toute conversation soit limitée - à quelques participants et à quelques mots, mais nous exigeons aussi que ces conversations soient tenues en public et à haute voix!

Quand deux modules A et B communiquent, cela doit apparaître de manière évidente dans le texte de A, de B ou des deux.

Page 30: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Rétention d'information

 

La règle de rétention d'information peut être explicitée comme suit:

Le concepteur de tout module doit choisir un sous-ensemble des propriétés du module pour représenter l'information officielle de ce module, information qui sera rendue publique aux auteurs des modules clients.

 

L'application de cette règle suppose que chaque module est connu du reste du monde (c'est-à- dire, des concepteurs des autres modules) via une description officielle, correspondant aux propriétés publiques.

Page 31: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Quelles propriétés d'un module devraient être publiques, ou secrètes?

De manière générale, la partie publique devrait inclure la spécification de la fonctionnalité du module; tout ce qui se rapporte à l'implémentation d'une telle fonctionnalité devrait rester secret, pour préserver les autres modules des changements ultérieurs des choix d'implémentation.

Page 32: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

2.3 CINQ PRINCIPES

 

Des règles précédentes, on déduit cinq principes de construction de logiciel:

le principe des unités linguistiques modulaires,

le principe d'autodocumentation,

le principe d'accès uniforme,

le principe ouvert-fermé,

le principe du choix unique.

Page 33: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Unités linguistiques modulaires

 

Le principe d'unités linguistiques modulaires exprime que le formalisme utilisé pour décrire le logiciel aux différents niveaux (spécification, conception, implémentation) doit permettre l'expression de la modularité au niveau envisagé:

Principe: Les modules doivent correspondre aux unités syntaxiques du langage utilisé.

 

Le langage mentionné peut être un langage de programmation, un langage de conception, un langage de spécification, etc. Dans le cas des langages de programmation, les modules devraient être compilables séparément.

Page 34: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Autodocumentation

 

Comme la règle de la rétention d'information, le principe d'autodocumentation gouverne la manière dont nous devrions documenter les modules:

Principe: Le concepteur d'un module devrait s'arranger pour que toute l'information concernant un module soit une partie intégrante du module lui-même. 

Cela élimine la situation fréquente dans laquelle l'information d'un module est maintenue, séparée, dans d'autres documents du projet. La documentation en question ici est la documentation interne concernant les composants du logiciel, pas la documentation utilisateur à propos du produit final.

Page 35: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Accès uniforme

 

Soit x le nom utilisé pour accéder à une certaine donnée (ce que nous appellerons plus tard un objet) et f le nom d'une caractéristique applicable à x.

Par exemple, x peut être une variable représentant un compte en banque, et f la caractéristique qui donne le solde courant du compte. L'accès uniforme concerne la question de savoir comment exprimer le résultat de l'application de f à x, en utilisant une notation qui ne fait pas d'hypothèse prématurée sur la manière dont f est implémentée.

Page 36: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Al) Vous pouvez représenter le solde comme l'un des champs de l'enregistrement décrivant chaque compte. Avec cette technique, chaque opération qui modifie le solde doit prendre soin de mettre à jour le champ balance.

A2) Ou vous pouvez définir une fonction qui calcule le solde en utilisant d'autres champs de l'enregistrement, par exemple les champs représentant les listes de débit et crédit. Avec cette technique, le solde d'un compte n'est pas stocké, mais est calculé à la demande. 

Une notation courante, dans des langages comme Pascal, C, C++ et Java, utilise - x.f dans le cas Al- f (x) dans le cas A2

Page 37: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Dans sa forme générale, le principe peut être exprimé de la façon suivante:

Tous les services offerts par un module devraient être accessibles via une notation uniforme, ne révélant pas s'ils sont implémentés par des moyens de calcul ou de stockage mémoire.

Page 38: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le principe ouvert-fermé

 

Principe: Les modules devraient être à la fois ouverts et fermés.

Un module est dit ouvert s'il est encore extensible. Par exemple, il devrait être possible d'étendre son ensemble d'opérations ou d'ajouter des champs à ses structures de données.

Un module est dit fermé s'il est accessible à d'autres modules. Cela suppose que le module a reçu une description bien définie et stable. Au niveau de l'implémentation, la fermeture d'un module implique également que vous pouvez le compiler, peut-être le stocker dans une bibliothèque, et le rendre accessible aux autres (ses clients).

Page 39: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

L'héritage fournira la solution à cette contradiction.

class A' inherit A redefine f, g, ... end feature f is ... g is .. ... u is ... end

où la clause feature contient à la fois la définition de nouvelles caractéristiques spécifiques à A', comme u, et la redéfinition de caractéristiques (comme f, g, ...) dont la forme dans A' diffère de celle qu'elles avaient dans A.

Le module A reste fermé et, grâce à l'héritage, il peut être ouvert pour donner naissance à un nouveau module étendu A'.

Page 40: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Choix unique

 type PUBLICATION = record auteur, titre: STRING; année_publication: INTEGER; case type_publication: (livre, revue, compte-rendu) of

livre: (éditeur: STRING);revue: (volume, numéro: STRING);compte-rendu: (éditeur, lieu: STRING);

end

Page 41: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La principale observation est que, pour réaliser une telle discrimination, chaque client doit connaître la liste exacte des variantes de la notion de publication représentée par A.

La conséquence est facile à prévoir, Tôt ou tard, vous réaliserez que vous avez besoin d'une nouvelle variante, comme des rapports techniques d'entreprise ou d'université. Il vous faudra alors étendre la définition du type PUBLICATION dans le module A pour prendre en compte ce nouveau cas.

Dans de tels cas, nous devons accepter la possibilité que la liste des variantes, quoique fixée et connue à un moment donné de l'évolution du logiciel, change ensuite par addition ou élimination de variantes.

Page 42: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Principe: Chaque fois qu'un système logiciel doit gérer un ensemble d'alternatives, un module du système, et un seul, devrait en connaître la liste exhaustive.

 

En imposant que la connaissance de la liste des choix soit limitée à un module unique, nous préparons l'environnement des futurs changements: si des variantes sont ajoutées, nous n'aurons qu'à mettre à jour le module qui possède l'information - le point de choix unique. Tous les autres, en particulier ses clients, pourront continuer leurs affaires comme si de rien n'était.

Page 43: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 3 : REUTILISABILITE

 

Suivez le chemin tracé par la conception du matériel! On ne peut plus accepter que chaque nouveau développement parte chaque fois de zéro. Il devrait exister des catalogues de modules logiciels, comme il existe des catalogues de circuits VLSI: pour construire un nouveau système, nous devrions commander des composants sur ces catalogues et les combiner entre eux, plutôt que de réinventer la roue à chaque fois. Nous écririons moins de logiciel, et celui qu'il nous resterait à écrire serait peut-être meilleur.

Page 44: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.1 LES OBJECTIFS DE LA REUTILISABILITE

3.2 CE QUE VOUS DEVRIEZ REUTILISER

3.3 REPETITION DURANT LE DEVELOPPEMENT LOGICIEL

3.4 OBSTACLES NON TECHNIQUES

3.5 LE PROBLEME TECHNIQUE

3.6 CINQ EXIGENCES SUR LES STRUCTURES DE MODULE

Page 45: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.1 LES OBJECTIFS DE LA REUTILISABILITE

 

Bénéfices attendus

Ponctualité

Effort de maintenance diminué

Fiabilité

Efficacité

Cohérence

Investissement

Page 46: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Réutiliser les consommateurs, réutiliser les producteurs

 

Deux aspects de la réutilisabilité:

la vision du consommateur, adoptée par les développeurs d'application qui peuvent s'appuyer sur les composants;

la vision du producteur, celle des groupes qui intègrent la réutilisabilité dans leurs propres développements.

Page 47: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.2 CE QUE VOUS DEVRIEZ REUTILISER

  

Réutilisation de personnel

Réutilisation des conceptions et des spécifications

Les modèles de conception

Réutilisabilité par le code source

Réutilisation de modules abstraits

 

Page 48: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.3 REPETITION DURANT LE DEVELOPPEMENT LOGICIEL

 

Combien de fois, avez-vous, vous-même ou ceux qui travaillent pour vous, écrit un bout de programme qui effectue une recherche dans une table?

La recherche dans une table est définie ici comme le problème consistant à trouver si un élément donné x apparaît dans une table t d'éléments similaires. Le problème admet de nombreuses variantes en fonction des types des éléments, de la représentation de la structure de données t, du choix de l'algorithme de recherche.

Page 49: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.4 OBSTACLES NON TECHNIQUES

 

Le syndrome NIH (Not Invented Here)

L'économie des achats 

Les entreprises du logiciel et leurs stratégies

Accéder aux composants 

Page 50: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.5 LE PROBLEME TECHNIQUE

Changement et stabilité

 recherche (t: TABLE, x: ELEMENT): BOOLEAN is-- Y a-t-il une occurrence de x dans t?localpos: POSITIONdo

frompos := INITIAL_POSITION (x, t)

untilEXHAUSTED (pos, t) or else FOUND (pos, x, t)

looppos := NEXT (pos, x, t)

endResult := not EXHAUSTED (pos, t)end

Page 51: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

3.6 CINQ EXIGENCES SUR LES STRUCTURES DE MODULE

variation de type,

regroupement de routines,

variation d'implémentations,

indépendance de représentation,

factorisation des comportements communs.

Page 52: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Variation de type

 

Le modèle de routine recherche suppose la présence d'une table contenant des objets de type ELEMENT. Une définition particulière utilisera un type spécifique, comme INTEGER ou BANK_ACCOUNT, pour appliquer ce modèle à une table d'entiers ou de comptes en banque.

 

Mais ce n'est pas satisfaisant. Un module de recherche réutilisable devrait être applicable à de nombreux types différents d'éléments, sans exiger que les réutilisateurs aient à effectuer des modifications manuelles du texte du logiciel.

Page 53: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Regroupement de routines

 

Même s'il avait été complètement défini et paramétré par des types, le modèle de routine recherche ne serait pas un composant réutilisable tout à fait satisfaisant.

La manière dont vous parcourez une table dépend de la façon dont elle a été créée, dont les éléments sont insérés ou éliminés.

Ainsi, la routine de recherche n'est pas suffisante en elle-même, en tant qu'unité de réutilisation. Un module réutilisable autosuffisant devrait contenir un ensemble de routines, une pour chacune des opérations citées - création, insertion, élimination, recherche.

Page 54: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Variation d'implémentation

 

Le modèle recherche est très général: il y a en pratique, comme nous l'avons vu, une grande variété de structures de données et d'algorithmes applicables. Nous ne pouvons donc pas espérer qu'un seul module puisse prendre en compte toutes les possibilités: il serait énorme.

Nous aurons besoin d'une famille de modules pour couvrir toutes les implémentations différentes. Une technique générale pour produire et utiliser des modules réutilisables devra admettre cette notion de famille de modules.

Page 55: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Indépendance de représentation

Supposez qu'un module client C d'un certain système applicatif ait besoin de déterminer si un certain élément x apparaît dans une certaine table t (d'investissements, de mots-clés d'un langage, de villes).

L'indépendance de représentation indique ici que C a la capacité d'obtenir cette information par un appel comme

present := recherche (t, x)

sans savoir le genre de table qu'est t au moment de l'appel. L'auteur de C devrait seulement savoir que t est une table d'éléments d'un certain type et que x désigne un objet de ce type.

Que t soit un arbre binaire, une table de hachage ou une liste chaînée lui importe peu.

Page 56: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Factorisation des comportements communs

La diversité des implémentations disponibles dans certains domaines de problèmes conduira typiquement à une solution basée sur une famille de modules. Cette famille est souvent tellement grande qu'il est naturel d'envisager des sous-familles.

Dans le cas de la recherche dans une table, un premier essai de classification pourrait amener à considérer trois grandes sous-familles:

les tables gérées avec une certaine forme de hachage,

les tables organisées comme des arbres d'un type ou d'un autre,

les tables gérées séquentiellement.

Page 57: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

recherche (t: SEQ_TABLE; x: ELEMENT): BOOLEAN is-- Y a-t-il une occurrence de x dans t?

dofrom start untilafter or else found (x)

loopforth

endResult := not afterEnd

start: pour placer le curseur sur le premier élémentforth: pour avancer le curseur d'une positionafter: pour savoir si le curseur s'est déplacé au-delà de la tablefound (x): pour savoir si l'élément sous le curseur a la valeur x.

Page 58: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

start forth after found (x)

Tableau i := 1 i := i + 1 i > count t [ i ] = x

Liste chaînée c := first_cell c := c.right c := Void c.item = x

Fichier rewind read end_of_file f ̂= x

Toutes ces variantes de tables séquentielles partagent la fonction recherche et ne diffèrent que par l'implémentation des quatre opérations de bas niveau.

Une solution satisfaisante au problème de la réutilisabilité doit inclure le texte de recherche en un seul endroit, associé d'une façon ou d'une autre à la notion générale de table séquentielle, indépendamment de tout choix de représentation. Pour décrire une nouvelle variante, tout ce que vous aurez à faire sera de fournir les versions appropriées de start, forth, after et found.

Page 59: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 4 : VERS LA TECHNOLOGIE OBJET

  

4.1 LES INGREDIENTS DU CALCUL

4.2 DECOMPOSITION FONCTIONNELLE

4.3 DECOMPOSITION ORIENTEE OBJET

4.4 CONSTRUCTION DE LOGICIEL ORIENTE OBJET

4.5 PROBLEMATIQUE

Page 60: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

4.1 LES INGREDIENTS DU CALCUL

Trois forces interviennent quand un logiciel effectue un calcul quelconque: exécuter un système logiciel revient à utiliser certains processeurs pour appliquer certaines actions à certains objets.

 

Les processeurs sont des dispositifs de calcul, physiques ou virtuels, qui exécutent des instructions.  

Les actions sont les opérations qui constituent le calcul.  

Les objets sont les structures de données sur lesquelles s'appliquent les actions.

Page 61: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

4.2 DECOMPOSITION FONCTIONNELLE

 

Mérites et limitations de l'approche traditionnelle: utiliser les fonctions comme base d'architecture des systèmes logiciels.  

Continuité

Développement descendant

Pas une fonction unique

Trouver le sommet

Interfaces et conception logicielle

Ordonnancement prématuré

Réutilisabilité

Page 62: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Evaluation de la conception descendante 

La méthode est peu adaptée au développement de systèmes importants. Elle reste un paradigme utile pour de petits programmes et des algorithmes individuels, en particulier dans les cours de programmation.

Mais elle ne se généralise pas aux logiciels pratiques de taille importante. En développant un système de manière descendante, vous gagnez en facilité à court terme ce que vous payerez par une inflexibilité à long terme; vous privilégiez une fonction par rapport aux autres; vous pouvez être conduit à concentrer votre attention sur les caractéristiques de l'interface au lieu de propriétés plus fondamentales; vous perdez de vue l'aspect donnée; et vous risquez de sacrifier la réutilisabilité.

Page 63: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

4.3 DECOMPOSITION ORIENTEE OBJET

 

La justification de l'utilisation des objets comme clé de voûte de la modularisation des systèmes est fondée sur les objectifs de qualité, en particulier l'extensibilité, la réutilisabilité et la compatibilité.

 

Ceci ne devrait pourtant pas nous conduire à éliminer entièrement la notion de fonction. Aucune approche de la construction de logiciel ne peut être complète si elle ne prend en compte à la fois les aspects fonction et objet.

Page 64: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Extensibilité

 

Si les fonctions d'un système ont tendance à changer lors de la vie d'un système, nous est-il possible de trouver une caractérisation plus stable de ses propriétés essentielles, de façon à guider notre choix des modules et atteindre l'objectif de continuité?

Les types des objets manipulés par le système sont des candidats particulièrement prometteurs. Quoiqu'il arrive au système de traitement de la paye du personnel, il continuera probablement toujours à manipuler des objets représentant des employés, des grilles de salaire, des règlements internes, des heures de travail, des chèques.

Page 65: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Réutilisabilité

 

Recherche dans une table: en débutant avec ce qui paraissait être un candidat naturel pour la réutilisation, une routine de recherche, on a noté que nous ne pouvions pas facilement réutiliser une telle routine séparément des autres opérations s'appliquant à une table, comme sa création, l'insertion ou l'élimination.

Mais, si nous essayons de comprendre le cheminement conceptuel qui unit toutes ces opérations, nous trouvons le type des objets auxquels elles s'appliquent - les tables. De tels exemples suggèrent que les types d'objets, associés aux opérations correspondantes, fourniront les unités stables de réutilisation.

Page 66: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Compatibilité

 

Un autre facteur de qualité du logiciel, la compatibilité, a été défini comme étant la facilité avec laquelle les produits logiciels (ici, les modules) peuvent être combinés entre eux.

Il est difficile de combiner des actions si les structures de données sur lesquelles elles opèrent ne sont pas conçues dans cette perspective. Pourquoi, alors, ne pas essayer de combiner des structures de données entières?

Page 67: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

4.4 CONSTRUCTION DE LOGICIEL ORIENTE OBJET

 

Construction de logiciel orienté objet (définition I)

La construction de logiciel orienté objet est la méthode de développement logiciel qui fonde l'architecture de tout système logiciel sur des modules déduits des types des objets qu'il manipule (plutôt que sur la ou les fonctions que le système est supposé remplir).

La devise objet: Ne demandez pas en premier ce que fait le système, demandez à qui il le fait!

Page 68: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

4.5 PROBLEMATIQUE

Comment trouver les types d'objets pertinents?

Comment décrire les types d'objets?

Comment décrire les relations et les similitudes entre les types d'objets?

Comment utiliser les types d'objets pour structurer le logiciel?

Page 69: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Trouver les types d'objets

De nombreux objets ne demandent justement qu'à être cueillis. Ils modélisent directement la réalité physique à laquelle s'applique le logiciel.

Les classes développées précédemment par d'autres.

L'expérience et l'imitation

Page 70: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Décrire types et objets

 

Deux critères doivent nous guider:

La nécessité de fournir des descriptions indépendantes de toute représentation, de peur de perdre le bénéfice principal de la conception fonctionnelle descendante: l'abstraction.

La nécessité de réintroduire les fonctions, en leur donnant une place appropriée dans les architectures logicielles dont la décomposition est essentiellement fondée sur l'analyse des types d'objets puisque nous devrons prendre en compte les deux aspects de la dualité objet-fonction.

Page 71: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Décrire les relations et structurer le logiciel

 

Dans la forme la plus pure de la technologie objet, seules deux relations existent: le client et l'héritage.

Elles correspondent à des familles différentes de dépendance possible entre deux types d'objets A et B:

B est un client de A si chaque objet de type B peut contenir des informations concernant un ou plusieurs objets de type A.

B est un héritier de A si B représente une version spécialisée de A.

Page 72: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 5 : TYPES ABSTRAITS DE DONNEES

5.1 CRITERES

5.2 VARIATIONS D'IMPLEMENTATION

5.3 VERS UNE VUE ABSTRAITE DES OBJETS

5.4 FORMALISER LA SPECIFICATION

5.5 DES TYPES ABSTRAITS DE DONNEES AUX CLASSES

Page 73: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

5.1 CRITERES

Les descriptions devraient être précises et sans ambiguïté.

Elles devraient être complètes - ou au moins aussi complètes que nous le souhaitons dans chaque cas (nous pouvons décider de ne pas préciser certains détails).

Elles ne devraient pas surspécifier.

Page 74: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

5.2 VARIATIONS D'IMPLEMENTATION

 

Représentations des piles

ARRAY_UP : représente une pile par un tableau representation et un entier count dont la valeur varie entre 0 (pour une pile vide) et capacity, la taille du tableau representation; les éléments de la pile sont stockés dans le tableau entre les indices 1 et count.

ARRAY_DOWN : comme ARRAY_UP, mais avec des éléments stockés à partir de la fin du tableau plutôt que depuis le début. Ici, l'entier est appelé free (c'est l'indice de la position libre la plus élevée du tableau, ou 0 si toutes les positions sont occupées) et il varie entre capacity pour une pile vide et 0. Les éléments de la pile sont stockés dans le tableau entre les indices capacity et free + 1.

Page 75: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

LINKED : une représentation en chaîne qui stocke chaque élément dans une cellule possédant deux champs: item représente l'élément, et previous contient un pointeur vers la cellule contenant l'élément empilé précédemment. La représentation utilise également last, un pointeur vers la cellule représentant le sommet.

 

Pour ARRAY_UP et ARRAY_DOWN, les instructions incrémentent ou décrémentent l'indicateur de sommet (count ou free) et affectent x à l'élément correspondant du tableau. Les gardiens suivants sont nécessaires:

if count < capaci ty then ...

if free > 0 then ...

Page 76: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Pour LINKED, empiler un élément nécessite quatre opérations: créer une nouvelle cellule n; affecter x au champ item de la nouvelle cellule; enchaîner la nouvelle cellule au sommet précédent de pile en affectant à son champ previous la valeur courante de last; et mettre à jour last de façon qu'il soit dorénavant attaché à la nouvelle cellule créée.

 

Bien que ce soient les représentations de pile le plus souvent utilisées, il en existe beaucoup d'autres. Choisir l'une d'elles comme "la" définition des piles serait un cas type de surspécification.

Page 77: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

5.3 VERS UNE VUE ABSTRAITE DES OBJETS

Utiliser les opérations

Empiler un élément sur le sommet d'une pile: put.

Ôter l'élément en sommet de pile: remove.

Obtenir l'élément au sommet, si la pile n'est pas vide: item.

Déterminer si la pile est vide ou non.

Création d'une pile initialement vide: make.

Une pile est n'importe quelle structure sur laquelle des clients peuvent appliquer les opérations répertoriées ci-dessus.

Page 78: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

5.4 FORMALISER LA SPECIFICATION

 

Une spécification de type abstrait de données (ADT pour "Abstract Data Type") contient quatre paragraphes:

TYPES,

FONCTIONS,

AXIOMES,

PRÉCONDITIONS.

Page 79: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Spécifier les types

Un type est une collection d'objets caractérisés par des fonctions, des axiomes et des préconditions.  

Un type abstrait de données comme STACK (pour les piles) n'est pas un objet (une pile particulière), mais une collection d'objets (l'ensemble de toutes les piles).

Un objet appartenant à l'ensemble des objets décrits par une spécification d'ADT est appelé une instance de l'ADT. Par exemple, une pile spécifique qui vérifie les propriétés du type abstrait de données STACK sera une instance de STACK.

Page 80: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le paragraphe TYPES répertorie les types introduits dans la spécification. Ici:

TYPES

STACK [G]

 

La spécification concerne un unique type abstrait de données STACK, décrivant des piles d'objets de type arbitraire G.

Page 81: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Généricité

Dans STACK [G], G désigne un type arbitraire, non spécifié. G est appelé un paramètre générique formel du type abstrait de données STACK, et STACK lui-même est appelé un ADT générique.  

En conséquence, un ADT comme STACK n'est pas exactement un type, mais plutôt un schéma de type; pour obtenir un type pile directement exécutable, vous devez obtenir un type d'élément et le fournir comme paramètre générique réel correspondant au paramètre formel G:

STACK [ACCOUNT]

est un type complètement défini.

Page 82: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Répertorier les fonctions

 

FONCTIONS

put: STACK [G] x G → STACK [G]

remove: STACK [G] |→ STACK [G]

item: STACK [G] |→ G

empty: STACK [G] → BOOLEAN

new: STACK [G]

Page 83: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le paragraphe FONCTIONS ne définit pas complètement les fonctions; il n'introduit que leurs signatures - la liste des types des arguments et du résultat. La signature de put est

put: STACK [G] x G → STACK [G]

ce qui indique que put accepte une paire d'arguments de la forme <s, x> où s est une instance de STACK[G] et x est une instance de G, et renvoie comme résultat une instance de STACK [G].

La signature des fonctions remove et item utilise |→ plutôt que la flèche standard utilisée par put et empty. Cette notation exprime le fait que ces fonctions ne sont pas applicables à tous les membres de l'ensemble source.

Page 84: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Catégories de fonctions

Une fonction comme new, dans laquelle un nouveau type T n'apparaît qu'à droite de la flèche, est une fonction de création.

Une fonction comme item et empty, dans laquelle T n'apparaît qu'à gauche de la flèche, est une fonction de requête.

Une fonction comme put ou remove, dans laquelle T apparaît des deux côtés de la flèche, est une fonction de commande.

Une autre proposition terminologique appelle ces trois catégories "constructeur", "accédeur" et "modificateur".

Page 85: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le paragraphe AXIOMES

Pour indiquer que nous avons une pile, et non une autre structure de données, la spécification de l'ADT donnée jusqu'à présent n'est pas suffisante. Toute structure "distributeur", comme une file premier entré-premier sorti, y correspond.

AXIOMES (d'une pile)

Pour tout x: G, s: STACK [G],

A1 : item (put (s, x)) = x

A2 : remove ((put (s, x)) = s

A3 : empty (new)

A4 : not empty (put (s, x))

Page 86: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Les fonctions partielles

 

La spécification de tout exemple réaliste, même aussi simple que les piles, rencontre le problème qu'introduisent les opérations non définies: certaines opérations ne sont pas applicables à tout élément possible de leur ensemble source. Ici, c'est le cas de remove et item: vous ne pouvez pas dépiler un élément d'une pile vide; et une pile vide n'a pas de sommet.

 

Le domaine d'une fonction partielle de X |→ Y est le sous-ensemble de X qui contient les éléments pour lesquels la fonction renvoie une valeur. Cela soulève un nouveau problème: comment spécifier les domaines de ces fonctions?

Page 87: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Préconditions

 

Toute spécification d'ADT qui contient des fonctions partielles doit spécifier le domaine de chacune d'entre elles. C'est le rôle du paragraphe PRECONDITIONS.

PRECONDITIONS

remove (s: STACK [G]) require not empty (s)

item (s: STACK [G]) require not empty (s)

où, pour chaque fonction, la clause require indique les conditions que les arguments de la fonction doivent vérifier pour appartenir au domaine de la fonction.

Page 88: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Spécification de l'ADT des piles

TYPESSTACK [G]

FONCTIONSput: STACK [G] x G → STACK [G]remove: STACK [G] |→ STACK [G]item: STACK [G] |→ Gempty: STACK [G] → BOOLEANnew: STACK [G]

AXIOMESPour tout x: G, s: STACK [G],

A1 : item (put (s, x)) = xA2 : remove ((put (s, x)) = sA3 : empty (new)A4 : not empty (put (s, x))

PRECONDITIONSremove (s: STACK [G]) require not empty (s)

item (s: STACK [G]) require not empty (s)

Page 89: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

5.5 DES TYPES ABSTRAITS DE DONNEES AUX CLASSES

 

Classes

Définition: une classe est un type abstrait de données muni d'une implémentation éventuellement partielle.

Ainsi, pour obtenir une classe, nous devons fournir un ADT et décider d'une implémentation. L'ADT est un concept mathématique; l'implémentation est sa version adaptée à l'ordinateur.

Définition: une classe qui est complètement implémentée est dite effective. Une classe qui n'est implémentée que partiellement, ou pas du tout, est dite retardée.

Page 90: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Comment produire une classe effective

 

Trois genres d'éléments rendront effective une classe:

El: une spécification d'ADT

E2: un choix de représentation

E3: une correspondance entre les fonctions (El) et la représentation (E2) sous la forme d'un ensemble de mécanismes, ou caractéristiques ("features"), où chacun implémente une des fonctions grâce à la représentation choisie, de manière à vérifier les axiomes et les préconditions. Nombre de ces caractéristiques seront des routines (sous-programmes) au sens usuel du terme, bien que certaines puissent apparaître sous forme de champs de données, ou "attributs".

Page 91: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Exemple: si l'ADT est STACK (E1) et la représentation ARRAY_UP qui implémente toute pile par une paire

<representation, count> où representation est un tableau et count un entier (E2),

pour les implémentations des fonctions (E3), nous aurons des "features" correspondant à put, remove, item, empty et new, qui réalisent les effets souhaités; par exemple, nous pouvons implémenter put par une routine de la forme put (x: G) is

-- Empiler x sur la pile.-- (Pas de vérification de débordement possible de pile.)

docount := count + 1representation [count] := x

end

Page 92: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le rôle des classes retardées

Si des informations d'implémentation (E2, E3) sont manquantes, la classe est retardée. Les classes retardées sont particulièrement utiles:

en analyse OO, aucun détail d'implémentation n'est nécessaire, ni souhaitable

en conception OO, de nombreux aspects de l'implémentation sont négligés car la conception doit se concentrer sur les fonctionnalités à fournir par chaque module et non comment les fournir

plus la conception se rapproche d'une implémentation complète, plus on ajoute des propriétés d'implémentation jusqu'à l'obtention de classes effectives.

Page 93: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Types abstraits de données et rétention d'information

 

Si le module est une classe provenant d'un ADT, sur les trois parties présentes dans la transition,

El, la spécification de l'ADT, est publique;

E2 et E3, le choix de représentation et l'implémentation de l'ADT, devraient être secrètes.

Page 94: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Introduire une vision plus impérative

put (x: G) is-- Empiler x sur le sommet de pile

require... La précondition, si nécessaire...

do... L'implémentation appropriée, si connue...

ensureitem = xnot empty

end

D'autres axiomes de la spécification de l'ADT donneront une clause appelée invariant de classe.

Page 95: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Construction de logiciel orienté objet

 

Définition II

La construction de logiciel orienté objet est l'élaboration de systèmes logiciels vus comme

des collections structurées d'implémentations,

éventuellement partielles,

de types abstraits de données.

Page 96: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La base est la notion de type abstrait de données.

Pour un logiciel, nous n'avons pas besoin d'ADT en soi, faisant référence à une notion mathématique, mais d'une implémentation d'ADT, une notion logicielle.

Ces implémentations, cependant, n'ont pas à être complètes; la qualification "éventuellement partielle" recouvre les classes retardées - ce qui comprend le cas extrême d'une classe complètement différée, dans laquelle aucune caractéristique n'a été implémentée.

Un système est une collection de classes, sans que l'une d'elles occupe une position principale - pas de programme principal ou de sommet.

La collection est structurée, grâce aux deux relations inter-classes: client et héritage.

Page 97: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 6 : LA STRUCTURE STATIQUE: LES CLASSES

6.1 LE SUJET N'EST PAS LES OBJETS

6.2 LE ROLE DES CLASSES

6.3 UN SYSTEME DE TYPES UNIFORME

6.4 UNE CLASSE SIMPLE

6.5 LE STYLE ORIENTE OBJET DE CALCUL

6.6 EXPORTATIONS SELECTIVES ET RETENTION D'INFORMATION

6.7 REGROUPER LE TOUT

Page 98: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.1 LE SUJET N'EST PAS LES OBJETS

 

Quel est le concept central de la technologie objet? Les objets sont certes importants pour décrire l'exécution d'un système orienté objet. Mais la base sur laquelle repose l'ensemble de la technologie orientée objet est la classe. 

Les types abstraits de données sont une notion mathématique, adaptée à l'étape de spécification (appelée aussi analyse). Parce qu'elle conduit à des implémentations, partielles ou totales, la notion de classe établit le lien nécessaire avec la construction logicielle – conception et implémentation. Rappelez-vous qu'une classe est dite effective si son implémentation est totale, et retardée sinon.

Page 99: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Comme un ADT, une classe est un type: elle décrit un ensemble de structures de données possibles, appelées les instances de la classe.  

La définition d'une "classe" conduit à la définition d'un "objet". Un objet est simplement une instance d'une classe.  

Les textes logiciels qui servent à produire des systèmes sont les classes. Les objets sont une notion n'ayant un sens qu'à l'exécution: ils sont créés et manipulés par le logiciel durant son exécution.

Page 100: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.2 LE ROLE DES CLASSES

 

Pour comprendre l'approche orientée objet, il est essentiel de bien comprendre que les classes jouent deux rôles que les approches pré-OO avaient toujours traités comme distincts: le module et le type.

Les modules et les types

Un module est une unité de décomposition logicielle.

Un type est une description statique de certains objets dynamiques: les divers éléments de données qui seront traités durant l'exécution d'un système logiciel.

Page 101: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La classe comme module et type

 

Dans les approches non OO, les concepts de module et de type restent distincts. La propriété la plus remarquable de la notion de classe est qu'elle généralise ces deux concepts, les fusionnant en une seule construction linguistique. Une classe est un module, ou une unité de décomposition logicielle; mais c'est aussi un type.

 

L'essentiel de la puissance de la méthode orientée objet vient de cette identification. L'héritage, en particulier, ne peut être complètement appréhendé que si nous le considérons comme fournissant à la fois des extensions de module et des spécialisations de type.

Page 102: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.3 UN SYSTEME DE TYPES UNIFORME

 

Règle de l'objet: Tout objet est instance d'une certaine classe.

 

La règle de l'objet s'appliquera non seulement aux objets composés définis par le développeur (comme les structures de données ayant plusieurs champs), mais aussi aux objets de base comme les entiers, les nombres réels, les valeurs booléennes et les caractères, qui seront tous considérés comme des instances de classes prédéfinies de bibliothèque (INTEGER, REAL, BOOLEAN, CHARACTER).

Page 103: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.4 UNE CLASSE SIMPLE (POINT)

Les caractéristiques

Pour caractériser le type POINT comme un type abstrait de données, nous aurons besoin de quatre fonctions de requête x, y, ρ, θ. La fonction x donne l'abscisse d'un point, y son ordonnée, ρ sa distance à l'origine, θ l'angle avec l'axe horizontal. Une autre fonction utile de requête est distance, qui renvoie la distance entre deux points.

La spécification d'ADT préciserait ensuite les commandes comme translate (pour déplacer un point d'une certaine distance horizontale et verticale), rotate (pour tourner le point d'un certain angle autour de l'origine) et scale (pour approcher ou éloigner le point de l'origine selon un certain facteur).

Page 104: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Il n'est pas difficile d'écrire la spécification complète d'ADT qui contient ces fonctions et certains des axiomes associés. Par exemple, deux des signatures de fonctions seront:

x: POINT → REAL

translate: POINT x REAL x REAL → POINT

et l'un des axiomes sera (pour tout point p et tous réels a, b):

x (translate (p, a, b)) = x (p) + a

indiquant que translater un point de <a, b> incrémente son abscisse de a.

Page 105: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Attributs et routines

Un type abstrait de données comme POINT est caractérisé par un ensemble de fonctions, qui décrivent les opérations applicables aux instances de l'ADT. Dans les classes (les implémentations des ADT), les fonctions deviendront des caractéristiques - les opérations applicables aux instances de la classe.

 

Nous avons vu que les fonctions d'ADT sont de trois sortes: les requêtes, les commandes et les créateurs. Pour les caractéristiques, nous avons besoin d'une classification complémentaire, fondée sur la manière dont chacune d'elles est implémentée: par de l'espace mémoire ou du temps de calcul.

Page 106: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

L'exemple des coordonnées des points illustre clairement la différence. Deux représentations courantes sont disponibles pour les points: cartésienne et polaire.

Si nous choisissons la représentation cartésienne, chaque instance de la classe contiendra deux champs représentant le x et le y du point correspondant. Si p est le point indiqué, obtenir son x ou son y ne nécessite qu'un accès au champ correspondant dans sa structure. Obtenir ρ ou θ, cependant, demande un calcul: pour ρ, nous devons calculer (x² + y²) ½ et, pour θ, nous devons calculer arctg (y/x) si x est non nul.

Si nous utilisons la représentation polaire, la situation est renversée: ρ et θ sont maintenant accessibles par simple accès à un champ, x et y demandant de petits calculs (de ρ cos θ et ρ sin θ).

Page 107: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Accès uniforme

Est-il donc approprié de faire une distinction explicite entre attribut et fonction?

Le principe d'accès uniforme, introduit lors de l'étude de la modularité, répond à cette inquiétude. Ce principe indique qu'un client devrait être capable d'accéder à une propriété d'un objet en utilisant une notation unique, que la propriété soit implémentée par de la mémoire ou par du calcul.

L'expression qui désigne la valeur de la caractéristique x pour p sera toujours

p.x

que ce soit pour accéder à un champ d'un objet ou pour exécuter une routine.

Page 108: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La classe POINT

indexingdescription: "Points à deux dimensions"

class POINT featurex, y: REAL -- Abscisse et ordonnéerho: REAL is -- Distance à l'origine (0,0)

doResult := sqrt (x ** 2 + y ** 2)

endtheta: REAL is -- Angle avec l'axe horizontal

do ... enddistance (p: POINT): REAL is -- Distance à

pdo

Result := sqrt ((x - p.x) ** 2 + (y - p.y) ** 2)

end

Page 109: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

translate (a, b: REAL) is -- Déplacer de a horiz.., b vertic.do

x := x + ay := y + b

endscale (factor: REAL) is -- Augmenter d'un facteur factor.

dox := factor * xy := factor * y

endrotate (p: POINT; angle: REAL) is

-- Rotation autour de p de angle.do ... end

end

Page 110: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

D'où vient la fonction sqrt (dans rho et distance)?

Afin de ne polluer pas le langage général avec des opérations arithmétiques spécialisées, la meilleure technique consiste à définir de telles opérations comme des caractéristiques d'une classe spécialisée - disons ARITHMETIC- et de demander simplement que toute classe qui a besoin de ces services hérite de cette classe spécialisée. D'où:

class POINT inheritARITHMETIC

feature... Le reste comme auparavant ...

end

Page 111: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.5 LE STYLE ORIENTE OBJET DE CALCUL

 

L'instance courante

translate (a, b: REAL) is -- Déplacer de a horiz.., b vertic.do

x := x + ay := y + b

end

À première vue, ce texte apparaît suffisamment clair. Mais, nulle part dans le texte nous n'avons précisé de quel point il s'agissait. À qui appartiennent ces x et ces y auxquels nous ajoutons a et b? C'est dans la réponse à cette question que réside l'un des aspects les plus caractéristiques du style de développement orienté objet.

Page 112: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le texte d'une classe décrit les propriétés et le comportement des objets d'un certain type, des points dans cet exemple. Il le fait en décrivant les propriétés et le comportement d'une instance typique de ce type appelée l'instance courante de la classe (Current).

Mais qui est Current? La réponse viendra lors de l'étude des appels de routines. Tant que nous ne regardons que le texte de la routine, il suffit de savoir que toutes les opérations sont relatives, par défaut, à un objet défini implicitement, l'instance courante.

Page 113: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Clients et fournisseurs

 

Comment utiliser une classe comme POINT? Soit on hérite d'elle, soit on devient client.

Définition: Soit S une classe. Une classe C qui contient une déclaration de la forme a: S est un client de S. S est alors un fournisseur de C.

Page 114: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

class GRAPHICS feature pl: POINT ... some_routine is -- Effectuer des actions sur p1

do... Créer une instance de POINT, attachée à p1...pl.translate (4.0, -1.5)

end ...end

Page 115: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Appel de caractéristique

 

pl.translate (4.0, -1.5)

Durant l'exécution d'un système logiciel orienté objet, tout calcul est effectué en appelant certaines caractéristiques sur certains objets.

Cet appel de caractéristique particulier veut dire: appliquer à pl la caractéristique translate de la classe POINT, avec les arguments 4.0 et -1.5, correspondant à a et b dans la déclaration de translate donnée dans la classe.

Page 116: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

L'identification module-type

 

Une classe est à la fois un module et un type; mais comment pouvons-nous réconcilier la notion syntaxique de module (un regroupement de services voisins, formant une partie d'un système logiciel) avec la notion sémantique de type (la description statique de certains objets possibles à l'exécution)?

 

L'exemple de POINT rend la réponse limpide: les services fournis par la classe POINT, considérée comme un module, sont précisément les opérations applicables aux instances de la classe POINT, considérée comme un type.

Page 117: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le rôle de Current

 

Current veut dire: "la cible de l'appel courant". Par exemple, pendant la durée de l'appel ci-dessus, Current désignera l'objet attaché à p1. Dans un appel suivant, Current désignera la cible de ce nouvel appel. Tout ceci a un sens grâce à l'extrême simplicité du modèle de calcul orienté objet, fondé sur des appels de caractéristiques et sur le principe de cible unique:

Principe de l'appel de caractéristique

Aucun élément logiciel n'est jamais exécuté s'il ne fait pas partie d'un appel de routine.

Tout appel a une cible.

Page 118: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.6 EXPORTATIONS SELECTIVES ET RETENTION D'INFORMATION

Exposition complète

class S1 featuref ...g ...

end

les caractéristiques f, g, ... sont accessibles à tous les clients de S1, ce qui veut dire que, dans une classe C, pour une entité x déclarée de type S1, un appel:

x.f ... est valide, sous réserve que l'appel vérifie les autres conditions de validité de f concernant le nombre et les types des arguments, s'il y en a.

Page 119: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Restreindre l'accès aux clients

class S2 featuref ...g ...feature {A, B}h ...

end

La caractéristique h n'est accessible qu'à A et B et à tous leurs descendants (les classes qui héritent directement ou indirectement de A ou B). Cela veut dire que, si x est déclaré avec un type S2, un appel de la forme:

x.h ... est invalide, sauf s'il apparaît dans le texte de A, de B ou d'un de leurs descendants.

Page 120: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

6.7 REGROUPER LE TOUT

Relativité générale

Ce qui est un peu déroutant, c'est que chaque description de ce qui arrive à l'exécution a été, jusqu'à présent, relative. L'effet d'une routine comme translate est relatif à l'instance courante; à l'intérieur du texte de la classe, l'instance courante n'est pas connue. Donc, nous ne pouvons essayer de comprendre l'effet d'un appel que par rapport à une cible spécifique, comme p1 dans:

pl.translate (u, v)

Mais cela soulève la question suivante: que désigne exactement p1? Ici, à nouveau, la réponse est relative. L'appel ci-dessus doit apparaître dans le texte d'une certaine classe, comme GRAPHICS. Mais qui est l'instance courante dans GRAPHICS?

Page 121: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le big-bang 

Définition: l'exécution d'un système logiciel orienté objet comprend les deux étapes suivantes:

créer un objet, appelé objet racine de l'exécution,

appliquer une certaine procédure, appelée procédure de création, à cet objet.

Au moment du big-bang, un objet est créé et la procédure de création est démarrée.

La procédure de création crée de nouveaux objets et appelle des routines sur ceux-ci, déclenchant d'autres créations d'objets et appels de routines, etc.

Page 122: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Systèmes

Pour obtenir un code exécutable, nous devons rassembler les classes en systèmes.

Pour fabriquer un système, nous avons besoin de trois choses:

un ensemble CS de classes, appelé l'ensemble des classes du système,

indiquer quelle classe de CS est la classe racine,

indiquer quelle procédure de la classe racine est la procédure racine de création.

Pour obtenir un système correct, ces éléments doivent vérifier une condition de cohérence, la fermeture du système: toute classe dont a besoin directement ou indirectement la classe racine doit faire partie de CS.

Page 123: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Chapitre 7 : LA STRUCTURE A L'EXECUTION: LES OBJETS

7.1 LES OBJETS

7.2 LES OBJETS: OUTILS DE MODELISATION

7.3 MANIPULER LES OBJETS ET LES REFERENCES

Page 124: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

7.1 LES OBJETS

À tout moment de son exécution, un système OO aura créé un certain nombre d'objets. La structure à l'exécution est l'organisation de ces objets et de leurs relations.  

Qu'est-ce qu'un objet?

Un système logiciel qui contient une classe C peut, en différents points de son exécution, créer des instances de C; une telle instance est une structure de données construite selon le modèle défini par C; par exemple, une instance de la classe POINT introduite dans le chapitre précédent est une structure de données formée de champs associés aux deux attributs x et y déclarés dans la classe. Les instances de toutes les classes possibles constituent l'ensemble des objets.

Page 125: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Forme de base

 

Soit O un objet. Sa définition indique qu'il est instance d'une certaine classe. Plus précisément, c'est une instance directe d'une seule classe, disons C. C est appelée la classe génératrice, ou simplement générateur, de O.

C est un texte logiciel; O est une structure de données à l'exécution, produite par l'un des mécanismes de création d'objets.

Parmi ses caractéristiques, C a un certain nombre d'attributs. Ces attributs déterminent entièrement la forme de l'objet: O est simplement une collection de composants, ou champs, un par attribut.

Page 126: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Champs simples

Les deux attributs de la classe POINT sont de type REAL. En conséquence, chaque champ correspondant d'une instance directe de POINT contient une valeur réelle.

 

C'est un exemple d'un champ correspondant à un attribut ayant un "type de base". Bien que ces types soient formellement définis comme des classes, leurs instances prennent leur valeur dans des ensembles prédéfinis, implémentés efficacement sur les ordinateurs. Parmi ceux-ci, on trouve BOOLEAN, CHARACTER, INTEGER, REAL et DOUBLE.

Page 127: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Une notion simple de livre

 class BOOK1 feature

title: STRIl\lGdate, page_count: INTEGER

end

 

bl: BOOK1

bl.page_count := 355

Page 128: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Ecrivains

 class WRITER feature

name, real_name: STRINGbirth_year, death_year: INTEGER

end

Page 129: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Références

Les objets dont les champs ont tous des types de base ne vont pas nous mener très loin. Nous avons besoin d'objets ayant des champs qui représentent d'autres objets. Par exemple, nous voudrons représenter la propriété selon laquelle un livre a un auteur - indiqué par une instance de la classe WRITER.

class BOOK3 featuretitle: STRINGdate, page_count: INTEGERauthor: WRITER -- C'est le nouvel attribut.

end

Page 130: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE
Page 131: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Définition: une référence est une valeur à l'exécution qui est vide ou attachée. Si elle est attachée, une référence identifie un objet unique.

 

Dans la figure, les champs de référence author dans les instances de BOOK3 sont tous les deux attachés à l'instance de WRITER, comme le montrent les flèches qui sont conventionnellement utilisées dans de tels diagrammes pour représenter une référence attachée à un objet.

Page 132: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Le type utilisé pour déclarer author est simplement le nom de la classe correspondante: WRITER. Il s'agit d'une règle générale: chaque fois qu'une classe est déclarée sous la forme standard:

class C feature ... end

toute entité déclarée de type C grâce à une déclaration de la forme:

x: C

désigne des valeurs qui sont des références aux objets potentiels de type C. Cette convention se justifie par la souplesse d'utilisation des références, qui sont donc plus appropriées dans la grande majorité des cas.

Page 133: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Un aperçu de la structure à l'exécution d'un objet

Page 134: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Une telle complexité à l'exécution n'a pas à affecter la vision statique.

Nous devrions essayer de conserver au logiciel lui-même - l'ensemble des classes et de leurs relations - la plus grande simplicité. Le fait que des modèles simples puissent avoir des instances complexes est, en partie, une conséquence de la puissance des ordinateurs.

Un petit texte logiciel peut décrire un calcul gigantesque; un simple système OO peut, au moment de l'exécution, fournir des millions d'objets connectés par de nombreuses références.

Un objectif primordial du génie logiciel est de maintenir la simplicité du logiciel, même quand ses instances ne le sont pas.

Page 135: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

7.2 LES OBJETS: OUTILS DE MODELISATION

Les quatre mondes du développement logiciel

le système modélisé, aussi appelé système externe (en opposition au système logiciel) et décrit par les types d'objets et les relations abstraites;

une instance particulière du système externe, faite d'objets entre lesquels des relations peuvent exister;

le système logiciel, fait de classes connectées par les relations de la méthode orientée objet (client et héritage);

une structure d'objets, comme celle qui peut exister durant l'exécution du système logiciel, faite d'objets logiciels connectés par des références.

Page 136: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE
Page 137: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

7.3 MANIPULER LES OBJETS ET LES REFERENCES

Création dynamique et rattachement

À partir d'un état initial dans lequel un seul objet a été créé - l'objet racine -, un système exécutera de manière répétitive sur la structure des objets des opérations telles que créer un nouvel objet, attacher une référence précédemment vide à un objet, créer une référence vide ou rattacher à un objet différent une référence précédemment attachée.

La nature dynamique et imprévisible de ces opérations explique, en partie, la flexibilité de l'approche et sa capacité à prendre en compte les structures de données dynamiques qui sont nécessaires si nous voulons utiliser des algorithmes sophistiqués et modéliser les propriétés volatiles des systèmes externes.

Page 138: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

L'instruction de création

 

Cela n'est possible que dans une routine d'une classe qui est client de BOOK3, comme: 

class QUOTATION featuresource: BOOK3page: INTEGERmake_book is

-- Créer un objet BOOK3 et lui attacher source.do

!! source end

end

Page 139: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

L'effet d'une instruction de création de la forme !! x, où le type de la cible x est un type référence fondé sur une classe C, est d'exécuter les trois étapes suivantes:

C1 : Créer une nouvelle instance de C (faite d'une collection de champs, un pour chaque attribut de C). Soit OC cette nouvelle instance.

C2 : Initialiser chaque champ de OC selon les valeurs standards par défaut.

C3 : Attacher la valeur de x (une référence) à OC.

Page 140: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

L'étape C1 créera une instance de C. L'étape C2 positionnera les valeurs de chaque champ à une valeur prédéterminée, qui dépend du type de l'attribut correspondant.

Ainsi, pour une cible source de type BOOK3, l'instruction de création !! source, exécutée comme partie d'un appel à la procédure make_book de la classe QUOTATION, donnera un objet dont

les champs entiers seront initialisés à zéro,

le champ référence pour author sera initialisé à une référence vide et

le champ pour title, une chaîne STRING, sera aussi initialisé à une référence vide. Cela découle du fait que le type STRING est, en fait, également un type référence.

Page 141: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La vue globale

 

Il est important de ne pas perdre le fil de l'ordre dans lequel les événements se produisent. Pour que l'instance ci-dessus de BOOK3 soit créée, les deux événements suivants ont dû avoir lieu:

B1 : Une instance de QUOTATION est créée. Soit Q_OBJ cette instance et soit a une entité dont la valeur est une référence attachée à Q_OBJ.

B2 : Quelque temps après l'étape B1, un appel de la forme a.make_book exécute la procédure make_book en ayant Q_OBJ comme cible.

Page 142: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

CHAPITRE 8 : GENERICITE

8.1 GENERALISATIONS HORIZONTALE ET VERTICALE DE TYPE

8.2 LA NECESSITE DE PARAMETRISATION DE TYPE

8.3 CLASSES GENERIQUES

8.4 TABLEAUX

Page 143: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Pour atteindre nos objectifs d'extensibilité, de réutilisabilité et de fiabilité, il nous faut rendre la construction de classes encore plus flexible, un effort que nous poursuivrons dans deux directions. L'une, verticale, représente l'abstraction et la spécialisation; elle donnera lieu à l'étude de l'héritage; l'autre, horizontale: représente la paramétrisation de type, connue sous le nom de généricité.

Page 144: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

8.1 GENERALISATIONS HORIZ. ET VERTIC. DE TYPE

Les listes représentent un cas spécial de structures "conteneurs", dont les arbres, les piles et les tableaux sont des exemples parmi d'autres. Une variante plus abstraite pourrait être décrite par une classe SET_OF_BOOKS d'ensembles de livres. Une variante plus spécialisée, correspondant à un choix particulier de représentation de liste, pourrait être décrite par une classe LINKED_LIST_OF_BOOKS de listes chaînées de livres. C'est la dimension verticale de notre figure - la dimension d'héritage.

Les listes de livres sont un cas particulier de listes d'objets de toutes sortes. C'est la dimension horizontale de notre figure - la dimension de généricité. Utiliser des paramètres de classe qui représentent des types arbitraires nous dispensera d'écrire de nombreuses classes quasi identiques - comme LIST_OF_BOOKS pour des livres et LIST_OF_PEOPLE pour des personnes - sans sacrifier la sûreté qu'offre le typage statique.

Page 145: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

8.2 LA NECESSITE DE PARAMETRISATION DE TYPE

Types abstraits génériques de données

Notre exemple de travail d'ADT, STACK, a été déclaré comme STACK [G], ce qui indique que toute utilisation réelle vous impose de spécifier un "paramètre générique réel" représentant le type des objets stockés dans une pile donnée. Le nom G utilisé dans la spécification d'ADT représente n'importe quel type possible que peuvent avoir ces éléments de pile; il est appelé paramètre générique formel de la classe. Dans cette approche, vous pouvez utiliser une spécification unique pour toutes les piles possibles.

Page 146: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

La solution de rechange, difficile à accepter, serait d'avoir une classe INTEGER_STACK pour les entiers, une classe REAL_STACK pour les réels et ainsi de suite.

On devrait alors définir:

put (element: INTEGER) is-- Empiler element sur le sommet.

do ... enditem: INTEGER is

-- Article au sommetdo ... end

Page 147: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

8.3 CLASSES GENERIQUES

 

Réconcilier le typage statique avec l'exigence de réutilisabilité pour les classes qui décrivent des structures conteneurs impose, comme l'illustre l'exemple de la pile, que nous puissions à la fois:

déclarer un type pour chaque entité qui apparaît dans le texte d'une classe de pile, y compris les entités représentant des éléments de pile;

écrire la classe de façon qu'elle ne donne aucune information à propos du type des éléments, et qu'elle puisse donc être utilisée pour construire des piles d'éléments arbitraires.

Page 148: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Déclarer une classe générique

indexingdescription: "Piles d'éléments d'un type arbitraire G"class STACK [G] feature count: INTEGER -- Nombre d'éléments dans la pile empty: BOOLEAN is -- N'y a-t-il pas d'éléments?

do ... end full: BOOLEAN is -- La représentation est pleine?

do ... end item: G is -- Elément au sommet

do ... end put (x: G) is -- Ajouter x au sommet

do ... end remove is -- Ôter l'élément au sommet.

do ... endend -- class STACK

Page 149: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Utiliser une classe générique

La déclaration doit fournir des types, appelés paramètres génériques réels - autant de types que la classe utilise de paramètres génériques formels, ici un seul:

sp: STACK [POINT]

Fournir un paramètre générique réel à une classe générique de façon à produire un type est appelé une dérivation générique, et le type résultant est dit être dérivé génériquement.

Une dérivation générique à la fois produit et exige un type:

Le résultat de la dérivation, STACK [POINT] dans cet exemple, est un type.

Pour produire ce résultat, il vous faut un type existant pour servir de paramètre générique réel, POINT dans l'exemple.

Page 150: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

8.4 TABLEAUX

indexingdescription: "Séquence de valeurs, toutes de même type ou de type conforme, accessible par des indices entiers dans un intervalle contigu"

class ARRAY [G] creationmake

featuremake (minindex, maxindex: INTEGER) is -- Allouer un tableau de bornes minindex et maxindex

-- (vide si minindex > maxindex)

do ... endlower, upper, count: INTEGER -- Minimum et maximum d'index légal; taille de tableau.

put (v: G; i: INTEGER) is -- Affecter v à la case d'indice i

do ... enditem (i: INTEGER): G is -- Case d'indice i

do ... endend -- class ARRAY

Page 151: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Pour créer un tableau de bornes m et n, où a est déclaré de type ARRAY [T] pour un type T donné:

!! a.make (m, n)

Pour positionner la valeur d'un élément de tableau:

a.put (x, i) positionne la valeur du i-ème élément à x.

Pour accéder à la valeur d'un élément:

x := a.item (i)

Page 152: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Voici une esquisse de la manière d'utiliser la classe depuis un client:

pa: ARRAY [POINT]; p1: POINT; i, j: INTEGER

...

!! pa.make (-32, 101)

-- Allouer un tableau dont les bornes sont –32 et 101

pa.put (p1, i) -- Affecter p1 à la case d'indice i.

p1 := pa.item (j)

-- Affecter à p1 la valeur de la case d'indice j.

Page 153: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

CHAPITRE 9 : CONSTRUIRE DU LOGICIEL FIABLE

9.1 LES MECANISMES DE BASE DE LA FIABILITE

9.2 A PROPOS DE LA CORRECTION LOGICIELLE

9.3 EXPRIMER UNE SPECIFICATION

9.4 INTRODUIRE DES ASSERTIONS DANS LES TEXTES LOGICIELS

9.5 PRECONDITIONS ET POSTCONDITIONS

9.6 INVARIANTS DE CLASSE

Page 154: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

9.1 LES MECANISMES DE BASE DE LA FIABILITE

 

La structure des systèmes logiciels (architectures simples, modulaires et extensibles).

L'incitation constante à rendre le logiciel élégant et lisible.  

La présence de règles de typage vérifiées statiquement évitant les erreurs de typage à l'exécution.

Page 155: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

9.2 A PROPOS DE LA CORRECTION LOGICIELLE

Un système ou un élément logiciel n'est ni correct ni incorrect en soi; il est correct ou incorrect par rapport à une certaine spécification.  

Il convient donc de pouvoir exprimer de telles spécifications par des assertions.

Page 156: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

9.3 EXPRIMER UNE SPECIFICATION

Formules de correction

Soit A une opération (par exemple une instruction ou un corps de routine). Une formule de correction est une expression de la forme: {P} A {Q}

toute exécution de A, débutant dans un état où P est vérifié, terminera dans un état où Q est vérifié.

P est appelée la précondition et Q la postcondition.

Exemple: si x est une entité entière,

{x >= 9} x := x + 5 {x > 13}

Page 157: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

9.4 INTRODUIRE DES ASSERTIONS DANS LES TEXTES LOGICIELS

 

Puisque la correction d'un élément logiciel a été définie comme étant la cohérence de son implémentation avec sa spécification, nous devrions prendre des mesures pour inclure la spécification, avec son implémentation, dans le logiciel même.  

Pour exprimer la spécification, nous utiliserons des assertions. Une assertion est une expression qui fait intervenir certaines entités du logiciel et qui exprime une propriété à laquelle ces entités doivent satisfaire à certaines étapes de l'exécution du logiciel. Une assertion typique peut exprimer qu'un certain entier a une valeur positive ou qu'une certaine référence n'est pas vide.

Page 158: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

9.5 PRECONDITIONS ET POSTCONDITIONS

indexingdescription: "Piles: Structures distributrices à politique d'accès dernier entré, premier sorti"

class STACK1 [G] feature count: INTEGER -- Nombre d'éléments de pile item: G is -- Elément au sommet

require not emptydo ... end

feature empty: BOOLEAN is -- Pile vide?

do ... end full: BOOLEAN is -- Représentation de pile pleine?

do ... end

Page 159: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

feature -- Elément change put (x: G) is -- Ajouter x au sommet

require not fulldo ...ensure not empty item = x count = old count + 1end

Page 160: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

remove is -- Éliminer l'élément au sommetrequire not emptydo ...ensure not full count = old count – 1end

end

La notation old e, où e est une expression (dans la plupart des cas pratiques, un attribut), désigne la valeur qu'avait e à l'entrée de la routine. Toute occurrence de e qui n'est pas précédée de old dans la postcondition désigne la valeur de l'expression en sortie.

Page 161: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

9.6 INVARIANTS DE CLASSE

class STACK2 [G] creationmake

feature... make, empty, full, item, put, remove ...capacity: INTEGERcount: INTEGER

feature {NONE} -- Implementationrepresentation: ARRAY [G]

end 

Il faut:

0 <= count; count <= capacity …

Page 162: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

class STACK4 [G] creation ... Comme dans STACK2 ...

feature... Comme dans STACK2 ...

invariantcount_non_negative: 0 <= countcount_bounded: count <= capacityconsistent_with_array_size: capacity =

representation.capacityempty_if_no_elements: empty = (count = 0)item_at_top: (count > 0) implies (representation.item (count)

= item) end

Page 163: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Un invariant d'une classe C est un ensemble d'assertions que toute instance de C vérifiera aux moments "stables".

Les moments stables sont ceux durant lesquels l'instance est dans un état observable:

durant la création de l'instance, c'est-à-dire après exécution de !! a ou !! a.make (...), où a est de type C;

avant et après tout appel distant a.r (...) à une routine r de la classe.

Page 164: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

CHAPITRE 10 : INTRODUCTION A L'HERITAGE

10.1 POLYGONES ET RECTANGLES

10.2 POLYMORPHISME

10.3 TYPAGE DE L'HERITAGE

10.4 LIAISON DYNAMIQUE

Page 165: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

10.1 POLYGONES ET RECTANGLES

indexingdescription: "Polygones ayant un nombre arbitraire de

noeuds"class POLYGON creationfeature -- Access

count: INTEGER -- Nombre de nœudsperimeter: REAL is -- Longueur du périmètre

do ... endfeature -- Transformation

display is -- Afficher le polygone à l'écran.do ... end

rotate (center: POINT; angle: REAL) is-- Tourner de angle autour du center

do ... Voir ci-dessous ... end

Page 166: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

translate (a, b: REAL) is-- Déplacer de a horizontalement, b verticalement.do ... end

... Déclarations d'autres caractéristiques ...feature {NONE} -- Implémentation

vertices: LINKED_LIST [POINT]-- Points successifs représentant le polygone

invariantsame_count_as_implementation: count = vertices.countat_least_three: count >= 3

-- Un polygone possède au moins trois nœudsend

 

Page 167: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

rotate (center: POINT; angle: REAL) is-- Tourner autour de center de angle.

dofrom

vertices.startuntil

vertices.afterloop

vertices.item.rotate (center, angle)vertices.forth

endend

Page 168: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

perimeter: REAL is -- Somme des longueurs des arcslocal

this, previous: POINTdo

fromvertices.start; this := vertices.itemcheck not vertices.after end

-- Conséquence de at_least_threeuntil vertices.is_lastloop

previous := this;vertices.forth this := vertices.item.Result := Result + this.distance (previous)

endResult := Result + this.distance (vertices.first)

end

Page 169: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Rectangles

class RECTANGLE inheritPOLYGONfeature... Caractéristiques spécifiques aux rectangles ...end

 

class RECTANGLE inheritPOLYGONredefine perimeter endfeature... Caractéristiques spécifiques aux rectangles ...end

Page 170: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

indexingdescription: "Rectangles comme cas spécial de polygones généraux"

class RECTANGLE inheritPOLYGON

redefine perimeter endcreation

makefeature -- Initialization

make (center: POINT; s1, s2, angle: REAL) is-- Créer un rectangle centré en center, de longueurs de côté s1 et s2 et d'orientation angle.

do ... end

Page 171: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

feature -- Accessside1, side2: REAL -- Les longueurs des deux côtésdiagonal: REAL -- Longueur de la diagonaleperimeter: REAL is -- Somme des longueurs des côtés

-- (Redéfinition de la version POLYGON)do

Result := 2 * (side1 + side2)end

invariantfour_sides: count = 4first_side: (vertices.i_th (l)).distance (vertices.i_th (2)) = side1second_side: (vertices.i_th (2)).distance (vertices.i_th (3)) = side2third_side: (vertices.i_th (3)).distance (vertices.i_th (4)) = side1fourth side: (vertices.i_th (4)).distance (vertices.i_th (1)) = side2

end

Page 172: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Héritage d'invariant

 

L'invariant de la classe RECTANGLE exprime que le nombre de côtés = 4 et que les longueurs des arcs sont side1 et side2. La classe POLYGON possède aussi un invariant qui s'applique à son héritier.

 

Puisque les parents ont eux-mêmes des parents, cette règle est récursive: l'invariant complet d'une classe est finalement obtenu en effectuant un and des clauses d'invariant de tous ses ancêtres.

Page 173: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Héritage et création

Une procédure de création pour POLYGON pourrait avoir la forme suivante:

make_polygon (vl: LINKED_LIST [POINT]) is-- Définir un polygone dont les nœuds sont dans vl.

requirevl.count >= 3

do... Initialiser la représentation du polygone à partir des

éléments de vl ...ensure

-- vertices et vl ont les mêmes éléments (cela peut s'exprimer formellement).

end

Pas pratique pour rectangle vu son invariant!

Page 174: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE
Page 175: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

10.2 POLYMORPHISME

Attachement polymorphe

Soient:

p: POLYGON; r: RECTANGLE; t: TRIANGLE

Les affectations suivantes sont, alors, valides:

p := r

p := t

Par contre, r := p n'est pas valide car vous ne pouvez attacher quelque chose de général à quelque chose de plus spécifique.

Page 176: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Structures polymorphes de données

Considérons un tableau de polygones:

poly_arr: ARRAY [POLYGON]

Quand vous affectez une valeur x à un élément du tableau, comme dans poly_arr.put (x, some_index)

la spécification de la classe ARRAY indique que le type de la valeur affectée doit être conforme au paramètre générique réel:

class ARRAY [G] creation...

feature -- Elément changeput (v: G; i: INTEGER) is

-- Affecter v à l'entrée d'indice i....

end -- class ARRAY

Page 177: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Puisque v, argument formel correspondant à x, est déclaré dans la classe avec le type G et que le paramètre générique réel correspondant à G est, dans le cas de poly_arr, POLYGON, le type de x doit être conforme à POLYGON. Comme nous l'avons vu, cela ne veut pas nécessairement dire que x doit être de type POLYGON: tout descendant de POLYGON est acceptable.

Ainsi, en supposant que le tableau ait pour bornes 1 et 4, que nous ayons déclaré certaines entités comme:

p: POLYGON; r: RECTANGLE; s: SQUARE; t: TRIANGLE

et que nous ayons créé les objets correspondants, nous pouvons exécuter: poly_arr.put (p, 1)

poly_arr.put (r, 2)poly_arr.put (s, 3)poly_arr.put (t, 4)

pour obtenir un tableau de références à des objets de types différents.

Page 178: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

10.3 TYPAGE DE L'HERITAGE

Soient:p: POLYGONr: RECTANGLE

Ce qui suit est valide: p.perimeter p.vertices, p.translate (...), p.rotate (...) avec des arguments valides; r.diagonal, r.side1, r.side2 r.vertices, r.translate (...), r.rotate (...): r.perimeter 

Ce qui suit n'est pas valide: p.sidel p.side2 p.diagonal

Page 179: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

10.4 LIAISON DYNAMIQUE

La liaison dynamique, alliée à la redéfinition, au polymorphisme et au typage statique, complétera la tétralogie de base de l'héritage.

Utiliser la bonne variante !! p.make (...); x := p.perimeter perimeterPOL sera appliqué

!! r.make (...); x := r.perimeter perimeterRECT sera appliqué

Qu'en est-il si l'entité polymorphe p déclarée statiquement comme un polygone fait dynamiquement référence à un rectangle? !! r.make (...) p := r x := p.perimeter

La liaison dynamique impose que la forme dynamique de l'objet détermine la version de l'opération à appliquer. Ici, il s'agira de perimeterRECT

Page 180: INTRODUCTION A LA METHODOLOGIE OBJET Chapitre 1 : LA QUALITE DU LOGICIEL Chapitre 2 : MODULARITE Chapitre 3 : REUTILISABILITE Chapitre 4 : VERS LA TECHNOLOGIE

Comme on l'a vu, un cas plus intéressant se produit, bien sûr, quand nous ne pouvons pas déduire le type dynamique qu'aura exactement p lors de l'exécution à partir de la simple lecture du texte logiciel, comme dans:

p: POLYGON -- Calculer le périmètre de la figure choisie par l'utilisateur

...if chosen_icon = rectangle_icon then

! RECTANGLE ! p.make (...)elseif chosen_icon = triangle_icon then

! TRIANGLE ! p.make (...)elseif

...end...x := p.perimeter