Paradigme de programmation De l ’intérêt de la programmation objet

Présentation au sujet: "Paradigme de programmation De l ’intérêt de la programmation objet"— Transcription de la présentation:

1 Philippe Holland : philippe.holland@free.fr
Paradigme de programmation De l ’intérêt de la programmation objet Philippe Holland :

2 Sommaire Différents paradigmes de programmation
Origine de la programmation objet Principes de programmation objet Bonnes pratiques de conception objet Historique de la modélisation UML Programmation par assamblage alternative au « Make all versus buy all » Typologie des investissements dans les systèmes d ’information

3 Différents paradigmes de programmation
Programmation procédurale : Un programme est vu comme un ensemble d’instructions qui manipulent un ensemble de données Exemples : Fortran, Pascal, C Programmation fonctionnelle : Un programme est vu comme l’équivalent informatique d’une fonction mathématique qui associe à des valeurs d’entrée des valeurs de sorties Exemples : Lisp Programmation logique : Un programme est vu comme un raisonnement logique dont l’exécution est une preuve de la déductibilité d’une formule logique. Exemples : Prolog Programmation objet : Un programme est vu comme un ensemble de petites entités interagissant par messages. Exemples : C++, Java

4 Origine de la programmation objet
La programmation objet est aujourd’hui une réalité industrielle qui comme la plupart des innovations en informatique est issue de la recherche en Intelligence Artificielle : 1967 : SIMULA (Norvège) L’objectif initial était de simuler le comportement d’un système (dans le domaine de la recherche nucléaire) ayant des parties pouvant fonctionner en concurrence. Les langages constituées de suite d’instructions successives ne pouvaient convenir. En poussant jusqu’au bout la logique de programmation modulaire on est parvenu à élaboré un langage permettant de définir des modules stables avec des comportements possibles. C’est la remise en question de la séparation entre données et programmes. 1972 : SMALLTALK (Centre de recherche de Xerox à Palo Alto) Alan Kay souhaitait réaliser un langage de programmation de son ordinateur convivial (souris, écran bitmap,…) il reprend est systématise SIMULA pour faire de SMALLTALK le premier langage objet. Si la cuisine est l’art de réutiliser les restes, la programmation objet est aujourd’hui son équivalent informatique

5 Principes de programmation objet
La séparation classique entre les données et les traitements dans la programmation procédurale est remplacée par des objets qui incorporent des aspects statiques (données) et dynamiques (traitements) dans la programmation objet. Principes de bases : Modélisation (classes et instances) : Une classe regroupe des objets possédant une structure et des comportements communs. Une classe est définie par des attributs et des méthodes qui leur sont applicables. Les objets qui correspondent à une classe sont des instances de cette classe L’encapsulation (des données) : N ’autoriser la modification des données d ’un objet que via ces méthodes. L’activation (méthodes) : Appel de méthode d ’un objet par l ’équivalent d ’un envoi de message L’héritage : Récupération automatique des attributs et méthodes d’une classe parente et de définition d’une hiérarchie de classes

6 Bonnes pratiques de conception objet
Tout est objet Si on peut parler de quelque chose en lui attribuant des propriétés ou que cette chose peut être manipulée alors il faut en faire un objet Autonomie et localité Un programme objet doit être constitué d’unités indépendantes, chacune disposant de sa propre mémoire locale et des opérations qu’elle sait effectuer Composition et affinage L’objectif est de n’écrire que la différence entre ce qui existe et ce qu’on souhaite réaliser en utilisant le classique mécanisme de composition et celui plus original d’affinage qui consiste à hériter de classes plus génériques. Plus on est capable de concevoir des classes abstraites plus on est capable de définir des mécanismes de gestion génériques sans nécessairement disposer de tous les mécanismes d’implémentation propres à des classes de plus bas niveau.

7 Modélisation UML Dans les années 70, il existait en France une profusion de méthodes d’analyse à l’initiative de nombreuses SSII avec deux grandes écoles celle de l’approche par les données et celle de l’approche par les traitements. En 1979, le projet français Merise est lancé avec le soutien du Ministère de l’Industrie et rencontre un vif succès pendant plus d’une décennie. Les nouvelles approches de modélisation et le savoir-faire acquis par les SSII permettent de réconcilier l’approche par les données et l’approche par les traitements et de mettre la modélisation au cœur du processus d’étude, les modèles étant construits pour comprendre, diagnostiquer et proposer des solutions. Le principal reproche à Merise est d’avoir sous-estimé l’importance de la modularité des SI. UML né en 1997 de la fusion de trois méthodes d’analyse orientées objet initialement issues des milieux industriels à l’initiative de Rational Software : Objet Oriented Design de Booch, DOD, structuration de programme Ada et C++ Object Modeling Technique de Rumbaugh, General Electric, modélisation de comportement Object Oriented Software Engineering, Ericson, modélisation d’utilisation du système A partir de 1998, UML est le langage de modélisation retenu comme norme par l’OMG, son intérêt continue de croître depuis auprès des développeurs

8 Programmation par assemblage alternative au « Make all versus Buy all»…
Programmation de logiciel spécifique : Solution optimale pour la satisfaction des besoins métiers Production et maintenance coûteuse Délais de réalisation importants Programmation de logiciel spécifique : Solution optimale pour la satisfaction des besoins métiers Production et maintenance coûteuse Délais de réalisation importants Paramétrage de logiciel générique : Réduction des coûts et de risques à court terme Nécessite une réorganisation des processus métiers Avantage stratégique moins fort Perte de control local Solution parfois inadaptée à certaines problématiques métiers Paramétrage de logiciel générique : Réduction des coûts et de risques à court terme Nécessite une réorganisation des processus métiers Avantage stratégique moins fort Perte de control local Solution parfois inadaptée à certaines problématiques métiers Courbe de réduction des coûts Courbe de réduction des coûts Courbe de flexibilité Courbe de flexibilité Les besoins et les technologies évoluent tellement vite qu’aujourd’hui la programmation par assemblage est inévitable. La programmation par assemblage : Solution optimale pour la satisfaction des besoins métiers Coût maîtrisé Possibilité de développement d’un système stratégique La programmation par assemblage : Solution optimale pour la satisfaction des besoins métiers Coût maîtrisé Possibilité de développement d’un système stratégique 0% 0% % acheté % acheté 100 % 100 % L’alternative offerte par la programmation par assemblage est une solution beaucoup plus souple que la programmation de logiciel spécifique ou le paramétrage de logiciel générique.

9 Typologie des investissements dans les systèmes d ’information
Améliorer la capacité de tous à prendre les bonnes décisions Acquérir un avantage concurrentiel Succès conditionné par l'utilisation Risque élevé (50% d'échec) Systèmes d'aide à la décision Réduire les coûts Systèmes stratégiques Risque faible Retour sur investissement entre 25 et 40% Systèmes transactionnels Accroître la flexibilité, la réactivité Infrastructure Investissement élevé Favorise la croissance On constate pratiquement que les gros investissements réalisés dans le domaine du SI sont plus souvent fondés sur la foi que sur des démonstrations solides