Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

visiteurs sont déjà passés par ici... UML (Unified Modeling Language, traduisez

visiteurs sont déjà passés par ici... UML (Unified Modeling Language, traduisez "langage de modélisation objet unifié") est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, Booch et OOSE. Issu "du terrain" et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à son développement. En l'espace d'une poignée d'années seulement, UML est devenu un standard incontournable. La presse spécialisée foisonne d'articles exaltés et à en croire certains, utiliser les technologies objet sans UML relève de l'hérésie. Lorsqu'on possède un esprit un tant soit peu critique, on est en droit de s'interroger sur les raisons qui expliquent un engouement si soudain et massif ! UML est-il révolutionnaire ? L'approche objet est pourtant loin d'être une idée récente. Simula, premier langage de programmation à implémenter le concept de type abstrait à l'aide de classes, date de 1967 ! En 1976 déjà, Smalltalk implémente les concepts fondateurs de l'approche objet : encapsulation, agrégation, héritage. Les premiers compilateurs C++ datent du début des années 80 et de nombreux langages orientés objets "académiques" ont étayés les concepts objets (Eiffel, Objective C, Loops...). Il y donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts de base de l'approche objet sont stables et largement éprouvés. De nos jours, programmer "objet", c'est bénéficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un réflexe quasi-automatique dès lors qu'on cherche à concevoir des logiciels complexes qui doivent "résister" à des évolutions incessantes. Oui, mais... Tout n'est pas si rose. Beaucoup on cédé aux sirènes de l'orienté objet et leur aveuglement a fait couler bien des projets... Premier hic : l'approche objet est moins intuitive que l'approche fonctionnelle. Malgré les apparences, il est plus naturel pour l'esprit humain de décomposer un problème informatique sous forme d'une hiérarchie de fonctions atomiques et de données, qu'en terme d'objets et d'interaction entre ces objets. Or, rien dans les concepts de base de l'approche objet ne dicte comment modéliser la structure objet d'un système de manière pertinente. Quels moyens doit-on alors utiliser pour mener une analyse qui respecte les concepts objet ? Sans un cadre méthodologique approprié, la dérive fonctionnelle de la conception est inévitable... Beaucoup l'ont appris à leurs dépens. Autre problème critique : l'application des concepts objet nécessite une très grande rigueur. Le vocabulaire précis est un facteur d'échec important dans la mise en oeuvre d'une approche objet (risques d'ambiguïtés et d'incompréhensions). Beaucoup de développeurs (même expérimentés) ne 02/11/2011 Page 1 sur 94 13:57:58 pensent souvent objet qu'à travers un langage de programmation. Or les langages orientés objet ne sont que des outils qui proposent une manière particulière d'implémenter certains concepts objet. Ils ne valident en rien l'utilisation de ces moyens techniques pour concevoir un système conforme à la philosophie objet. Connaître C++ ou Java n'est donc pas une fin en soi, il faut aussi savoir se servir de ces langages à bon escient. La question est donc de savoir "qui va nous guider dans l'utilisation des concepts objet, si ce ne sont pas les langages orientés objet ?". Pour finir : comment comparer deux solutions de découpe objet d'un système si l'on ne dispose pas d'un moyen de représentation adéquat ? Il est très simple de décrire le résultat d'une analyse fonctionnelle, mais qu'en est-il d'une découpe objet ? Pour remédier à ces inconvénients majeurs de l'approche objet, il nous faut donc : 1) un langage (pour s'exprimer clairement à l'aide des concepts objets), qui doit permettre de • représenter des concepts abstraits (graphiquement par exemple), • limiter les ambiguïtés (parler un langage commun, au vocabulaire précis, indépendant des langages orientés objet), • faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions). 2) une démarche d'analyse et de conception objet, pour • ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ, • définir les vues qui permettent de décrire tous les aspects d'un système avec des concepts objets. En d'autres termes : il faut disposer d'un outil qui donne une dimension méthodologique à l'approche objet et qui permette de mieux maîtriser sa richesse. La prise de conscience de l'importance d'une méthode spécifiquement objet ("comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 méthodes objet sont apparues durant le milieu des années 90 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...). Aucune ne s'est réellement imposée. L'absence de consensus sur une méthode d'analyse objet a longtemps freiné l'essor des technologies objet. Ce n'est que récemment que les grands acteurs du monde informatique ont pris conscience de ce problème. L'unification et la normalisation des méthodes objet dominantes (OMT, Booch et OOSE) ne datent que de 1995. UML est le fruit de cette fusion. UML, ainsi que les méthodes dont il est issu, s'accordent sur un point : une analyse objet passe par une modélisation objet. Modélisation, modèle ? 02/11/2011 Page 2 sur 94 13:57:58 Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité en vue d'une utilisation précise. L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur. Un modèle est une vue subjective, mais pertinente de la réalité. Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de la réalité. Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente. Le caractère abstrait d'un modèle doit notamment permettre de faciliter la compréhension du système étudié. Il réduit la complexité du système étudié, permet de simuler le système, le représente et reproduit ses comportements. Concrètement, un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail exploitables par des moyens mathématiques ou informatiques. UML permet donc de modéliser une application selon une vision objet. Mais plus concrètement, qu'est UML ? UML possède plusieurs facettes. C'est une norme, un langage de modélisation objet, un support de communication, un cadre méthodologique. UML est tout cela à la fois, ce qui semble d'ailleurs engendrer quelques confusions... Je vous invite maintenant à découvrir ces différents visages d'UML et par là même, à vous forger votre propre opinion... UML, OMG, OMA et cie. Fin 1997, UML est devenu une norme OMG (Object Management Group). Cela vous semble certainement sans importance, mais pourtant... L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fédère plus de 850 acteurs du monde informatique. Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes. L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un modèle standard pour la construction d'applications à objets distribués (répartis sur un réseau). Pour rester simple, on peut considérer CORBA comme une généralisation de l'architecture clients/serveurs aux objets. Au centre de l'architecture CORBA, un routeur de messages (ORB : Object Request Broker) permet à des objets clients d'envoyer des requêtes et de recevoir des réponses, sans avoir à se préoccuper des détails techniques propres à l'infrastructure du réseau. L'ORB se charge de transmettre les requêtes aux objets concernés, où qu'ils se trouvent (dans le même processus, dans un autre, sur un autre noeud du réseau...). Le bus CORBA (dont l'ORB est le composant central) permet d'assurer la transparence des invocations de méthodes ; les requêtes aux objets semblent toujours être locales. De plus, l'ORB assure une coopération entre objets qui est indépendante des langages de programmation. Le modèle CORBA permet en effet de se focaliser sur les interfaces des objets, qu'on exprime en IDL (Interface Definition Language). L'IDL décrit de manière standard l'interface d'un objet, en faisant abstraction des détails qui relèvent de son d'implémentation. Avec CORBA, il n'est donc pas nécessaire de savoir comment les objets sont codés pour utiliser leurs services. L'utilisation d'IDL comme langage pivot dans la construction d'une architecture, permet de gérer l'hétérogénéité. 02/11/2011 Page 3 sur 94 13:57:58 Cette approche, qui consiste à masquer les couches techniques du réseau (système d'exploitation, processeur, langage de programmation...), permet d'assurer l'interopérabilité de toute application à objets distribués, conforme au modèle CORBA. CORBA fait partie d'une vision globale de la construction d'applications réparties, appelée OMA (Object Management Architecture) et définie par l'OMG. Sans rentrer dans les détails, on peut résumer cette vision par la volonté de favoriser l'essor industriel des technologies objet, en offrant un ensemble de solutions technologiques non propriétaires, qui suppriment les clivages techniques. UML a été adopté (normalisé) par l'OMG et intégré à l'OMA, car il uploads/Philosophie/ cours-uml-francais 1 .pdf