Remerciez-le!

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

Module : Analyse et conception orientée objet UML : Langage de modélisation obj

Module : Analyse et conception orientée objet UML : Langage de modélisation objet unifié ISTA-TAZA Formateur : Abdelmajid LAMKADAM TDI 2ème Année ISTA – TAZA TDI 2ème Année Module : Analyse et conception orientée objet Formateur : LAMKADAM Abdelmajid 2 Sommaire 1. Introduction 2. Présentation d'UML • Définition • Les méthodes objet et la genèse d'UML • Rôle d’UML • Avantages et inconvénients d'UML 3. Modéliser avec UML • Qu'est-ce-qu'un modèle ? • Comment modéliser avec UML ? • Une démarche itérative et incrémentale • Une démarche pilotée par les besoins des utilisateurs 4. Modéliser les Vues d'un système • Vues statiques • Vues dynamiques 5. Modéliser les Aspects d'un système • Aspect statique • Aspect dynamique • Aspect fonctionnel 6. Modéliser les Diagrammes d'un système • Diagramme du cas d’utilisation • Diagramme de séquences • Diagramme de collaboration • Diagramme de classes • Diagramme d’objets • Diagramme d’états transition • Diagramme d’activités • Diagramme de composants • Diagramme de déploiement 7. Synthèse et conclusion ISTA – TAZA TDI 2ème Année Module : Analyse et conception orientée objet Formateur : LAMKADAM Abdelmajid 3 1. Introduction : 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. Penser objet avec UML, pour concevoir objet : Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts abstraits, indépendants des langages d'implémentation et des contraintes purement techniques. Les langages de programmation ne sont pas un support d'analyse adéquat pour "concevoir objet". Ils ne permettent pas de décrire des solutions en terme de concepts abstraits et constituent un cadre trop rigide pour mener une analyse itérative. Pour conduire une analyse objet cohérente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de propriétés et de cardinalités... Utiliser le langage de programmation comme support de conception ne revient bien souvent qu'à juxtaposer de manière fonctionnelle un ensemble de mécanismes d'implémentation, pour résoudre un problème qui nécessite en réalité une modélisation objet. Au risque d'en décourager certains et d'en décevoir d'autres, l'approche objet nécessite une analyse réfléchie, qui passe par différentes phases exploratoires ! Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits cartésiens... Voilà pourquoi il ne faut pas se contenter d'une implémentation objet, mais se discipliner à "penser objet" au cours d'une phase d'analyse préalable. Toutes les dérives fonctionnelles de code objet ont pour origine le non respect des concepts de base de l'approche objet (encapsulation...) ou une utilisation détournée de ces concepts (héritage sans classification...). Ces dérives ne sont pas dues à de mauvaises techniques de programmation ; la racine du mal est bien plus profonde ! Bref, programmer en C++ ou en Java n'implique pas forcément concevoir objet... Les difficultés de mise en oeuvre d'une approche "réellement objet" ont engendré bien souvent des déceptions, ce qui a longtemps constitué un obstacle important à l'essor des technologies objet. Beaucoup ont cédé au leurre des langages de programmation orientés objet et oublié que le code n'est qu'un "moyen". Le respect des concepts fondamentaux de l'approche objet prime sur la manière dont on les implémente. Ne penser qu'à travers un langage de programmation objet est un mirage qui vous détourne de l'essentiel. Pour sortir les technologies objet, l'OMG propose UML. ISTA – TAZA TDI 2ème Année Module : Analyse et conception orientée objet Formateur : LAMKADAM Abdelmajid 4 2. Présentation d’UML : Définition : UML (Unified Modeling Language), qui se traduit par : "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. Né de la fusion des méthodes objet dominantes (OMT, Booch et OOSE), puis normalisé par l'OMG en 1997, UML est rapidement devenu un standard incontournable. UML n'est pas à l'origine des concepts objet, mais il en en donne une définition plus formelle et apporte la dimension méthodologique qui faisait défaut à l'approche objet. 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. Le but de cette présentation n'est pas de faire l'apologie d'UML, ni de restreindre UML à sa notation graphique, car le véritable intérêt d'UML est ailleurs. En effet, maîtriser la notation graphique d'UML n'est pas une fin en soi. Ce qui est primordial, c'est d'utiliser les concepts objet à bon escient et d'appliquer la démarche d'analyse correspondante. Cette présentation a donc pour objectif, d'une part, de montrer en quoi l'approche objet et UML constituent un "plus" et d'autre part, d'exposer comment utiliser UML dans la pratique, c'est-à-dire comment intégrer UML dans un processus de développement et comment modéliser avec UML. Les méthodes objet et la genèse d'UML : • Les premières méthodes d'analyse : (années 70) o Découpe cartésienne (fonctionnelle et hiérarchique) d'un système. • L'approche systémique : (années 80) o Modélisation des données + modélisation des traitements (Merise, Axial, IE...). • L'émergence des méthodes objet : (1990-1995) o 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) ? o Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) ! o Aucune méthode ne s'est réellement imposée. • Les premiers consensus : (1995) o OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un système Issue du centre de R&D de General Electric. Notation graphique riche et lisible. o OOD (Grady Booch) : vues logiques et physiques du système Définie pour le DOD, afin de rationaliser de développement d'applications ADA, puis C++. Ne couvre pas la phase d'analyse dans ses 1ères versions (préconise SADT). Introduit le concept de package (élément d'organisation des modèles). o OOSE (Ivar Jacobson) : couvre tout le cycle de développement Issue d'un centre de développement d'Ericsson, en Suède. La méthodologie repose sur l'analyse des besoins des utilisateurs. • L'unification et la normalisation des méthodes : (1995-1997) ISTA – TAZA TDI 2ème Année Module : Analyse et conception orientée objet Formateur : LAMKADAM Abdelmajid 5 o UML (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes : • UML aujourd'hui est un standard incontournable: o UML est le résultat d'un large consensus (industriels, méthodologistes...). o UML est le fruit d'un travail d'experts reconnus. o UML est issu du terrain. o UML est riche (il couvre toutes les phases d'un cycle de développement). o UML est ouvert (il est indépendant du domaine d'application et des langages d'implémentation). o Après l'unification et la standardisation, bientôt l'industrialisation d'UML : les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering, OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...). o XML (format d'échange standard de modèles UML). • UML évolue mais reste stable: o L'OMG RTF centralise et normalise les évolutions d'UML au niveau international. o Les groupes d'utilisateurs UML favorisent le partage des expériences. o De version en version, UML gagne en maturité et précision, tout en restant stable. o UML inclut des mécanismes standards d'auto-extension. o La description du métamodèle d'UML est standardisée (OMG-MOF). Note : UML n'est pas une mode, c'est un investissement fiable ! Le rôle d’UML : • UML n'est pas une méthode ou un processus ! o Si l'on parle de méthode objet pour UML, c'est par abus de langage ! o Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modélisation. o Propose aussi un processus, qui régit l'enchaînement des activités de production d'une entreprise. o UML a été pensé pour permettre de modéliser les activités de l'entreprise, pas pour les régir. o Un processus de développement logiciel universel est une utopie : Impossible de prendre en uploads/Management/ cours-uml 1 .pdf