Programmation et Développement orientés objetssuffi.free.fr/poo/02-Modele_objet.pdf · Chapitre...

Chapitre 2 Cours B4 : Programmation & Développement OO 1/49

Diapositive 1

Version 1.0

Programmation et Développement orientés objets

Cours B4Chapitre 2: Le modèle à objet


Diapositive 2

17/03/2001 Cours B4: Programmation et développement orientés objets 2/33

Évolutions du génie logicielDérive des centres d’intérêt de la « programmation à petite échelle » vers la « programmation à grande échelle »Évolution des langages de haut niveau

L’augmentation de la complexité des logiciels ont forcé le développement du génie logiciel. La tendance est de créer des langages de programmation qui décrivent les entités fondamentales du domaine à traiter (langages déclaratifs) au détriment des langages qui disent à l’ordinateur ce qu’il doit faire (langages impératifs). Au cours de chaque génération de langages, le genre d’abstraction que les langages supportaient change Dans la première génération, la préoccupation des de traduire des formules mathématiques en s’affranchissant des pb du langage machine. Dans la deuxième génération, les machines sont plus puissantes, de nombreuses applications de gestion sont écrites,l’accent est mis sur les abstractions algorithmiques (gestion de fichiers, gestion d’enregistrements, tris, impressions de rapports…) A la fin des années 60, les ordinateurs sont devenus très puissants et peuvent résoudre des pb qui nécessitent la manipulation de nombreux types de données. Les langages évoluent vers l’abstraction des données et permettent au programmeur de décrire les type de données. Le langage de programmation se charge de faire respecter les choix de conception Dans les années 80 apparition des langages basés sur les objets à cause des problèmes traités qui sont colossaux. Exemples de qques langages et de leurs propriétés: 1ere Génération 54-58 FORTRAN I Expressions mathématiques Algol 58 « » Flowmatic « »


IPL V « » Langages de seconde génération (1959-61) Fortran II sous programmes, compilation séparée Algol 60 structure en blocs, types de données Cobol description de données, gestion de fichiers Lisp Traitement des listes, pointeurs, ramasse miette Langages de 3ieme Génération (1962-70) PL/1 Fortran + ALGOL + COBOL Algol 68 successeur rigoureux d’algol 60 Pascal Successeur simple d’algol 60 Simula classes, abstraction de données Langages de quatrièmes génération Beaucoup de langages peu de survivants ADA Smalltalk C++ Eiffel Object Pascal


Diapositive 3


Topologie des langages de 1ière génération

Données

Sous - programmes

Topologie? Blocs élémentaires physiques du langage et comment ces bloc sont connectés. Pour ces langages (Fortran, Cobol) le bloc élémentaire est le sous programme. Les applications sont formées de données globales et de sous programmes Pendant la conception ont peut identifier des genres de données, mais lors de l’écriture du programme le langage ne permet pas d’imposer ses décisions de conception. Une erreur dans une partie du programme peut par effet de bord avoir des effets dévastateurs dans d’autres parties du programme à cause des structures de données globales. Lors de la maintenance, il est difficile de maintenir l’intégrité de l’architecture. Le couplage entre les sous programmes est généralement fort; la signification des données est implicite, et les flux de contrôles « entortillés »: ce qui rend tout le système fragile


Diapositive 4


Topologie des langages de 2ième génération

Données

Sous - programmes

Les sous programmes existent dans les langages de première génération, mais ne sont pas reconnus comme des abstractions des fonctions du programme. Au départ le sous programme est utilisé pour faciliter la tache du programmeur en réduisant la réécriture de code. L’utilisation du sous programme en tant qu’unité d’abstraction à 3 conséquences majeures: Invention de langages permettant des mécanismes de passage d’arguments Développement de la programmation structurée avec des langages qui supportent l’imbrication des sous programmes et développement de la théorie des structures de contrôle, de la portée et de la visibilité des déclarations Fondations de la programmation structurée avec l’utilisation des blocs de sous programmes comme blocs élémentaires dans la conception de grands systèmes. La topologie de ces langages est un variation de ceux de la première génération qui contourne les insuffisances de ces langages en offrant un plus grand contrôle sur les structures algorithmiques. Mais ne résout pas les problèmes de la grande programmation, ni de la conception des données.


Diapositive 5


Topologie des langages de 3ième génération

Données

Sous - programmes

Les langages de 3ième génération permettent de s’attaquer aux préoccupations de la grande programmation: Les programmes ne sont plus développés par un seul individu, mais par une équipe de développement qui écrivent des partie indépendantes du programme. La réponse a ce besoin est la notion de module et de compilation séparée. Dans ces langages le module est une enveloppe arbitraire destinée à regrouper des programmes et des données. Il sont utilisés pour regrouper des sous programmes dont les modifications sont liées. Ils ne sont pas reconnus comme des entités d’abstraction. Les langages de cette génération, bien que supportant la structure modulaire n’ont pas beaucoup d’outils pour assurer la cohérence des interfaces du module. Par exemple dans un module on peut concevoir un sous programme utilisant 3 paramètre entier, tableau de 5 caractères et booléen et dans un autre module appeler ce sous programme avec un nombre flottant, un tableau de 3 caractères et un entier!! De même un module peut être construit en supposant qu’il est seul à modifier les données alors qu’un autre module contrevient à cette règle en les modifiant aussi. A cause de l’absence de typage fort et d’abstraction ces erreurs ne sont pas détectées jusqu’à l’exécution.


Diapositive 6


Topologie des langages orientés objets

Petites et moyennes applications orientées objets

Grosse applications orientées objets

On s’aperçoit que l’utilisation des procédures est bien adaptée à la description des opérations abstraites, mais ne permet pas de décrire des objets abstraits. Ces un inconvénient car dans de nombreuses applications la complexité des données participe activement à la complexité du problème. Ceci à deux conséquences principales: Apparition de méthodes de conception basées sur les données qui donnent une approche disciplinée aux pb que posent l’abstraction des données dans les langages orientés algorithmes Théorie relative au concept de données concrétisées dans des langages tels que PASCAL. Ces idées ont débouchées sur les langages OO -> Smalltalk, Object PASAL, C++, CLOS, Ada, Eiffel… Dans ces langages le bloc élémentaire est le module qui représente un ensemble cohérent de classes et d’objets au lieu de sous programmes comme dans les langages de la génération précédente. Il y a peu ou pas de données globales. Les données et les opérations sont unifiées de façon que le bloc fondamental ne soit plus l’algorithme mais la classe et l’objet Dans les très grands systèmes les notions de classes, d’objets et de module ne sont plus suffisants. Le modèle à objet s’adapte en proposant des groupes d’abstractions construits les uns sur les autres. A n’importe quel niveau, on trouve des groupes d’objets qui collaborent pour offrir un comportement de plus haut niveau. Si on regarde l’intérieur d’un groupe donné, on trouve un autre ensemble d’abstractions coopérantes. Ceci est l’organisation de la complexité décrite précédemment.


Diapositive 7


Définitions préliminairesProgrammation orientée objets:

La programmation orientée objet est une méthode de mise en œuvre dans laquelle les programmes sont organisés comme un ensemble d’objets coopérants. Chacun représente une instance d’une certaine classe, toutes les classes étant membre d’une hiérarchie de classe unifiée par la relation d’héritage

Conception orientée objetsLa conception orientée objet est une méthode de conception incorporant le processus de décomposition orienté objets et une notation permettant de dépeindre à la fois les modèles logiques, physiques, statiques et dynamiques du système à concevoir

Analyse orientée objetsL’analyse orientée objets est une méthode d’analyse qui examine les besoins d’après la perspective des classes et des objets trouvés dans le vocabulaire du domaine.

Le modèle objets dérive de nombreuses sources disparates. Il est accompagnée d’une terminologie confuse. Un programmeur smalltak utilise des méthodes, un programmeur C++ utilise des fonctions membres virtuelles. Même la définition de l’objet est un peu confuse (à ce stade de l’étude) un objet est une entité tangible qui a un comportement bien défini. Une définition plus précise de l’objet est une entité qui combine les propriétés des procédures et des données puisqu’ils réalisent des calculs et sauvegarde un état local. Ils unifient les abstractions d’algorithme et de données. POO: La définition comporte trois parties importantes: la programmation fait appel à des objets plutôt qu’à des algorithmes comme blocs fondamentaux chaque objet est une instance d’une certaine classe les classes sont reliées par une notion d’héritage. Si l’un des ces trois éléments vient à manquer ce n’est plus de la programmation orientée objets. Programmer sans héritage n’est pas orienté objet mais programmer avec des types abstraits. Cette définition permet de déterminer les langages orientés objets: un langage orienté objets est un langage supportant facilement le style de programmation orientée objets. Un langage est orienté objet si il répond aux conditions suivantes: il supporte des objets qui sont des abstractions de données avec une interface d’opérations nommées et un état internce caché les objets ont un type associé (la classe) les types (les classes) peuvent hériter des attributs venant de super-types (les super-classes).


Pour qu’un langage supporte l’héritage, il faut qu’il soit possible d’exprimer « est un ». C++, Smalltalk et Eiffel sont des langages orientés objets suivant cette définition, ADA est un langage basé sur les objets. Conception OO Les méthodes de POO mettent l’accent sur un usage approprié et efficace des mécanismes présents dans les langages OO. Les méthodes de COO mettent l’accent sur la structuration appropriée et efficace d’un système complexe. La def contient deux idées importantes: la COO conduit à une décomposition OO plutôt qu’à une décomposition algorithmique la COO utilise des notations différentes pour exprimer des modèles différents de la conception logique (classe et objets) de la conception physique (modules et processus). AOO Le modèle Objets a influencé jusqu’à l’analyse des systèmes. Les techniques traditionnelles d’analyse (Yourdon, Ward et Mellor, SADT, SART) se concentrent sur les flux de données à l’intérieur d’un système. L ’analyse OO met l’accent sur la construction de modèle du monde réel en utilisant une vue OO de ce monde. Liens entre AOO, COO et POO: Les résultat de l’AOO peuvent servir de modèle pour réaliser la COO Les résultats de la COO peuvent servir de base pour bâtir un programme en utilisant des méthodes de POO.


Diapositive 8


Fondements conceptuels des modèles orientés objets

FondamentauxAbstractionEncapsulationModularitéHiérarchie

SecondairesTypageSimultanéitéPersistance

Il existe différents paradigmes de programmation, chacun ayant sa propre ossature conceptuelle (modèles) Orienté procédures et algorithmes Orientés objets classes et objets Orientés logique but, calcul des prédicats Orientés règles règles SI-ALORS Orientés contraintes respect de relations invariantes Il n’y a pas de style de programmation qui serait meilleur que tous les autres. Chacun est adapté à la résolution d’un type de pb. Le style de programmation OO semble seulement capable de résoudre un plus large éventail de pb. Pour ce qui est « orienté objets » l’ossature conceptuelle est composée de 4 éléments majeurs, et de 3 éléments mineurs. Si l’un des 4 éléments majeur est absent, le modèle n’est pas OO. Les éléments mineurs sont des éléments utiles mais non essentielle du modèle à objets. Sans cette ossature, on peut programmer dans les langages à O mais on ne peut pas tirer parti de la puissance du langage, l’architecture sera semblable à celle d’une appli écrite en FORTRAN et vraisemblablement la complexité du pb ne sera pas maîtrisée.


Diapositive 9


AbstractionMoyen de traiter la complexitéIdentification des similaritésMet l’accent seulement sur les détails nécessaires à la compréhension du problèmeDéfinition:

Une abstraction fait ressortir les caractéristiques essentielles d’un objet et donc procure des frontières conceptuelles rigoureusement définies par rapport au point de vue de l’observateur.

L’abstraction est une des façons fondamentales pour l’être humain de traiter la complexité L’abstraction provient d’une identification des similarités entre certains objets, situations ou processus du monde réel et de la décision de se concentrer sur ces similarités et d’ignorer momentanément les différences. L’abstraction est une description simplifiée d’un système en mettant l’accent sur certains détails et en supprimant les autres. En résumé l’abstraction se concentre sur les caractéristiques essentielles d’un objet (celles qui le distinguent de tous les autres genres d’objets) du point de vue de l’observateur. L’abstraction se concentre sur la vue externe de l’objet en la séparant de sa mise en œuvre. Elle procure une division comportement/mise en œuvre. Une « bonne abstraction » capture tout le comportement d’un objet ni plus ni moins (principe de moindre engagement) et n’offre aucune surprise ou effet de bord (principe de moindre étonnement). Déterminer les abstractions d’un domaine donné est le problème central de la conception OO. Il existe plusieurs genres d’abstractions des plus utiles au moins utiles: Abstraction d’entité: un objet qui représente un modèle utile d’une entité du domaine du problème ou de sa solution Abstraction d’action: un objet qui procure un ensemble généralisé d’opérations réalisant toutes le même genre de fonctions Abstraction de coïncidence: un objet qui referme un ensemble d’opérations qui n’ont pas de relations entre elles. Il faut s’efforcer de construire des abstractions d’entité car elles épousent directement le problème du domaine.


Qu’est ce que déterminer le comportement d’un objet? considérant les services qu’il offre à ses clients considérant les opérations qu’il peut effectuer sur d’autres objets Ceci oblige à se concentrer sur la externe de l’objet et permet de définir le modèle contractuel. La vue externe d’un objet définit un contrat sur lesquels les objets clients reposent. La vue interne de l’objet est chargée de traiter ce contrat. Le contrat définit les responsabilités d’un objet, cad le comportement qu’on peut attendre de lui. Chaque opération qui contribue au contrat est caractérisée par une signature unique qui est composée de ses paramètre formels ainsi que de son type. Le concept d’invariant est au centre de la notion d’abstraction. Un invariant est une condition booléenne qui doit être maintenue. Pour chaque opération on définit des préconditions (invariants sur lesquels se base l’opération) et des postconditions (des invariants qu’elle satisfait). Violer les invariants signifie rompre le contrat. Si une précondition n’est pas remplie le client n’a pas rempli sa par du marché, si une post condition n’est pas satisfaite, c’est que le serveur n’a pas rempli sa tâche et les clients ne peuvent plus lui faire confiance. Certain langages à objets permettent de lever des exceptions pour traiter ces cas. Toutes les abstractions ont des propriétés statiques et dynamiques. Par exemple un objet fichier à pour propriétés statiques un espace sur le disque et un nom. La valeur de ces propriétés peut changer pendant la durée de vie de l’objet sa taille augmente ou diminue et son nom peut changer. Dans le style de programmation OO le changement des valeurs dynamiques d’un objet à lieu quand on agit sur cet objet -> le comportement d’un objet est défini par les opérations que nous pouvons exécuter sur lui et la façon dont il va réagir.


Diapositive 10


Exemples d’abstractions// Température exprimée en degres °Ctypedef float Temperature;

// Nombre indiquant l’endroit où est placé le capteurtypedef unsigned int Localisation;

class CapteurDeTemperature {

public:CapteurDeTemperature(Localisation);

~CapteurDeTemperature();

void Calibrer(Temperature TemperatureEtalon);Temperature TemperatureActuelle() const;

private:

...};

Temperature temperature;

CapteurDeTemperature CapteurMaison1(1);

CapteurDeTemperature CapteurMaison2(2);

temperature = CapteurMaison1.TemperatureActuelle();

Le problème consiste à représenter un système de domotique qui contrôle les paramètres d’environnement d’une maison. Les paramètres à contrôler sont la température, l’hygrométrie et l’éclairage la maison. Le système de domotique exécute des « plans » ou « programmes » prédéfinis pour ajuster constamment ces paramètres. L’une des abstractions clé du domaine est celle du capteur: tous les paramètres qui doivent être mesurés et contrôlés le sont par l’intermédiaire de capteurs. Capteurs de température, d’humidité, et d’éclairage. Un capteur de température est chargé de mesurer la température dans un endroit; Une température est une valeur numérique dans une gamme limitée de valeurs et avec une certaine précision. La valeur numérique représente des degrés dans l’échelle Celsuis. Un endroit est un lieu identifié ou l’on veut mesure la température(dans la maison il s’agit d’une pièce), on peut supposer qu’il existe un nombre restreint d’endroits. Vu de capteur de température l’important n’est pas tant l’endroit que le qu’il a un emplacement unique et une identité unique par rapport aux autres capteurs de température. On peut déterminer les responsabilités du capteur de température: Notre capteur est chargé de connaître la température en un endroit et de la fournir à la demande. Les opérations que l’on peut pratiquer sur notre capteur sont le calibrer et demander la température courante. Temperature et Localisation sont des synonymes des types de base destinés à exprimer nos abstractions dans le domaine du problème. La classe CapteurDeTemperature constitue l’abstraction du capteur et sa représentation est cachée dans la partie privée de la classe.


On remarque que CapteurDeTemperature est un classe et non un objet individuel. Il faut créer un instance pour avoir un objet sur lequel agir. Les invariants associés à l’opération TemperatureActuelle sont: précondition: le capteur est à un emplacement valide postcondition: le capteur à mesuré une valeur valide en degrés °C. Cette abstraction est passive.


Diapositive 11


Exemples d’abstractionclass CapteurDeTemperatureActif {

public:

CapteurDeTemperatureActif(Localisation,

void (*f)(Localisation, Temperature));

~CapteurDeTemperatureActif();

void Calibrer(Temperature TemperatureEtalon);

void FixerConsigne(Temperature TemperatureConsigne,

Temperature Delta);

Temperature TemperatureActuelle() const;

private:

...

};

On peut rendre l’objet actif : plutôt que d’attendre qu’on lui demande la température, ce capteur pourra agir si la température s ’ écarte d’une température de consigne. Ces presque la même classe de précédemment mais les responsabilités sont légèrement altérées: un capteur doit signaler tout changement de temp plutôt que d’attendre qu’on le lui demande. Cette classe utilise la technique des callbacks. Quand on crée l’objet on doit spécifier à la fois sa localisation et aussi une fonction qui sera appelée lorsque la température varie. Nous ajoutons aussi une opération pour fixer la température de consigne. Lors de l’appel du réflexe, le capteur fournit sa localisation et la température courante; le client a toutes les infos nécessaires pour traiter. Et si le client ne définit pas de température de consigne? Notre abstraction doit faire des suppositions valides La mise en œuvre de responsabilité de la classe d »pend de sa vue interne et et ne concerne pas les classes clientes. Ce sont les secrets de la classe.


Diapositive 12


EncapsulationL’encapsulation s’attache à la mise en œuvre d’un objetElle est obtenue par le masquage des informationsElle procure des barrières explicites entre les différentes abstractions et amène une séparation claire des problèmesDéfinition:

L’encapsulation est le procédé de séparation des éléments d’une abstraction qui constituent sa structure et son comportement. Elle permet de dissocier l’interface contractuelle de la mise en œuvre d’un objet

L’abstraction d’un objet précède aux détails de sa mise en œuvre. Mais dès que cette dernière est définie elle doit être considérée comme cachée et secrète pour la plupart des clients. Aucune partie interne d’un système ne doit dépendre des parties internes d’un autre système. L’encapsulation permet aux modifications d’un programme d’être faites en toute sécurité et avec un moindre effort. Abstraction et Encapsulation sont des concepts complémentaires: l’abstraction se concentre sur l’interface externe d’un objet, l’encapsulation se concentre sur la mise en œuvre de ce comportement. L’encapsulation est souvent obtenue par le masquage des informations qui permet de cacher tous les secrets d’un objet qui ne participent pas directement à ses caractéristiques essentielles. Souvent la structure de l’objet ainsi que le codage de ses méthodes sont cachés. L’encapsulation crée des barrières explicites entre les différentes abstractions et amène une séparation claire des problèmes. Par exemple dans l’écriture d’une application de base de données il est courant d’ecrire des programmes qui ne se soucient pas de la représentation physique des données, mais qui se basent uniquement sur une vue logique de ces données; Les objets aux niveaux supérieurs d’abstraction sont protégés des détails de mise en œuvre des niveaux inférieurs.


En pratique l’encapsulation indique que chaque classe doit avoir deux parties: une interface et une mise en œuvre. L’interface d’une classe capture seulement sa vue externe, qui renferme l’abstraction du comportement commun à toutes les instances de cette classe. La mise en œuvre renferme la représentation de l’abstraction ainsi que ses mécanismes de mise en œuvre. L’interface est l’endroit ou nous indiquons toutes les hypothèses qu’un client peut faire au sujet des instances d’une classe. La mise en œuvre cache au client les détails qu’il ne doit pas connaître.


Diapositive 13


Exemples d’encapsulation// Type booleenenum Booleen { FALSE=0, TRUE };

// Abstraction d'un radiateur

class Radiateur {public:

Radiateur(Localisation);~Radiateur();

MettreEnMarche();

Arreter();Boolean EstEnMArche() const;

protected:...

};

// Abstraction d’une liaison sérieclass LiaisonSerie {

public:LiaisonSerie();

~LiaisonSerie();

void Ecrire(char *);void Ecrire(int);

static LiaisonSerie[10];

private:...

};

// Implémentation d’un radiateurclass Radiateur {

public:...

protected:const Localisation _loc;

Boolean _isOn;LiaisonSerie *_port;

};

//Initialisation d’une instance deradiateur

Radiateur::Radiateur(Localisation loc):

_loc(loc),_isOn(FALSE),_port(&LiaisonSerie::ports[1] {}

// Implémentation de la mise en servicedu radiateur

Radiateur::MettreEnMarche() {if (!_isOn) {

_port->Ecrire("*");_port->Ecrire(_loc);

_port->Ecrire(1);_isOn = TRUE;

}}

// Implémentation de la mise horsservice du radiateur

Radiateur::Arreter() {

if (_isOn) {_port->Ecrire("*");

_port->Ecrire(_loc);_port->Ecrire(0);

_isOn = FALSE;}

}

// Vérification de l’état duradiateur

Radiateur::EstEnMarche() const {

return _isOn;}

Cet exemple décrit un des radiateurs de la « maison ». Cet appareil se situe bas dans la hiérarchie (pas très évolué). Nous supposons qu’il supporte seulement 3 opérations : le mettre en marche l’arrêter vérifier si il est en fonctionnement Il n’est pas de la responsabilité du radiateur de maintenir la température constante. Cette fonction sera confiée à un objet de plus haut niveau (le régulateur par ex:) basé sur les abstractions CapteurDeTempérature et Radiateur. Cette séparation des responsabilités rend les abstractions plus cohérentes. Ces trois opérations (plus les opérations de construction et de destruction) forment l’interface de la classe qui tout client doit connaître. Si on se tourne vers l’intérieur de la classe c’est tout à fait différent. Dans notre système la mise en marche du radiateur est pilotée par un relais electromagnétique commandé par des messages envoyés sur une liaison série. Abstraction d’une liaison série. Le tableau de ports représente les ports série disponibles. On suppose que la commande des radiateurs se fait sur la ligne série 1 et que les messages ont la forme suivante: « * Numéro de radiateur Commande » (commande pouvant être 0 pour arrêt, et 1 pour marche). La mise en œuvre de notre classe radiateur fait appel à trois variables internes (3 attributs) qui sont la représentation interne encapsulée de notre abstraction:


Le numéro du radiateur, L’état courant du radiateur et L’adresse du port série. Les règles du langage C++ font que la compilation d’un client qui chercherait à accéder à ces attributs provoquerait une erreur La mise en œuvre des opérations est simple. Cette structure est la caractéristique des SOO bien construits. Les codes de mise en œuvre sont généralement compacts car ils sont construits en utilisant les ressources offertes par des classes coopérantes. Supposons que l’on décide de remplacer les liaisons séries par un réseau ? Il suffit de modifier la mise en œuvre de la classe Radiateur pour refléter ce nouveau choix. Le reste de l’application n’est pas impacté par ce choix. Une encapsulation intelligente rend local à la classe les choix de conception susceptibles d’être remis en cause (ou sujet au changement). Au cours du développement, on peut s’apercevoir qu’un temps de traitement est trop long, qu’un objet consomme plus de place que disponible… L’encapsulation permet de corriger ces défauts sans pour autant modifier les clients de la classe. Cette possibilité de modifier la représentation d’un abstraction sans perturber les clients est l’avantage majeur de l’encapsulation. Les tentatives d’accès à la représentation d’un objet devraient être détectée dès la compilation du client. Cette assertion fait l’objet d’un débat dans la communauté OO. Chaque langage à sa propre philosophie sur le sujet: Smalltalk ne permet pas l’accès aux variables d’instance d’une classe; Object Pascal n’encapsule pas les données et aucun mécanisme empêche d’y accéder CLOS: chaque attribut peut avoir l’option :read, :write, :accessor ou aucun C++: utilisation des attributs public, protected et private et de la notion d’ami. Bien sur aucun système n’empêche un développeur de lire le code source de la mise en œuvre d’une classe et dans certains cas c’est le seul moyen de comprendre le fonctionnement réel de la classe (surtout si la documentation est déficiente).


Diapositive 14


ModularitéAction de scinder un programme est composants individuelsChaque composant étant faiblement liés aux autresPermettre la compilation séparéDéfinition

La modularité est la propriété d’un système qui a été décomposé en un ensemble de modules cohérents et faiblement couplés

L’action de découper un programme en composants individuels peut réduire sa complexité, mais la meilleure justification de la modularité réside dans le fait qu’elle crée des frontières bien définies et documentées à l’intérieur d’un programme Dans certains langages le concept de module n’existe pas, les classes forment une seule unité physique de décomposition (SMALLTALK). Dans de nombreux autres langages, (C++,ADA, Object Pascal) le module est une unité de construction séparée. Dans ces langages les classes et les objets représentent la structure logique d’un système; ces abstractions sont placées dans des modules pour produire l’architecture physique du système. La modularité est essentielle pour contrôler la complexité dans les grosses applications qui contiennent plusieurs centaines de classes. La plupart des langages qui supportent la modularité font la différence entre l’interface du module et sa mise en œuvre. Les langages supportent différemment la modularité: En C++, les modules ne sont rien d’autre que des fichiers compilés séparément. On a pour habitude de placer les interfaces du module dans le fichier d’en tête (« .h »). Le code des modules est placé dans les fichiers .c. Les dépendance entre modules sont exprimés au moyen de la directive #include. En C, c’est une approche totalement conventionnelle car la définition du langage n’impose rien. Ada va plus loin: le paquetage à deux parties sa spécification et son corps. ADA autorise a énoncer différemment les connexions entre modules dans la spécification du paquetage et dans son body. Le body peut dépendre de modules qui sont invisibles de la spécification.


Le choix des modules est aussi difficile que le choix de l’ensemble des abstractions clés. Pour les applications les plus anciennes le choix des modules peut être quasiment standard, mais pour les nouvelles applications il peut être très difficile en partie parce que la solution du pb ne peut pas être totalement connue au moment où la conception commence. Les modules servent de conteneurs physiques pour nos classes et non objets. Analogie: un électronicien dispose de portes logiques pour concevoir les cartes d’un ordinateurs. Ces portes sont organisées dans des CI standard (7400, 7402, 7404…). L’informaticien malheureusement ne dispose pas toujours de ces briques standards et à beaucoup plus de liberté (comme si l’électronicien disposait une fonderie de silicium). La difficulté de la modularité provient aussi de déterminer le bon compromis de granularité entre monolithique et fragmenté à l’extrême. Une modularité trop poussé conduit à une documentation difficile à mettre en œuvre et à faire évoluer. Elle rend aussi difficile pour les programmeurs difficile la découverte des classes à utiliser. Lorsque les choix changent se sont de nombreux modules qu’il faut modifier. On peut utiliser plusieurs guides pour établir les modules d’une application (ce sont à la fois des considérations techniques et non techniques qui peuvent aider à la réalisation des modules. Le but global de la décomposition en module est la réduction du coût global des programmes en permettant leur conception et modification indépendante par des équipes différentes. La structure de chaque module doit être suffisamment simple pour être comprise dans sa totalité Il doit être possible de modifier le module sans connaître le codage des autres modules Il doit être possible de modifier le module sans affecter le comportement des autres modules La facilité d’apporter une modification doit être proportionnelle à la probabilité de devoir le faire. En pratique, le coût de la recompilation du corps d’un module est assez faible. Le coût de compilation de l’interface d’un module est élevé car il entraîne la compilation de l’interface, du corps et de tous les modules qui utilise l’interface. Ainsi si l’environnement ne supporte pas la compilation incrémentale pour les gros programmes la modification de l’interface d’un module peut entraîner des compilations pouvant durer plusieurs heures. Deux autres points techniques peuvent influencer le choix des modules: les modules représentent des unités de code élémentaire et indivisibles pouvant être réutilisées: le programmeur peut choisir de regrouper classes et modules pour faciliter cette ré-utilisation. De nombreux compilateurs génèrent le code objet en segments , un pour chaque module. Il peut exister des limites physiques à la taille d’un module et les performances générales d’un programme peuvent être dégradées si il y a de nombreux appels inter-segments. Autres besoins non techniques pouvant guider le choix des modules: Les tâches de développement étant souvent distribuées dans une équipe, le module peut servir d’unité de développement pour assurer le travail parallèle des équipiers. Dans certaines situations le module peut servir de d’interface avec les sous-traitants. La confidentialité peut être aussi le motif de réalisation d’un module… Les principes d’abstraction, d’encapsulation et de modularité sont synergiques. Découvrir les classes et les objets et les distribuer dans des modules sont des opérations indépendantes: l’identification des modules fait partie de la conception physique tandis que l’identification des classes fait partie de la conception logique. La découverte des classes et des modules sera de préférence mener en // de façon itérative.


Diapositive 15


Exemple de module// Plan de contrôle Plan.h

#ifndef _PLAN_H

#define _PLAN_H

#include "PlanTypes.h"

#include "except.h"

#include "actions.h"

class PlanDeChauffage ...

class PlanHorsGel ...

class PlanEco ...

...

#endif

Examinons la modularité du système de domotique. A partir d’un ordinateur personnel un utilisateur peut créer des programmes de chauffage, les modifier, suivre leur exploitation, etc… L’un des abstractions clé étant celle du porgramme (plan), nous pouvons créer un module qui regroupe toutes les classes associées à des programmes de domotique. En C++, elles sont regroupées dans un fichier d’entête.


Diapositive 16


HiérarchieLa hiérarchie est un classement ou un ordonnancement des abstractionsLes hiérarchies les plus importantes sont:

La structure de classe (est un)La structure d’objets (partie de)

L'abstraction est une bonne chose mais, dans la plupart des applications non triviales, on peut avoir affaire à beaucoup d'abstractions que nous ne pouvons appréhender en même temps. En masquant l'intérieur de ces entités, l'encapsulation aide à contrôler cette complexité. La modularité apporte aussi une aide en nous permettant de grouper des entités ayant des liens logiques. Pourtant, tout ceci n'est pas suffisant. Un ensemble d'abstractions constitue souvent une hiérarchie. En identifiant celles�ci dans notre architecture, nous pouvons grandement simplifier la compréhension du problème


Diapositive 17


Héritage2 types d’héritages:

simplemultiple

L’héritage représente une hiérarchie généralisation/spécialisationL’héritage simple est la plus importante des hiérarchies « est un »C’est un élément essentiel des systèmes orientés objetsChaque sous-classe enrichit la super-classe

Fondamentalement, l'héritage définit une relation entre les classes, dans laquelle une classe partage la structure ou le comportement défini dans une ou plusieurs classes (ce qui s'appelle respectivement héritage simple ou héritage multiple) L'héritage représente une hiérarchie d'abstractions, dans laquelle une sous�classe hérite d'une ou plusieurs super�classes. Typiquement, une sous�classe enrichit ou redéfinit la structure et le comportement de ses super�classes. Sémantiquement, l'héritage dénote une relation «est un». Par exemple, un ours «est un» mammifère, une maison «est un» patrimoine, et le tri rapide «est un» algorithme de tri particulier. L'héritage suppose donc une hiérarchie de généralisation/ spécialisation, dans laquelle une sous�classe spécialise la structure ou le comportement plus généraux de ses super�classes. C'est là le test par excellence de l'héritage: si B n'est pas un «type» de A alors B ne devrait pas hériter de A.


Diapositive 18


Exemple d’héritage simple (1/2)

typedef unsigned int Day;

typedef unsigned int Hour;

typedef unsigned int Quart;

struct Condition {

Temperature temperature;

Lumiere Eclairage;

Humidite humidite;

};


Diapositive 19


Exemple d’héritage simple (2/2)class PlanDeChauffage {

public:

PlanDeChauffage(char *nom);

~PlanDeChauffage();

void Effacer();

virtual void Etablir(

Day,Hour,Quart,

const Condition&);

const char* Nom() const;const Condition& ConditionDesiree(

Day,

Hour,

Quart) const;

protected:

// Une structure de donnees pour

// recevoir des etapes du programme

....

};

class PlanDeHorsGel: publicPlanDeChauffage {

public:

PlanDeHorsGel(char *nom);

~PlanDeHorsGel();

virtual void Etablir(

Day, Hour, Quart,const Condition&);

void DefinirHorsGel(Day);

void TemperatureHorsGel(

Temperature);

Boolean EstHorsGel();

protected:

Temperature _tempHorsGel;

};

La déclaration de la classe PlanDeHorsGel représente un choix de conception. Un plan de Hors Gel est un « type » particulier de programme avec des attributs supplémentaires et un comportement étendu Ceci se traduit par l’ajout d’attributs (encapsulés) et de fonctions membres. Sur cette base on pourrait définir des programmes encore plus spécialisés. Au fur et à mesure que nous faisons évoluer notre hiérarchie d'héritage, la structure et le comportement qui sont les mêmes pour différentes classes vont tendre à migrer vers des super�classes communes. C'est pourquoi nous parlons souvent de l'héritage comme étant une hiérarchie de généralisation/spécialisation. Les super�classes représentent des abstractions généralisées, et les sous�classes représentent des spécialisations dans lesquelles les champs et les méthodes de la super�classe sont étendus, modifiés, voire occultés. De cette façon, l'héritage nous permet d'exprimer nos abstractions avec une certaine économie d'expression. Le fait de négliger les hiérarchies de «types» existantes peut conduire à des architectures lourdes et inélégantes. Sans héritage, chaque classe serait une unité isolée et développée à partir de zéro. Les différentes classes ne supporteraient aucune relation les unes avec les autres, puisque le développeur de chacune d'elles définit des méthodes à sa convenance. La cohérence entre classes ne serait alors que le résultat d'une grande discipline de la part des programmeurs. Il existe une opposition (sain) entre les principes d'encapsulation et de hiérarchie: l’encapsulation essaie de cacher les données et les méthodes d’un objet tandis que l’héritage ouvre cette barrière et permet d’accéder aux données et aux méthodes d’une super-classe.


Pour une classe donnée, il y a habituellement deux genres de clients : les objets qui invoquent des opérations sur les instances de la classe, et des sous�classes qui héritent de cette classe. Par héritage, l’encapsulation peut être violée de 3 façons: la sous�classe peut accéder à une variable d'instance de sa super�classe, appeler une opération privée de sa super�classe ou faire directement référence à des super�classes de sa super�classe. Les divers langages de programmation font des compromis différents au sujet de l'encapsulation et de l'héritage. C++ offre une grande flexibilité. l'interface d'une classe peut avoir trois parties: les parties privées, qui déclarent les membres qui sont accessibles seulement par la classe elle�même, les parties protégées, qui déclarent les membres qui sont visibles seulement par la classe et ses sous�classes, et les parties publiques, qui sont accessibles par tous les clients.


Diapositive 20


Exemple d’héritage multiple (1/2)typedef unsigned int PuissanceFiscale;

typedef unsigned int PuissanceReelle;

class Vehicule {

public:

Vehicule(char* marque, char* modele);

virtual ~Vehicule();

void MiseEnService(Date d);

const char* marque() const;

const char* modele() const;

const Date DateMiseEnService() const;

virtual Date ContrôleTechnique();

virtual void FaireLePlein();

protected:

char* _modele;

char* _marque;

Date _dateMiseEnService;

....

};

Pour certaines abstractions il est utile d’hériter de plusieurs super-classes Exemple: Définition d’une classe présentant un type de vehicule: suivant cette abstraction un vehicule est Caractérisé par sa marque, son modèle et sa date de mise en service


Diapositive 21


Exemple d’héritage multiple (2/2)class VehiculeTerrestre {

public:

VehiculeTerrestre(char* immatriculation);

~VehiculeTerrestre();

void setPuissanceReelle(

PuissanceReelle pr);

const PuissanceReelle

getPuissanceReelle() const;

virtual PuissanceFiscale

getPuissanceFiscale() const;


protected:

...

};

class Bateau {

public:

Bateau(char *port, char* immatriculation);

virtual ~Bateau();

virtual Date ControleTechnique();

void setNombreDeMoteurs(unsigned int nb);

virtual char* RefHomologation();


protected:

...

};

class Camion: public Vehicule, public VehiculeTerrestre ...

class Paquebot: public Vehicule, public Bateau ...

class VoitureAmphibie: public Vehicule,

public VehiculeTerrestre,

public Bateau ...

Par ailleurs l’analyse du pb permet de suggérer que les véhicules terrestres et les bateaux ont des propriétés spécifiques qui peuvent intéresser l’application Une solution est de créer une sous classe de Vehicule pour les véhicules terrestre et une sous classe de vehicule pour les bateaux. Mais que se passera-t-il si on veut modéliser les véhicules amphibie? Il faudra créer une nouvelle classe qui dupliquera l’information contenue dans VehiculeTerreste et Bateau Une meilleur façon d’exprimer cela est de faire appel à l’héritage multiple. Dans ce but nous déclarons deux classes indépendantes qui regroupent les propiétés spécifiques des vehicules terrestres et des bateaux. Il faut noter ici que ces deux classes n'ont pas de super�classe; elles sont autonomes l'une de l'autre. Elles sont appelées classes fusionnantes, car elles sont destinées à fusionner ensemble et avec d'autres classes pour produire de nouvelles sous�classes. Dans les deux cas, nous formons la sous�classe par héritage depuis deux super�classes. Les instances de la sous�classe Camion renferment par conséquent la structure et le comportement hérités de la classe Vehicule ainsi que ceux hérités de la classe VehiculeTerrestre. Pour déclarer une classe pour un véhicule amphibie qui est à la fois véhiculeTerreste et Bateau . Nous pourrons écrire class VoitureAmphibie: public Vehicule, public VehiculeTerrestre, public Bateau ...


Diapositive 22


Problèmes liés à l’héritage multipleclass Vehicule {

public:

protected:

char* _modele;

char* _marque;

Date _dateMiseEnService;

....

};

class VehiculeTerrestre: public Vehicule {

public: ....

const Vitesse VitesseMax() const;

....

};

class Bateau: public Vehicule {

public:

const Vitesse VitesseMax() const;

};

class VoitureAmphibie:

public VehiculeTerrestre,

public Bateau ...

Vehicule

VéhiculeAmphibie

VéhiculeTerrestre Bateau

Conceptuellement, l'héritage multiple est facile à comprendre, mais il introduit des difficultés pratiques dans les langages de programmation. Ceux�ci doivent résoudre deux problèmes : les collisions de noms dans les super�classes, et l'héritage répété. Les collisions surviennent lorsque deux ou plusieurs super�classes définissent un champ ou une opération portant le même nom ou présentant la même signature. En C++, ces collisions sont évitées par la qualification explicite ; en Smalltalk, la première occurrence du nom sera choisie. L'héritage répété survient lorsque deux ou plusieurs super�classes partagent un ancêtre commun. Dans cette situation, l'arbre d'héritage a la forme d'un losange. La question est de savoir si la classe fille contient alors une ou plusieurs copies de cet ancêtre commun. Quelques langages interdisent les héritages répétés, certains font un choix arbitraire et d'autres, dont C++, laissent la décision au programmeur. En C++, les classes virtuelles permettent de signifier le partage des structures répétées, alors que les classes non virtuelles provoquent la duplication de ces structures (la qualification explicite étant alors nécessaire pour distinguer les copies). Attention à ne pas abuser de l’héritage multiple. Par exemple, une maquette d'auto est un type de maquette, mais ce n'est pas un type d'auto. De nouveau, le test discriminatoire de l'héritage s'applique : si a n'est pas un «type» de A, alors a ne devrait pas hériter de A.


Diapositive 23


AgrégationDécrit la hiérarchie « partie de »L’agrégation permet le regroupement de structures liées logiquementAvec l’héritage, ces groupes peuvent être réutilisés facilement dans plusieurs abstractions.L’agrégation permet de constituer des abstractions de niveau supérieur

Alors que ces hiérarchies «est un» désignent des relations de généralisation/ spécialisation, les hiérarchies «partie de» décrivent des relations d'agrégation


Diapositive 24


Exemple d’agrégation

class Local {

public:

Local();

virtual ~Local();

...

protected:

Radiateur * _radiateur[50];

CapteurTemperature * _capteur[50];

PlanDeChauffage _programme;

};

Cette classe représente une abstraction d’un local contrôlé par le système de domotique. Selon le vocabulaire de la hiérarchie de composant, une classe est à un niveau d'abstraction supérieur à celui des sous�classes qui la constituent. Par conséquent la classe Local est à un niveau d'abstraction supérieur à celui du type Radiateur ou Capteur de Température sur lequel elle se construit. L'agrégation n'est pas un concept propre à la programmation orientée objets. Tout langage qui autorise des structures de données de type enregistrement permet l'agrégation. Cependant, la combinaison de l'agrégation et de l'héritage est très puissante l'agrégation permet le regroupement physique de structures liées logiquement, et l'héritage permet une réutilisation facile de ces groupes dans diverses abstractions. L'agrégation soulève le problème de la propriété. Notre abstraction d'un local d’avoir plusieurs radiateurs (éventuellement de plusieurs types). Le remplacement d'un radiateur ne change pas l'identité du local en lui�même, et la suppression d'un local ne détruit pas obligatoirement toutes ses radiateurs (ils peuvent être réutilisés dans un autre local). En d'autres termes, les durées de vie d'un local et de ses constituants sont indépendants. Nous représentons ce fait, dans l'exemple précédent, en incluant des pointeurs sur des objets Radiateur plutôt que des valeurs. A l'opposé, nous avons décidé qu'un objet PlanDeChauffage est intrinsèquement lié à un objet Local et ne peut exister de façon indépendante. C'est pour cela que nous utilisons une valeur de PlanDeChauffage ; lorsque nous détruisons l'objet Local, nous détruisons l'instance de PlanDeChauffage qu'il contient.


Diapositive 25


Le Typageun type est une caractérisation précise de propriétés structurelles ou comportementales qu'un ensemble d'entités partagentLe typage est le fait d'imposer la classe d'un objet, de façon que des objets de types différents ne puissent pas être intervertis ou, tout au plus, qu'ils ne puissent être intervertis que de façon très restrictive.

Le concept de type découle principalement des théories des types abstraits Le typage nous permet d'exprimer les abstractions afin que le langage de programmation dans lequel nous les écrivons puisse imposer nos choix de conception. Ce qui est essentiel pour la programmtion à grande échelle. la notion de typage introduit l’idée de conformité: par exemple lorsque nous divisons une distance par une durée, la valeur obtenue doit correspondre à une vitesse, pas à une masse. De même, multiplier une température par une force n'a pas de sens, mais multiplier une masse par une force en a un. Ce sont deux exemples de typage fort, lorsque les règles de notre domaine n'autorisent que des combinaisons particulières d'abstractions.


Diapositive 26


Typage Fort et FaibleIl existe différents types de langages:

fortement typés, faiblement typés ou non typés

Le typage fort empêche le mélange des entitésLe typage faible apporte plus de souplesse

Un langage de programmation donné peut être fortement typé, faiblement typé ou même non typé, tout en étant orienté objets. Par exemple, Eiffel est fortement typé, c'est�à�dire que la conformité des types est assurée: une opération ne s'applique à un objet que si la signature de cette opération est définie dans la classe ou les super�classes de l'objet. Dans les langages fortement typés, la violation de la conformité des types peut être relevée durant la compilation. A l'inverse, Smalltalk n'est pas typé : un client peut envoyer n'importe quel message à une classe, même si cette dernière ne sait comment y répondre. Les violations des règles de typage ne peuvent être détectées qu'à l'exécution, et elles se manifestent souvent sous la forme d'erreurs. Les langages comme C++ sont hybrides: ils ont une tendance au typage fort, mais il est possible d'ignorer ou contourner ces règles. En C++, les synonymes ne sont pas de nouveaux types. En particulier, PuissanceFiscale et PuissanceRéelle sont tous deux des nombres entiers non signés et peuvent être intervertis. C++ est, sous cet angle, faiblement typé : les valeurs des types élémentaires (comme int et float) ne peuvent être distinguées à l'intérieur d'un même type. Par contraste, des langages comme Ada et Object Pascal assurent un typage fort des types élémentaires. En Ada, par exemple, les types dérivés et les sous�types laissent le développeur créer de nouveaux types, restreints en valeur ou en précision par rapport aux types plus généraux. En C++ si on se reporte aux classes de Véhicules précedement définies Vehicule v1, v2; Bateau b; VehiculeTerrestre a;


Date d = v1.DateMiseEnService(); //legal Char *num = b.ControleTechnique(); // a.PuissanceRelle(150); V1.PuissanceFiscale() //illegal (detecté à la compil) a.NombreDeMoteurs() //illegal « » Le typage fort permet d'utiliser le langage de programmation afin d'imposer certains de nos choix de conception. Il est donc particulièrement important lorsque la complexité augmente. Cependant, il a une face cachée. Dans les faits, il introduit des dépendances sémantiques telles que même une légère modification de l'interface d'une classe de base entraîne la recompilation de toutes ses sous�classes. En l'absence de classe paramétrées, (dont on parlera plus tard) il est difficile de créer des ensembles hétérogènes d'objets qui puissent être correctement typés. Pour créer des ensembles hétérogène en C++ on utilise souvent un idiome particulier de créer une classe qui gère des pointeurs sur des void). Par exemple on veut établir l’inventaire du parc des biens d’une entreprise class Inventory public: Inventory ); ~Inventory(); vois add(void* ) ; void remove(void*); void* mostRecent() const; void apply(Boolean (*)(void*)); private: … ); On peut insérer dans cette structure dans éléments physiques des radiateurs et des capteurs mais aussi des PlanDeChauffage!! Ce qui est contraire à ce que l’abstraction est sensée représenter. On peut aussi insérer un objet Radiateur, puis un objet CapteurDeTemperature, et sauf si on y fait tres attention, on peut utiliser la méthode GetMostRecent en supposant obtenir un radiateur et obtenir un capteur de température. Deux solutions une classe de basse englobante de tous les composants inventoriable (1er pb) utiliser l’identification de type à l’exécution RTTI en C++ Un langage fortement typé garantit la cohérence des types dans toutes les expressions. Les affectations V1 = v2 et v1 = b sont légales La première l'est parce que la classe de la variable gauche (Vehicule) est la même que celle du membre droit. La seconde est valide car la classe de la variable gauche (Vehicule) est une super�classe de celle de la variable droite (Bateau). Mais cette affectation provoque une perte d'informations (appelée troncature en C++). La sous-classe Bateau introduit une structure et un comportement plus étendus que ceux de sa classe de base; ces informations ne peuvent être copiées dans une instance de la classe de base. Les instructions ci�dessous sont interdites a= v1; // Illegal a = b; // Illegal


La première l'est parce que la classe de la variable gauche (Vehicule) est une sous�classe de celle de la variable droite (VehiculeTerrestre). La seconde est invalide car les deux classes sont soeurs et ne se trouvent pas dans la même ligne d'héritage (bien qu'elles aient une super�classe commune). l'usage des langages fortement typés entraîne des avantages importants • «Sans vérification de type, un programme peut dans la plupart des langages "se planter" mystérieusement à l'exécution. • Dans la plupart des systèmes, le cycle édition/ compilation/déboguage est si fastidieux qu'une détection précoce des erreurs est indispensable. • Les déclarations de type aident à documenter les programmes. • La plupart des compilateurs peuvent générer un code objet plus efficace lorsque les types sont déclarés» Les langages non typés offrent une plus grande souplesse, mais même avec ceux�ci, dans presque tous les cas, le programmeur connaît en fait les types d'objets qui doivent être les arguments d'un message, et quel genre d'objet sera renvoyé. Pratiquement, la sécurité offerte par les langages fortement typés compense largement la perte de flexibilité qu'un langage non typé aurait autorisé, particulièrement pour la programmation à grande échelle.


Diapositive 27


Typage dynamique et statiqueDifférent du concept de type fort ou faibleSe réfère au moment où sont résolus les typesStatique (Précoce ou Early Binding)

Les types sont affectés au moment de la compilation

Dynamique (Tardive ou Late Binding)Les types sont affectés aux moment de l’exécutionCombiné à l’héritage, la résolution dynamique entraîne le polymorphisme qui est un concept important de la programmation OO.

Comme typage fort et résolution sont des concepts indépendants, un langage peut être à la fois fortement et statiquement typé (Ada), fortement typé et supporter la résolution dynamique (Object Pascal et C++), ou non typé et autoriser la résolution dynamique (Smalltalk). Pour illustrer ces concepts de typage: Soit la fonction suivante: Vehicule& Utiliser(Vehicule& v1, Vehicule & v2); L’appel de cette fonction avec n’importe qu’elle instance de Vehicule ou de ses sous classes respecte les contraintes de type. Dans la fonction on utilise une expression de la forme if (v1.DateMiseEnService() > v2.DateMiseEnService()) v1.FaireLePlein(); Else v2.FaireLePlein(); Quel est le sens de if (v1.DateMiseEnService() > v2.DateMiseEnService()) l’ opération DateMiseEnService n'est définie que dans la classe de base Vehicule ; quelle que soit la classe ou sous�classe de l'instance que nous utilisons comme paramètre réel, ce sera l'opération de la classe de base qui sera appelée. L'invocation de DateMiseEnService est, ici, résolue de façon statique : durant la compilation, nous savons déjà quelle sera la fonction appelée.


l'invocation de l'opération FaireLePlein, est résolue de façon dynamique. Cette opération est déclarée dans la classe de base puis redéfinie dans les sous-classes. Si le paramètre réel est une instance de Vehicule, ce sera Vehicule::FaireLePlein qui sera appelée; s'il s'agit d'une instance de VehiculeTerrestre ce sera VehiculeTerrestre::FaireLePlein qui sera appelée; et s'il s'agit d'une instance de Bateau ce sera Bateau::FaireLePlein qui sera Cette particularité est appelée polymorphisme ; elle représente, en théorie des types, un concept dans lequel un nom unique (tel qu'une déclaration de variable) peut désigner des objets de nombreuses classes différentes reliés par une super�classe commune. Le polymorphisme est le résultat de l'interaction entre héritage et résolution dynami-que. C'est peut�être, avec la notion d'abstraction, l'élément le plus puissant des langages de programmation orientés objets, et c'est ce qui distingue la programmation orientée objets de la programmation plus traditionnelle avec les types abstraits.


Diapositive 28


SimultanéitéPlusieurs flots de contrôleSupportée par de nombreux SELa simultanéité s’occupe de l’abstraction des processus et de leur synchronisationDans un système OO, la simultanéité est la propriété qui distingue un objet actif d’un autre qui ne l’est pasLa simultanéité permet à des objets différents d'agir en même temps

Dans certains genres de problèmes, un système automatisé peut avoir à gérer en même temps de nombreux événements. D'autres problèmes nécessitent tant de calculs qu'ils excèdent les possibilités d'un ordinateur unique. Dans chacun de ces cas, il est naturel d'envisager, pour la mise en oeuvre, soit l'utilisation d'un ensemble distribué d'ordinateurs, soit l'usage de processeurs pouvant faire du multi-tâches . De nombreux systèmes d'exploitation supportent aujourd'hui la simultanéité; il y a donc des opportunités (et des demandes) plus importantes pour qu'elle apparaisse dans les systèmes orientés objets. Ainsi, UNIX dispose de l'appel système fork, qui crée un nouveau processus. De même, Windows NT et OS/2 sont multi�actifs (multi�thread) et incluent des interfaces spécifiques afin de créer et de manipuler des processus. l'utilisation de la simultanéité dans les langages orientés objets n'est pas très différente par rapport aux autres genres de langages POO ou pas, tous les problèmes traditionnels de programmation simultanée subsistent. Construire un gros logiciel est difficile ; en concevoir un qui renferme des tâches de contrôle multiples est encore plus difficile car on doit se soucier de questions telles que blocage, interblocage, épuisement des ressources, exclusion mutuelle et synchronisation. la POO peut faciliter les questions de simultanéité, en l'occultant à l'intérieur d'abstractions réutilisables. Chaque objet (tiré d'une abstraction du monde réel) peut représenter une tâche de contrôle séparée (une abstraction de processus). De tels objets sont dits actifs. Dans un système basé sur une


architecture orientée objets, nous pouvons concevoir le monde comme composé d'un ensemble d'objets coopérants, certains d'entre eux étant actifs et servant de centres d'activité indépendants. Notre précédente discussion de l'abstraction a présenté la classe CapteurDeTemperatureActif, dont le comportement consistait à mesurer périodiquement la température, puis à appeler une fonction réflexe d'un client lorsque la température changeait d'un certain nombre de degrés. Nous n'avons pas expliqué comment obtenir ce comportement. C'est un secret de mise en oeuvre, mais il est clair qu'une certaine forme de simultanéité est nécessaire. Il existe généralement trois approches de la simultanéité en conception orientée objets: la simultanéité est une caractéristique du langage (ADA-> notion de tâche et de rendez vous) Bibliothèques de classes -> AT&T fournit une bibliothèque qui contient des classes Sched, Timer, Task, Sema… Utilisation des interruptions -> necessite une connaissance détaillée du matériel. Quelle que soit l'approche choisie, il faut comprendre une chose au sujet de la simultanéité. Dès qu'on l'a introduite dans un système, il faut étudier comment les objets actifs synchronisent leurs activités entre eux et avec les objets purement séquentiels. Par exemple, si deux objets actifs essaient d'envoyer des messages à un troisième, nous devons réaliser une exclusion mutuelle afin que l'état de l'objet cible ne soit pas corrompu quand les deux objets actifs essaient en même temps de le modifier. Ceci constitue un carrefour où les idées d'abstraction, d'encapsulation et de simultanéité se rencontrent. En présence de la simultanéité, il ne suffit pas de définir les méthodes d'un objet; nous devons aussi être certains que la sémantique de ces méthodes est préservée même s'il existe plusieurs flots de contrôle.


Diapositive 29


PersistanceUn objet occupe une certaine place en mémoireUn objet dure un certain tempsNaissance des Bases de données orientées objetsPeu de langages offrent la persistance

BOOSurcouche OO aux SGBDR

Dans les systèmes supportant la simultanéité:

persistance spatiale , un objet pouvant se « déplacer » entre les machines et les processus

Plusieurs types de persistance: Résultats temporaires dans une évaluation d'expression • Variables locales dans des activations de procédure • variables statiques, variables globales et éléments du tas dont la durée de vie est différente de la portée • données qui persistent entre les exécutions d'un programme • données qui persistent entre différentes versions d'un programme • données qui survivent au programme Les langages de programmation traditionnels traitent en général seulement les trois premiers genres de persistance d'un objet ; la persistance des trois derniers genres est typiquement du domaine des bases de données. Ceci conduit à un affrontement culturel, qui produit parfois de très étranges architectures. Les programmeurs voulant traiter les 3 derniers cas et les architectes de BD les trois premiers!!! l'introduction du concept de persistance dans le modèle à objets donne naissance aux bases de données orientées objets. En pratique, de telles bases de données sont construites sur une technologie éprouvée, comme les modèles de bases de données séquentielles, indexées, hiérarchiques, en réseau ou relationnelles. Mais elles offrent par la suite au programmeur l'abstraction d'une interface orientée objets, à travers laquelle les interrogations de la base de données et les autres opérations sont réalisées au moyen d'objets dont la durée de vie dépasse celle d'un programme particulier. Cette unification simplifie grandement le développement de certains types d'applications. En particulier, elle nous permet, au sein d'une application, d'employer les mêmes méthodes de conception pour les parties liées à la base de données comme pour les autres.


Très peu de langages orientés objets offrent un support direct de la persistance (ou la supporte mal) La persistance concerne beaucoup plus que la durée de vie des données. Dans les bases de données orientées objets, non seulement l'état d'un objet persiste, mais sa classe doit aussi dépasser n'importe quel programme particulier, afin que chaque programme interprète de la même façon cet état préservé. Cela rend plus difficile le maintien de l'intégrité d'une base de données lorsque sa taille augmente, surtout si nous devons modifier la classe d'un objet. La persistance est la propriété d'un objet à travers laquelle son existence transcende le temps (ie. l'objet continue d'exister après que son créateur cesse d'exister) et / ou l'espace (ie. l'objet se déplace par rapport à l'emplacement mémoire où il a été créé).


Diapositive 30


Avantages du modèle à objetsSystèmes incorporant les 5 attributs des systèmes complexesPermet d’exploiter la puissance des langages objetsFavorise la réutilisation de logiciel et d’architectureProduction de logiciel basés sur des formes intermédiaires stablesRéduit les risques inhérents au développement de systèmes complexesIntellectuellement séduisant car naturel

Le modèle à objets ne rejette pas tous les principes éprouvés et les leçons qu'on peut tirer de ces méthodes plus anciennes. Au lieu de cela, il introduit plusieurs éléments nouveaux s'appuyant sur des modèles plus anciens. Ainsi, le modèle à objets offre un certain nombre d'avantages significatifs que les autres modèles ne procurent pas. L'utilisation du modèle à objets amène à construire des systèmes qui incorporent les cinq attributs des systèmes complexes bien structurés, ce qui est le plus important:

• Les systèmes complexes sont hiérarchisés • Le choix des composants primaire est arbitraire et dépend de l’observateur • Les liaisons intra-composant sont plus fortes que les liaisons inter-composants • Les systèmes sont formés d’un petit nombre de sous systèmes différents • Un système complexe qui fonctionne a toujours évolué a partir d’un système simple qui a

fonctionné •

L'utilisation du modèle à objets nous aide à exploiter la puissance expressive de tous les langages de programmation basés sur objets et orientés objets. Comme l'indique Stroustrup, «la meilleure façon de tirer parti d'un langage tel que C++ n'est pas toujours claire. Des améliorations significatives de productivité et de qualité ont été réalisées en utilisant C++ comme un "meilleur C", avec un peu d'abstraction de données apportée aux endroits où elle est clairement utile. Cependant, des améliorations supplémentaires beaucoup plus importantes ont été faites en tirant parti, dans le processus de conception, des hiérarchies de classes. Ceci est souvent appelé conception orientée objets et c'est là qu'on a rencontré les plus grands avantages de l'utilisation de C++ »


L'utilisation du modèle à objets favorise non seulement la réutilisation du logiciel mais aussi d'architectures complètes, qui amène la création d'applications-types. Les systèmes orientés objets sont souvent plus petits que leurs équivalents non orientés objets. Ceci signifie non seulement moins de code à écrire et à maintenir, mais aussi une meilleure réutilisation du logiciel, qui se traduit par des avantages en coût et en temps. L'utilisation du modèle à objets produit des systèmes basés sur des formes intermédiaires stables, qui résistent mieux aux changements. Ceci signifie aussi que de tels systèmes évoluent facilement avec le temps et n'ont pas besoin d'être abandonnés ou complètement re-conçus au moindre changement majeur de spécifications. Le modèle à objets réduit les risques inhérents au développement de systèmes complexes, principalement parce que l'intégration est répartie tout au long du cycle de vie plutôt que d'apparaître ponctuellement comme un événement majeur. La méthodologie des modèles à objets, en facilitant une séparation intelligente des sujets, réduit aussi le risque du développement et augmente notre confiance dans la justesse de la conception.


Diapositive 31


Résumé (1/2)La maturité du génie logiciel -> analyse et conception OOL’abstraction dénote les caractéristiques essentielle d’un objetL’encapsulation permet de séparer l’interface contractuelle et la mise en œuvreLa modularité permet du découper un système en sous ensemble cohérents et faiblement liés

• La maturation du génie logiciel a conduit au développement de l'analyse, de la conception et des méthodes de programmation orientées objets, qui concernent toutes les questions de la programmation «à grande échelle». • Il y a plusieurs paradigmes de programmation différents : orientés procédures, orientés objets, orientés logique, orientés règles et orientés contraintes. • Une abstraction dénote les caractéristiques essentielles d'un objet, qui le distinguent de tous les autres et, par conséquent, fournissent des frontières conceptuelles claires et adaptées au point de vue de l'observateur. • L'encapsulation est le processus de compartimentation des éléments qui consti-tuent la structure et le comportement d'une abstraction. Elle permet de séparer l'interface contractuelle d'une abstraction de sa mise en oruvre. • La modularité est la propriété d'un système qui a été décomposé en un ensemble de modules cohérents et faiblement couplés. • La hiérarchie est un rangement ou un classement des abstractions. • Le typage est l'imposition d'une classe à un objet, afin que des objets de types différents ne puissent pas être intervertis ou, au pire, qu'ils ne puissent l'être que de façon limitée. • La simultanéité est la propriété qui distingue un objet actif d'un objet non actif. • La persistance est la propriété d'un objet à travers laquelle son existence transcende le temps et/ou l'espace.


Diapositive 32


Résumé (2/2)La hiérarchie est un classement des abstractionsLe typage permet que des objets ne soient pas intervertisLa simultanéité distingue les objets passifs des objets actifsLa persistance permet aux objets de traverser le temps et l’espace


Diapositive 33


Questions en suspensQue sont exactement les classes et les objets ?Comment identifier correctement les classes et les objets utiles à une application particulière ?Quelle est la notation convenable pour exprimer l'architecture d'un système orienté objets ?Quel procédé peut nous conduire à un système orienté objets bien structuré ?

Programmation et Développement orientés objetssuffi.free.fr/poo/02-Modele_objet.pdf · Chapitre...

Documents

Transcript of Programmation et Développement orientés objetssuffi.free.fr/poo/02-Modele_objet.pdf · Chapitre...