partie 7: evolution du modèle objet — programmation orientée objet en c++

Fabio [email protected]

Programmation Orientée Objet en C++Programmation Orientée Objet en C++

7ème Partie:7ème Partie: EvolutionEvolution du Modèle Objetdu Modèle Objet

© 1997-2003 Fabio HERNANDEZ172POO en C++:Evolution du Modèle Objet

Vue d'EnsembleVue d'Ensemble

Notions de base Types, variables, opérateursContrôle d'exécutionFonctionsMémoire dynamiqueQualité du logicielEvolution du modèle objet Objets et classesFonctions membresClasses génériquesHéritagePolymorphismeHéritage multipleEntrée/sortie


Table des MatièresTable des Matières

MotivationEvolution des langages de programmationTopologie des langages de programmationCycle de vie du logicielEléments du modèle objetRésumé


MotivationMotivation

Nous nous intéressons principalement aux problèmes du développement de logiciel de qualité industrielleCaractéristiques de ces produits

complexité: impossible de maîtriser pour un individutailledurée de vie importantede plus en plus des personnes/entreprises dépendent de leur bon fonctionnement (finance, transport, énergie, médecine, médias, télécommunications,...)coût


Motivation (suite)Motivation (suite)

Stratégies pour traiter cette complexitédécomposition

"divide et impera"nous avons besoin de comprendre les parties pour maîtriser le toutdécomposition par algorithmesdécomposition par objets

abstractionignorer les détails et se concentrer sur l'essentielcréer un modèle général (idéal)

hiérarchieclassification identification des propriétés et des structures communes et individuellesidentification des interactions entre les objets de la hiérarchie


Motivation (suite)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é expressiveNécessité d'exprimer les solutions en termes d'objets plus proches du domaine du problème


EvolutionEvolution des langages de programmationdes langages de programmation

Première génération1954-1958FORTRAN, ALGOL 58calcul scientifiquele vocabulaire du domaine du problème était les mathématiques

☺ "FORTRAN should virtually eliminate coding and debugging": FORTRANPreliminary Report, IBM, November 1954

Deuxième génération1959-1961FORTRAN II, ALGOL 60, COBOL, LISPaccent sur les abstractions algorithmiquessous-programmescompilation séparée


EvolutionEvolution des langages de programmation des langages de programmation (suite)(suite)

Deuxième génération (suite)structure en bloquestypes de donnéesdescription de donnéesfichierspointeurslistesramasse-miettes (garbage collection)machines plus puissantesspectre des problèmes automatisables plus large, en particulier pour les applications de gestion


EvolutionEvolution des langages de programmation des langages de programmation (suite)(suite)

Troisième génération1962-1970PL/1, ALGOL 68, PASCAL, SIMULAapparition du transistor et des circuits intégréscoût des machines en baissemachines plus puissantesproblèmes plus complexesabstraction des données

Quatrième génération1970-Smalltalk, ADA, C++, EIFFEL, Java


Topologie des langages de programmationTopologie des langages de programmation

Première et début de deuxième générationprogrammes: données globales et sous-programmesstructure des données globale exposée à tous les sous-programmesdifficulté à maintenir l'intégrité du système, spécialement pour les gros systèmessous-programmes fortement coupléssignification implicite des données


Topologie des langages de programmation Topologie des langages de programmation (suite)(suite)

Première et début de deuxième génération (suite)

Données

Sous-programmes



Fin de deuxième et début de troisième générationsous-programmes comme mécanisme d'abstractionpassage des paramètresimbrication de sous-programmesportée et visibilité des déclarationsméthode de conception structurée avec les sous-programmes comme brique de baseplus de contrôle sur les abstractions algorithmiquespas de solution pour la programmation de grands systèmespas de support pour la conception des données



Fin de deuxième et début de troisième génération (suite)

Données

Sous-programmes



Fin de troisième générationprojets de programmation plus ambitieuxéquipes de développement plus grandesbesoin de développer différentes parties du même système indépendammentmodule compilé séparémentau début le module était juste un conteneur arbitraire de données et de sous-programmesle module n'était pas considéré comme mécanisme d'abstractionpas des règles pour garantir la cohérence sémantique entre les interfaces des modules



Fin de troisième génération (suite)

Données

Sous-programmes

Modules



Langages orientés objetcomplexité des données contribue substantiellement à la complexité globale du systèmebesoin de bons mécanismes de description d'objets abstraits et pas seulement des opérations abstraitesnotion de typebrique de base du modèle physique: collection de classes et objets (module) au lieu de sous-programmesbrique de base du modèle logique: classes et objetspas de données globales (ou presque)modèle extensible: à chaque niveau d'abstraction des collectionsd'objets collaborent pour atteindre le comportement souhaité



Langages orientés objet (suite)


Cycle de vie du logicielCycle de vie du logiciel

Plusieurs étapes dans le développement du logicielcollecte des besoinsanalyseconceptionimplémentationtests

Collecte des besoinsdescription du problème en termes du vocabulaire du domainerègles du domaine en question sont incluesparticipation des utilisateursobjectif: document avec la spécification des besoins


Cycle de vie du logiciel (suite)Cycle de vie du logiciel (suite)

Analyseobjectif: comprendre le problèmeidentification des classes et objets du domaine du problèmeréponse à la question quoi

Conceptionidentification des composants logiciels necéssaires pour construire la solution au problèmedécomposition orientée par les objets du problèmedescription du modèle logique et physiquedescription du modèle statique et dynamiqueconception des panneaux, des rapports, des bases des données, distribution des applications, composants de communicationsréponse à la question comment



Implémentationécriture des programmes en un langage de programmationprogrammes sont organisés comme une collection d'objets qui coopérentchaque objet est une instance d'une classeles classes font partie d'une hiérarchie des classesobjectif: des programmes exécutables

Testsobjectif: vérifier que la solution construite correspond aux besoins



Besoins

Analyse

ConceptionImplémentation

Tests

if (..)else


ElémentsEléments du modèle objetdu modèle objet

Quatre éléments majeurs du modèleabstractionencapsulationmodularitéhiérarchie

Trois éléments mineurstypesconcurrencepersistence


ElémentsEléments du modèle objet (suite)du modèle objet (suite)

Abstractionstratégie pour gérer la complexitécaractéristiques essentiels d'un objet qui servent à définir des limites conceptuelles entre les objetsrelative à la perspective de l'observateurfocalisée sur la vue de l'extérieur d'un objetséparation entre le comportement de l'objet de son implémentationcomment décider quelles sont les bonnes abstractions d'un domaine donné?

Encapsulationfaçon de cacher l'information d'un objetpermet de modifier l'implémentation d'un objet sans que les utilisateurs de cet objet soient impactésdonnées et procédures sont emballées dans un même paquet


ElémentsEléments du modèle objet (suite)du modèle objet (suite)

Modularitépartitionnement d'un programme en plusieurs composants individuelsinterface (limites) bien définies entre les composants d'un mêmeprogrammeclasses et objets constituent le modèle logique du programmemodules constituent le modèle physiquecompilation séparée

Hiérarchieorganisation des abstractionsrelations entre classesexemple: la vache est un mammifère


RésuméRésumé

Le modèle objet: évolution et pas révolutionBasé sur des concepts qui ont fait leur preuve par le passéDécomposition algorithmique atteint ses limitesLangages s'éloignent de la machine pour s'approcher de plus en plus du domaine du problèmeDécomposition orientée objet permet de traiter la complexité inhérente aux problèmes d'aujourd'hui

partie 7: evolution du modèle objet — programmation orientée objet en c++

Documents