SlideShare une entreprise Scribd logo
1  sur  25
Télécharger pour lire hors ligne
Programmation Orientée Objet en C++
    7ème Partie: Evolution du Modèle Objet



                Fabio Hernandez
              Fabio.Hernandez@in2p3.fr
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Topologie des langages de programmation
                       (suite)
   Langages orientés objet (suite)




POO en C++:Evolution du Modèle Objet   187   © 1997-2003 Fabio HERNANDEZ
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
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
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
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
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
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
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
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

Contenu connexe

Tendances

Introdot Netc Sharp Fr
Introdot Netc Sharp FrIntrodot Netc Sharp Fr
Introdot Netc Sharp Fr
Gregory Renard
 
Visual Studio 2008 Overview
Visual Studio 2008 OverviewVisual Studio 2008 Overview
Visual Studio 2008 Overview
Gregory Renard
 

Tendances (20)

Partie 14: Entrée/Sortie — Programmation orientée objet en C++
Partie 14: Entrée/Sortie — Programmation orientée objet en C++Partie 14: Entrée/Sortie — Programmation orientée objet en C++
Partie 14: Entrée/Sortie — Programmation orientée objet en C++
 
Partie 10: Classes Génériques — Programmation orientée objet en C++
Partie 10: Classes Génériques — Programmation orientée objet en C++Partie 10: Classes Génériques — Programmation orientée objet en C++
Partie 10: Classes Génériques — Programmation orientée objet en C++
 
Partie 4: Fonctions - Programmation orientée objet en C++
Partie 4: Fonctions - Programmation orientée objet en C++Partie 4: Fonctions - Programmation orientée objet en C++
Partie 4: Fonctions - Programmation orientée objet en C++
 
Partie 6: Qualité du Logiciel — Programmation orientée objet en C++
Partie 6: Qualité du Logiciel — Programmation orientée objet en C++Partie 6: Qualité du Logiciel — Programmation orientée objet en C++
Partie 6: Qualité du Logiciel — Programmation orientée objet en C++
 
Cours Visual Basic.NET
Cours Visual Basic.NETCours Visual Basic.NET
Cours Visual Basic.NET
 
Chap1V2019: Cours en C++
Chap1V2019: Cours en C++Chap1V2019: Cours en C++
Chap1V2019: Cours en C++
 
Chap1: Cours en C++
Chap1: Cours en C++Chap1: Cours en C++
Chap1: Cours en C++
 
Chap 6 : classes et interfaces
Chap 6 : classes et interfacesChap 6 : classes et interfaces
Chap 6 : classes et interfaces
 
Chapitre4: Pointeurs et références
Chapitre4: Pointeurs et références Chapitre4: Pointeurs et références
Chapitre4: Pointeurs et références
 
Langage C
Langage CLangage C
Langage C
 
Introdot Netc Sharp Fr
Introdot Netc Sharp FrIntrodot Netc Sharp Fr
Introdot Netc Sharp Fr
 
Chap2fonctionscpp
Chap2fonctionscppChap2fonctionscpp
Chap2fonctionscpp
 
Visual Studio 2008 Overview
Visual Studio 2008 OverviewVisual Studio 2008 Overview
Visual Studio 2008 Overview
 
Chapitre2fonctionscppv2019
Chapitre2fonctionscppv2019Chapitre2fonctionscppv2019
Chapitre2fonctionscppv2019
 
Cours de c
Cours de cCours de c
Cours de c
 
Polymorphisme
PolymorphismePolymorphisme
Polymorphisme
 
Cours langage-c
Cours langage-cCours langage-c
Cours langage-c
 
Chapitre 11: Expression Lambda et Référence de méthode en Java
Chapitre 11: Expression Lambda et Référence de méthode en JavaChapitre 11: Expression Lambda et Référence de méthode en Java
Chapitre 11: Expression Lambda et Référence de méthode en Java
 
Le langage C
Le langage CLe langage C
Le langage C
 
Introduction rapide à 'objet et à UML
Introduction rapide à 'objet et  à UML Introduction rapide à 'objet et  à UML
Introduction rapide à 'objet et à UML
 

Similaire à Partie 7: Evolution du Modèle Objet — Programmation orientée objet en C++

U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
Amine Chkr
 

Similaire à Partie 7: Evolution du Modèle Objet — Programmation orientée objet en C++ (20)

Jcom02.ppt
Jcom02.pptJcom02.ppt
Jcom02.ppt
 
Inria - Catalogue logiciels
Inria - Catalogue logicielsInria - Catalogue logiciels
Inria - Catalogue logiciels
 
SystemC
SystemCSystemC
SystemC
 
Captronic grenoble 01102014 version presentee
Captronic grenoble 01102014 version presenteeCaptronic grenoble 01102014 version presentee
Captronic grenoble 01102014 version presentee
 
Outils de construction pour la recherche
Outils de construction pour la rechercheOutils de construction pour la recherche
Outils de construction pour la recherche
 
Réutilisation de code entre Windows 8 et Windows Phone 8.
Réutilisation de code entre Windows 8 et Windows Phone 8.Réutilisation de code entre Windows 8 et Windows Phone 8.
Réutilisation de code entre Windows 8 et Windows Phone 8.
 
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
 
IPTECH CATALOGUE DES SUJETS PFE POUR L'ANNÉE 2018
IPTECH  CATALOGUE DES SUJETS PFE POUR L'ANNÉE 2018IPTECH  CATALOGUE DES SUJETS PFE POUR L'ANNÉE 2018
IPTECH CATALOGUE DES SUJETS PFE POUR L'ANNÉE 2018
 
Lmo02.ppt
Lmo02.pptLmo02.ppt
Lmo02.ppt
 
Développer des codes de simulation numérique avec une équipe "non geek" à l'ULg
Développer des codes de simulation numérique avec une équipe "non geek" à l'ULgDévelopper des codes de simulation numérique avec une équipe "non geek" à l'ULg
Développer des codes de simulation numérique avec une équipe "non geek" à l'ULg
 
Du Polymorphisme dynamique au polymorphisme statique : Abstraction sans perte...
Du Polymorphisme dynamique au polymorphisme statique : Abstraction sans perte...Du Polymorphisme dynamique au polymorphisme statique : Abstraction sans perte...
Du Polymorphisme dynamique au polymorphisme statique : Abstraction sans perte...
 
Introduction aux logiciels libres et à Linux
Introduction aux logiciels libres et à LinuxIntroduction aux logiciels libres et à Linux
Introduction aux logiciels libres et à Linux
 
§G-VisualDECO
§G-VisualDECO§G-VisualDECO
§G-VisualDECO
 
Anton kolotaev. cv fr
Anton kolotaev. cv frAnton kolotaev. cv fr
Anton kolotaev. cv fr
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
 
Architecture logicielle #1 : introduction
Architecture logicielle #1 : introductionArchitecture logicielle #1 : introduction
Architecture logicielle #1 : introduction
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
 
CM uml-concepts-avances
CM uml-concepts-avancesCM uml-concepts-avances
CM uml-concepts-avances
 
Projet+com02.ppt
Projet+com02.pptProjet+com02.ppt
Projet+com02.ppt
 
U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
 

Partie 7: Evolution du Modèle Objet — Programmation orientée objet en C++

  • 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