1. Programmation Orientée Objet en C++
7ème Partie: Evolution du Modèle Objet
Fabio Hernandez
Fabio.Hernandez@in2p3.fr

2. Vue d'Ensemble
Notions de base
Types, variables, opérateurs
Contrôle d'exécution
Fonctions
Mémoire dynamique
Qualité du logiciel
Evolution du modèle objet
Objets et classes
Fonctions membres
Classes génériques
Héritage
Polymorphisme
Héritage multiple
Entrée/sortie
POO en C++:Evolution du Modèle Objet 172 © 1997-2003 Fabio HERNANDEZ

3. Table des Matières
Motivation
Evolution des langages de programmation
Topologie des langages de programmation
Cycle de vie du logiciel
Eléments du modèle objet
Résumé
POO en C++:Evolution du Modèle Objet 173 © 1997-2003 Fabio HERNANDEZ

4. Motivation
Nous nous intéressons principalement aux problèmes du
développement de logiciel de qualité industrielle
Caractéristiques de ces produits
complexité: impossible de maîtriser pour un individu
taille
durée de vie importante
de plus en plus des personnes/entreprises dépendent de leur bon
fonctionnement (finance, transport, énergie, médecine, médias,
télécommunications,...)
coût
POO en C++:Evolution du Modèle Objet 174 © 1997-2003 Fabio HERNANDEZ

5. Motivation (suite)
Stratégies pour traiter cette complexité
décomposition
"divide et impera"
nous avons besoin de comprendre les parties pour maîtriser le tout
décomposition par algorithmes
décomposition par objets
abstraction
ignorer les détails et se concentrer sur l'essentiel
créer un modèle général (idéal)
hiérarchie
classification
identification des propriétés et des structures communes et individuelles
identification des interactions entre les objets de la hiérarchie
POO en C++:Evolution du Modèle Objet 175 © 1997-2003 Fabio HERNANDEZ

6. Motivation (suite)
Il est très difficile et anti-naturel de modéliser les problèmes
du monde réel avec des éléments si primitifs que les objets de
type int, float, double, etc.
Besoin de langages de programmation avec plus de capacité
expressive
Nécessité d'exprimer les solutions en termes d'objets plus
proches du domaine du problème
POO en C++:Evolution du Modèle Objet 176 © 1997-2003 Fabio HERNANDEZ

7. Evolution des langages de programmation
Première génération
1954-1958
FORTRAN, ALGOL 58
calcul scientifique
le vocabulaire du domaine du problème était les mathématiques
☺ "FORTRAN should virtually eliminate coding and debugging": FORTRAN
Preliminary Report, IBM, November 1954
Deuxième génération
1959-1961
FORTRAN II, ALGOL 60, COBOL, LISP
accent sur les abstractions algorithmiques
sous-programmes
compilation séparée
POO en C++:Evolution du Modèle Objet 177 © 1997-2003 Fabio HERNANDEZ

8. Evolution des langages de programmation
(suite)
Deuxième génération (suite)
structure en bloques
types de données
description de données
fichiers
pointeurs
listes
ramasse-miettes (garbage collection)
machines plus puissantes
spectre des problèmes automatisables plus large, en particulier pour les
applications de gestion
POO en C++:Evolution du Modèle Objet 178 © 1997-2003 Fabio HERNANDEZ

9. Evolution des langages de programmation
(suite)
Troisième génération
1962-1970
PL/1, ALGOL 68, PASCAL, SIMULA
apparition du transistor et des circuits intégrés
coût des machines en baisse
machines plus puissantes
problèmes plus complexes
abstraction des données
Quatrième génération
1970-
Smalltalk, ADA, C++, EIFFEL, Java
POO en C++:Evolution du Modèle Objet 179 © 1997-2003 Fabio HERNANDEZ

10. Topologie des langages de programmation
Première et début de deuxième génération
programmes: données globales et sous-programmes
structure des données globale exposée à tous les sous-programmes
difficulté à maintenir l'intégrité du système, spécialement pour les gros
systèmes
sous-programmes fortement couplés
signification implicite des données
POO en C++:Evolution du Modèle Objet 180 © 1997-2003 Fabio HERNANDEZ

11. Topologie des langages de programmation
(suite)
Première et début de deuxième génération (suite)
Données
Sous-programmes
POO en C++:Evolution du Modèle Objet 181 © 1997-2003 Fabio HERNANDEZ

12. Topologie des langages de programmation
(suite)
Fin de deuxième et début de troisième génération
sous-programmes comme mécanisme d'abstraction
passage des paramètres
imbrication de sous-programmes
portée et visibilité des déclarations
méthode de conception structurée avec les sous-programmes comme
brique de base
plus de contrôle sur les abstractions algorithmiques
pas de solution pour la programmation de grands systèmes
pas de support pour la conception des données
POO en C++:Evolution du Modèle Objet 182 © 1997-2003 Fabio HERNANDEZ

13. Topologie des langages de programmation
(suite)
Fin de deuxième et début de troisième génération (suite)
Données
Sous-programmes
POO en C++:Evolution du Modèle Objet 183 © 1997-2003 Fabio HERNANDEZ

14. Topologie des langages de programmation
(suite)
Fin de troisième génération
projets de programmation plus ambitieux
équipes de développement plus grandes
besoin de développer différentes parties du même système
indépendamment
module compilé séparément
au début le module était juste un conteneur arbitraire de données et de
sous-programmes
le module n'était pas considéré comme mécanisme d'abstraction
pas des règles pour garantir la cohérence sémantique entre les
interfaces des modules
POO en C++:Evolution du Modèle Objet 184 © 1997-2003 Fabio HERNANDEZ

15. Topologie des langages de programmation
(suite)
Fin de troisième génération (suite)
Données
Sous-programmes
Modules
POO en C++:Evolution du Modèle Objet 185 © 1997-2003 Fabio HERNANDEZ

16. Topologie des langages de programmation
(suite)
Langages orientés objet
complexité des données contribue substantiellement à la complexité
globale du système
besoin de bons mécanismes de description d'objets abstraits et pas
seulement des opérations abstraites
notion de type
brique de base du modèle physique: collection de classes et objets
(module) au lieu de sous-programmes
brique de base du modèle logique: classes et objets
pas de données globales (ou presque)
modèle extensible: à chaque niveau d'abstraction des collections
d'objets collaborent pour atteindre le comportement souhaité
POO en C++:Evolution du Modèle Objet 186 © 1997-2003 Fabio HERNANDEZ

17. Topologie des langages de programmation
(suite)
Langages orientés objet (suite)
POO en C++:Evolution du Modèle Objet 187 © 1997-2003 Fabio HERNANDEZ

18. Cycle de vie du logiciel
Plusieurs étapes dans le développement du logiciel
collecte des besoins
analyse
conception
implémentation
tests
Collecte des besoins
description du problème en termes du vocabulaire du domaine
règles du domaine en question sont inclues
participation des utilisateurs
objectif: document avec la spécification des besoins
POO en C++:Evolution du Modèle Objet 188 © 1997-2003 Fabio HERNANDEZ

19. Cycle de vie du logiciel (suite)
Analyse
objectif: comprendre le problème
identification des classes et objets du domaine du problème
réponse à la question quoi
Conception
identification des composants logiciels necéssaires pour construire la
solution au problème
décomposition orientée par les objets du problème
description du modèle logique et physique
description du modèle statique et dynamique
conception des panneaux, des rapports, des bases des données,
distribution des applications, composants de communications
réponse à la question comment
POO en C++:Evolution du Modèle Objet 189 © 1997-2003 Fabio HERNANDEZ

20. Cycle de vie du logiciel (suite)
Implémentation
écriture des programmes en un langage de programmation
programmes sont organisés comme une collection d'objets qui coopérent
chaque objet est une instance d'une classe
les classes font partie d'une hiérarchie des classes
objectif: des programmes exécutables
Tests
objectif: vérifier que la solution construite correspond aux besoins
POO en C++:Evolution du Modèle Objet 190 © 1997-2003 Fabio HERNANDEZ

21. Cycle de vie du logiciel (suite)
Besoins
Tests Analyse
Implémentation Conception
if (..)
else
POO en C++:Evolution du Modèle Objet 191 © 1997-2003 Fabio HERNANDEZ

22. Eléments du modèle objet
Quatre éléments majeurs du modèle
abstraction
encapsulation
modularité
hiérarchie
Trois éléments mineurs
types
concurrence
persistence
POO en C++:Evolution du Modèle Objet 192 © 1997-2003 Fabio HERNANDEZ

23. Eléments du modèle objet (suite)
Abstraction
stratégie pour gérer la complexité
caractéristiques essentiels d'un objet qui servent à définir des limites
conceptuelles entre les objets
relative à la perspective de l'observateur
focalisée sur la vue de l'extérieur d'un objet
séparation entre le comportement de l'objet de son implémentation
comment décider quelles sont les bonnes abstractions d'un domaine
donné?
Encapsulation
façon de cacher l'information d'un objet
permet de modifier l'implémentation d'un objet sans que les utilisateurs
de cet objet soient impactés
données et procédures sont emballées dans un même paquet
POO en C++:Evolution du Modèle Objet 193 © 1997-2003 Fabio HERNANDEZ

24. Eléments du modèle objet (suite)
Modularité
partitionnement d'un programme en plusieurs composants individuels
interface (limites) bien définies entre les composants d'un même
programme
classes et objets constituent le modèle logique du programme
modules constituent le modèle physique
compilation séparée
Hiérarchie
organisation des abstractions
relations entre classes
exemple: la vache est un mammifère
POO en C++:Evolution du Modèle Objet 194 © 1997-2003 Fabio HERNANDEZ

25. Résumé
Le modèle objet: évolution et pas révolution
Basé sur des concepts qui ont fait leur preuve par le passé
Décomposition algorithmique atteint ses limites
Langages s'éloignent de la machine pour s'approcher de plus en
plus du domaine du problème
Décomposition orientée objet permet de traiter la complexité
inhérente aux problèmes d'aujourd'hui
POO en C++:Evolution du Modèle Objet 195 © 1997-2003 Fabio HERNANDEZ