Télécharger en tant que PDF, PPTX
Partie 7: Evolution du Modèle Objet — Programmation orientée objet en C++
- 1. Programmation Orientée Objeten 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde 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 langagesde programmation (suite) Langages orientés objet (suite) POO en C++:Evolution du Modèle Objet 187 © 1997-2003 Fabio HERNANDEZ
- 18. Cycle de viedu 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 viedu 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 viedu 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 viedu 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èleobjet 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èleobjet (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èleobjet (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