1. Concepts fondamentaux de La P.O.O
2. Introduction à la conception orientée
objet:
2.3 Attitudes et outils méthodologiques
Le lecteur qui connaît les fondements de ce chapitre peut l'ignorer et passer au chapitre suivant. Dans le cas contraire, la programmation visuelle étant intimement liée aux outils et aux concepts objets, ce chapitre est un minimum incontournable.
Cette manière de concevoir
les programmes reste proche des machines de Von Neuman et consiste en dernier
ressort à traiter indépendamment les données et les algorithmes
(traduits par des procédures) sans tenir compte des relations qui
les lient.
En introduisant la notion de modularité dans la programmation structurée descendante, l’approche diffère légèrement de l’approche habituelle de la programmation algorithmique classique. Nous avons défini des machines abstraites qui ont une autonomie relative et qui possèdent leurs propres structures de données; la conception d’un programme relevait dès lors essentiellement de la description des interactions que ces machines ont entre elles.
La programmation orientée
objet relève d'une conception ascendante définie comme des "messages"
échangés par des entité de base appelées objets.
comparaison des deux topologies de programmation
Les langages objets sont fondés
sur la connaissance d’une seule catégorie d’entité informatique
: l’objet. Dans un objet, traditionnellement ce sont les données qui
deviennent prépondérantes. On se pose d’abord la question :
"de quoi parle-t-on ?" et non pas la question "que veut-on faire ?", comme
en programmation algorithmique. C’est en ce sens que les machines abstraites
de la programmation structurée modulaire peuvent être considérées
comme des pré-objets. En fait la notion de TAD est utilisée
dans cet ouvrage comme spécification d’un objet, en ce sens nous nous
préoccupons essentiellement des services offerts par un objet indépendamment
de sa structure interne.
Programmation structurée :
1. Concepts fondamentaux de La P.O.O
Nous écrirons P.O.O pour : programmation orientée objet.
Voici trois concepts qui donnent
toute sa puissance à la P.O.O.
|
Un module représente un objet ou une classe d’objet de l’espace du problème et non une étape principale du processus total, comme en programmation descendante. |
Recenser les objets du
monde réel
Lors de l’analyse du problème,
faire l’état de l’existant en recensant les objets du monde réel.
On établit des classes d’objets et pour chaque objet on inventorie
les connaissances que l’on a sur lui :
Exemple :
Les objets rassemblent une
partie de la connaissance totale portant sur le problème. Cette connaissance
est répartie sur tous les objets sous forme déclarative ou
procédurale.
Les objets sont décrits
selon le modèle des structures abstraites de données (TAD) :
ils constituent des boîtes noires dissimulant leur implantation avec
une interface publique pour les autres objets. Les interactions s’établissant
à travers cette interface.
Un objet :
Encapsulation
c’est le fait de réunir à l'intérieur d'une même entité (objet) le code (méthodes) + données (champs). Il est donc possible de masquer les informations d'un objet aux autres objets. les champs et les méthodes masqués sont dans la partie privée de l’objet. Public les champs et les méthodes visibles sont dans la partie interface de l’objet. |
|
Figure sur la visibilité entre deux objets
- Les méthodes de public ou privé de l'objet A accèdent et peuvent utiliser les méthodes et les champs public de B.
- Les méthodes de public ou privé de l'objet B accèdent et peuvent utiliser les méthodes et les champs public de A.
Postulons une analogie entre les objets matériels de la vie courante et les objets informatiques. Un objet de tous les jours est souvent obtenu à partir d’un moule industriel servant de modèle pour en fabriquer des milliers. Il en est de même pour les objets informatiques.
Définition
Une classe est une sorte de moule ou de matrice à partir duquel sont engendrés les objets réels qui s’appellent des instances de la classe considérée. |
Remarque
En POO, programmer revient donc à décrire des classes d’objets, à caractériser leur structure et leur comportement, puis à instancier ces classes pour créer des objets réels. Un objet réel est matérialisé dans l’ordinateur par une zone de mémoire que les données et son code occupent. |
Les attributs de la classe décrivent la structure de ses instances (les objets). Les méthodes décrivent les opérations qui sont applicables aux instances de la classe. |
Un exemple : les étudiants
Supposons que chaque étudiant soit caractérisé par sa note en mathématiques (NoteMath) et sa note en informatique (NoteInfo). Un étudiant doit pouvoir effectuer éventuellement des opérations de calcul de ses moyennes dans ces deux matières (MoyMath, MoyInfo)et connaître sa moyenne générale calculée à partir de ces deux notes (MoyTotale).
|
La classe Etudiant a été créée. Elle ne possède que les attributs NoteMath et NoteInfo. Les méthodes de cette classe sont par exemple MoyMath, MoyInfo, MoyTotale. Nous avons créé deux objets étudiants (deux instances : Julien et Claudie) de la classe Etudiant. |
Dans un LOO (langage orienté
objet), il existe une particularité dans la façon d’organiser
ses classes : l’héritage de propriétés. L’objectif est
de construire de nouvelles classes en réutilisant
des attributs et des méthodes de classes déjà existantes.
C’est un mécanisme très puissant qui permet de décrire des structures génériques en transmettant depuis l’intérieur d’une même classe toutes les propriétés communes à toutes les " sous-classes " de cette classe. Par construction toutes les sous-classes d’une même classe possèdent toutes les attributs et les méthodes de leur classe parent. |
|
Propriétés
générales et pratiques de l'héritage :
|
La classe " Etudiant
premier cycle" héritant de la classe Etudiant
|
Tout se passe comme si toute la classe Etudiant était recopiée dans la sous-classe Etudiant premier cycle (même si l’implémentation n’est pas faite ainsi). La nouvelle classe dispose d’un attribut supplémentaire (Mention) et d’une méthode supplémentaire (EvaluerMention). |
Voici en Delphi (à
titre indicatif) une implantation possible de ces deux classes :
type Tmention=(Passable,Abien,Bien,Tbien);
Etudiant = class NoteInfo : real; procedure MoyMath(UneNote:real); procedure MoyInfo(UneNote:real); function MoyTotale : real ; Etudiant1erCycle = class(Etudiant) function EvaluerMention: Tmention; |
Voici en Java (à
titre indicatif) une implantation possible de ces deux classes :
class Etudiant
{ public float NoteMath; public float NoteInfo; public void MoyMath(float UneNote){ ... } public void MoyInfo(float UneNote){ ... } public float MoyTotale(){ ... } }// fin classe Etudiant public class Etudiant1erCycle extend Etudiant{ public String Mention; public String EvaluerMention(){ ... } public static void Main(String[ ] args){ ... } }// fin classe Etudiant1erCycle |
Exemples d’héritage dans d’autres domaines :
Structures mathématiques :
Héritage de figures en géométrie affine :
Héritage d'objets graphiques dans un système multi-fenêtré fictif :
PanneauProgEvenement.dif
Nous utilisons ici un de ces
dosages pour montrer à l’étudiant comment écrire des
programmes avec des objets sans être un grand spécialiste. Une
aide irremplaçable à cet égard nous sera fournie par
l’environnement de développement visuel Delphi.
La méthode O.O.D (object oriented design) de G.Booch propose 5 étapes dans l’établissement d’une conception orientée objet. Ces étapes n’ont pas obligatoirement à être enchaînées dans l’ordre dans lequel nous les citons dans le paragraphe suivant. C’est cette souplesse qui nous a fait choisir la démarche de G.Booch, car cette méthode est fondamentalement incrémentale et n’impose pas un cadre trop précis et trop rigide dans son application. Cette démarche se révèle être utile pour un débutant et lui permettra de fabriquer en particulier des prototypes avec efficacité sans trop surcharger sa mémoire.
Identifier les objets et leurs attributs : |
On cherchera à identifier les objets du monde réel que l’on voudra réaliser.
Conseil : Il faut identifier les propriétés caractéristiques
de l’objet (par l’expérience, l’intuition,...).On pourra s’aider d’une
description textuelle (en langage naturel) du problème. La lecture
de cette prose aidera à déduire les bons candidats pour les
noms à utiliser dans cette description ainsi que les propriétés
des adjectifs et des autres qualifiants.
Identifier les opérations : |
On cherchera ensuite à identifier les actions que l’objet subit de la part de son environnement et qu’il provoque sur son environnement.
Conseil : Les verbes utilisés dans la description informelle
(textuelle) fournissent de bons indices pour l’identification des opérations.
Si nécessaire, c’est à cette étape que l’on pourra définir
les conditions d’ordonnancement temporel des opérations (les événements
ayant lieu).
Etablir la visibilité : |
L’objet étant maintenant identifié par ses caractéristiques et ses opérations, on définira ses relations avec les autres objets.
Conseil : On établira quels objets le voient et quels objets
sont vus par lui (les spécialistes disent alors qu’on insère
l’objet dans la topologie du projet). Il faudra prendre bien soin de définir
ce qui est visible ou non, quitte à y revenir plus tard si un choix
s’est révélé ne pas être judicieux.
Etablir l’interface : |
Dès que la visibilité est acquise, on définit l’interface précise de l’objet avec le monde extérieur.
Conseil : Cette interface définit exactement quelles fonctionnalités
sont accessibles et sous quelles formes. Cette étape doit pouvoir
être décrite sous notation formelle; les TAD sont l’outil que
nous utiliserons à cette étape de conception.
Implémenter les objets : |
La dernière étape consiste à implanter les objets en écrivant le code.
Conseil : Cette étape peut donner lieu à la création
de nouvelles classes correspondant par exemple à des nécessités
d’implantation. Le code en général correspond aux spécifications
concrètes effectuées avec les TAD, ou à la traduction
des algorithmes développés par la méthode structurée.
Lors de cette étape, on identifiera éventuellement de nouveaux
objets de plus bas niveau d’abstraction qui ne pouvaient pas être analysés
en première lecture(ceci provoquant l’itération de la méthode
à ces niveaux plus bas).
2.2 Notation UML de classes
et d'objets
La notion d'un langage de modélisation standard pour tout ce qui concerne les développements objets a vu le jour en 1997 il s’agit d’UML (Unified Modeling Language).
Il ne s'agit pas d'une méthode, mais d'une notation graphique et d'un métamodèle.
Nous allons fournir ici les principaux schémas d'UML permettant de décrire des démarches de conception objets simples. Le document de spécification de la version 1.3 d'UML par l'OMG (l'Object Management Group) représente 808 pages de définitions sémantiques et de notations; il n'est donc pas question ici de développer l'ensemble de la notation UML (que d'ailleurs l'auteur ne possède pas lui-même). Nous nous attacherons à détailler les diagrammes de base qui pourront être utilisés par la suite dans le reste du document.
Nous nous limiterons
aux notations relatives aux classes, aux objets, et à l'héritage.
Notations UML possibles d'une classe :
Reprenons l'exemple précédent
avec la classe étudiant :
|
|
|
|
|
|
et méthodes typées |
et méthodes typées |
|
|
Une classe abstraite est notée :
VISIBILITE DES ATTRIBUTS ET DES METHODES
Notations préfixées UML pour trois niveaux de visibilité ( +, - , # ) :
Pour les attributs :
|
|
|
|
|
|
Pour les méthodes :
|
|
|
|
|
|
|
|
Exemple :
|
Notations UML pour deux objets étudiants instanciés à partir de la classe Etudiant :
Schéma UML simplifié :
Schéma UML avec valeur des attributs :
Ces notations correspondent à l'exemple ci-dessous :
Notation UML de l'héritage :
|
Soit pour l'exemple de hiérarchie de
classes fictives ci-dessous :
La notation UML suivante :
Une association binaire (ou plus généralement n-aire), représente un lien conceptuel entre deux classes. Par exemple un étudiant travaille dans un groupe (association entre la classe Etudiant et la classe Groupe).
Une association peut être dénotée par une expression
appelée nom d'association (nommé Travailler ci-dessous) :
Chaque association possède donc deux extrémités
appelées aussi rôles, il est possible de nommer les extrémités
(nom de rôles, ci-dessous un étudiant est un acteur travaillant
dans un groupe qui est un ensemble) :
Une association peut posséder une multiplicité qui représente sous forme d'un intervalle de nombres entiers a..b, le nombre d'objets de la classe d'arrivée qui peut être mis en association avec un objet de la classe de départ. Supposons qu'un étudiant doive s'inscrire à au moins 2 groupes de travail et au plus à 5 groupes, nous aurons le schéma UML suivant :
La présence d'une étoile dans la multiplicité indiquant un nombre quelquonque (par exemple un étudiant peut s'inscrire à au moins 2 groupes sans limite supérieure):
Par exemple pour dénoter en UML le fait qu'un nombre quelconque d'étudiants doit travailler dans au moins deux groupes nous écrirons:
UNE ASSOCIATION PARTICULIERE : L'AGREGATION
Une agrégation est une association correspondant à une relation qui lorsqu'elle est lue dans un sens signigfie "est une partie de" et lorsqu'elle est lue dans l'autre sens elle signifie "est composé de". UML disposant de plusieurs raffinements possibles nous utiliserons l'agrégation comme composition par valeur en ce sens que la construction du tout implique la construction automatique de toutes les parties et que la destruction du tout entraîne en cascade la destruction de chacune de ses parties.
Notation UML de l'agrégation
|
Exemple :
un groupe contient au moins 3 étudiants et chaque étudiant doit
s'inscrire à au moins 2 groupes
Un message envoyé par une classe à une autre classe est représenté par une flèche vers la classe à qui s'adresse le message, le nommage de la flèche indique le message à exécuter :
2.3 Attitudes et outils méthodologiques
Afin d’utiliser une méthodologie pratique et rationnelle, nous énumérons au lecteur les outils que nous utiliserons selon les besoins, dans le processus d’écriture d’un logiciel.
les outils
En tout premier la notion
de module :
|
La notion de cycle de
vie du logiciel :
|
Utiliser des TAD :
|
La programmation structurée
par machines abstraites :
|
La conception et la programmation
orientées objet :
|
La programmation événementielle
:
|
Utiliser un RAD visuel/événementiel
:
|
Utiliser la programmation
exploratoire :
|
Utiliser la programmation
défensive :
|