UML support à la COO 2ème année IUT Calais-Boulogne Bénédicte Talon Conception Objet UML support à la COO 2ème année IUT Calais-Boulogne Bénédicte Talon

Objectifs du cours Acquérir un savoir-faire dans la conception et le développement d’applications objets (Java) Découvrir le langage UML Apprendre une « méthode » de conception orientée objets Développer objet implique une stratégie de découverte des classes, attributs, méthodes Merise incompatible avec la PO puisque orientée systémique (séparation des données et des traitements, BD relationnelles) UML est un langage et non une méthode (ensemble de formalismes de représentation sans démarche officielle) Nous proposerons une méthode pour aider à la réalisation des diagrammes

Présentation de l’enseignement 2 séances de « Conception Objet » de 1h30/semaine Bénédicte Talon Alternance de cours/TD/TP Enseignement groupé sur le 1er semestre Le cours traite de l’aspect conception orientée objet Les TP vous initient à la conception/programmation (documentation JavaDoc, utilisation d’un AGL (Poseidon, ArgoUML, WinDev) pour la description des classes et la RetroConception

Plan du cours Introduction/Rappel Les vues structurelles (statiques) Le diagramme de cas d’utilisation Le diagramme de classes Les vues comportementales (dynamiques) Le diagramme d’interaction Une méthode Objet AGL et Documentation 1 séance pour introduire à UML et aux MOO et faire un peu d’histoire 2 séances pour le diagramme de classes (modèle le plus utilisé par les Concepteurs) 2 séances pour le diagramme de cas indispensable à la définition des besoins et d’ailleurs utilisé par d’autres méthodes 1 séance pour le diagramme d’objet et de composants 1 séance diagramme de déploiement (visualisation de l’architecture ) 2 séances pour les vues dynamiques : collaboration, séquence et état-transition 1 séance pour le diagramme d’activité 1 séance sur la méthodologie (démarche pour accompagner UML) 1 séance pour parler de documentation et d’AGL et répondre aux questions éventuelles

Chapitre 1 Introduction/Rappel Conception Objet Chapitre 1 Introduction/Rappel

Introduction Bibliographie utilisée Petit Test Qu’est ce que la Conception Objet Histoire rapide UML Les différents diagrammes

Bibliographie UML en français UML2 par la pratique – 4ème édition Uml.free.fr UML2 par la pratique – 4ème édition Pascal Roques, EYROLLES, 2005 Conception objet en Java avec BlueJ David Barnes et Michael Kölling, Pearson Education UML Martin Fowler, Le tout en poche, Campus Press Introduction à UML Sinan Si Alhir, O’REILLY UML 2 Benoît Charroux, Aomar Osmani, Yann Thierry-Mieg

Introduction – Conception Objet Approche fonctionnelle non adaptée applications qui évoluent sans cesse complexité croit continuellement Objectif approche objet faciliter l'évolution d'applications complexes

Introduction – Petit Test de connaissances Des concepts évoqués l’an passé Objet Programme objet Classe Encapsulation Surcharge, polymorphisme UML Diagramme de classes Ensemble d’objets qui se disent les uns les autres quoi faire en s’envoyant des messages Ensemble d’objets partageant un état (attributs) et des comportements (méthodes : opérations applicables) entité ayant une existence matérielle ou virtuelle. Toute chose est objet Possède un type précis : la classe qui est le moule de l’objet Possède une interface : face visible de l’objet : attributs et méthodes accessibles Mécanisme consistant à rassembler les données et les méthodes au sein d'une structure Cacher l'implémentation de l'objet, Empêcher l'accès aux données par un autre moyen que les services proposés. Objectif : garantir l'intégrité des données contenues dans l'objet.

Introduction – Conception Objet Objectif méthode objet Structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements (mais sur les deux) Approche objet moins intuitive que l'approche fonctionnelle. plus naturel de décomposer un problème sous forme d'une hiérarchie de fonctions atomiques et de données, qu'en terme d'objets et d'interaction entre ces objets.

Introduction – Conception Objet Très grande rigueur nécessaire développeurs (même expérimentés) pensent à travers un langage de programmation. Les langages orientés objet doivent être considérés comme des outils Comment programmer « objet » un système si l'on ne dispose pas d'un moyen de représentation adéquat ? vocabulaire 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 pensent souvent objet qu'à travers un langage de programmation. 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 pas une fin en soi, il faut aussi savoir se servir de ces langages à bon escient.

Introduction –Conception Objet Les "méthodologues" [Rumbaugh] disent qu'une méthode comporte : une démarche (les étapes, phases et tâches de mise en oeuvre) des formalismes (les modélisations et les techniques de transformation) une organisation et des moyens de mise en oeuvre

Introduction – Conception Objet Langage pour Représenter des concepts abstraits (graphiquement) Limiter les ambiguïtés Faciliter l'analyse langage (pour s'exprimer clairement à l'aide des concepts objets), qui doit permettre de Pré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).

Introduction –Conception Objet Démarche pour penser objet dès le départ, définir les vues (décrire tous les aspects d’un système) Organisation et moyens de mise en œuvre Outils (AGL) Gestion de projet 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, Pour définir les vues qui permettent de décrire tous les aspects d'un système avec des concepts objets. il faut disposer d'un outil qui donne une dimension méthodologique à l'approche objet et qui permette de mieux maîtriser sa richesse

Introduction – Conception Objet Modèle (Formalisme) abstraction de la réalité. vue subjective, mais pertinente de la réalité. frontière entre la réalité et la perspective de l'observateur. reflète des aspects importants Modéliser permet de communiquer Le langage naturel est trop imprécis Le code est précis mais trop détaillé Un modèle est une abstraction de la réalité. L'abstraction : 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. Un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente.

Introduction – Conception Objet L’abstraction Pourquoi ? Faciliter la compréhension du système Réduire la réalité pour de disposer d'éléments de travail exploitables par des moyens mathématiques ou informatiques. Comment ? le représenter et reproduire ses comportements. en réduisant la complexité du système étudié Le caractère abstrait d'un modèle doit permettre de faciliter la compréhension du système étudié. réduit la complexité du système étudié, permet de simuler le système, le représente et reproduit ses comportements. 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.

Introduction – Conception Objet Pour penser et concevoir objet "prendre de la hauteur", jongler avec des concepts abstraits, Les langages de programmation constituent un cadre trop rigide Se discipliner à "penser objet" dès la phase d’analyse Pour penser et concevoir objet, "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. Se discipliner à "penser objet" au cours d'une phase d'analyse préalable

Introduction - Histoire Premières méthodes (années 70) Approche systémique (années 80) Émergence des Méthodes Objets (années 90-95) Booch, Rumbaugh, Jacobson Révision (2000) Unification (années 95-97) Normalisation (fin 1997) Premières méthodes (années 70) Découpe cartésienne (fonctionnelle et hiérarchique) d'un système. Approche systémique (années 80) Modélisation des données + modélisation des traitements (Merise, Axial, IE...) Emergence des méthodes objet (1990-1995) : période de fragmentation Prise de conscience de l'importance d'une méthode spécifiquement objet Plus de 50 méthodes objet apparaissent : Aucune méthode ne s’impose Difficulté à changer de méthode et à s’adapter OMG créée en 1989 Fédère plus de 850 acteurs du monde informatique. Promouvoir des standards Unification et Normalisation des méthodes (1995-1997): période d’unification les 3 amigos se rapprochent Booch’93 (Booch method) OMT-2 (Rumbaugh) OOSE (Jacobson) Le groupe « Analyse et Conception Objet de l’OMG publie une requête RFP (Request For Proposal) => standard définissant signification des concepts OO pour les outils prenant en charge ACOO. Un consortium (dont Rational Software Corp.) soumet UML 1.0 Période de normalisation (fin 1997) UML 1.1 émerge. Toutes les réponses à la requête combinées dans UML 1.1 OMG adopte UML et assume en novembre 1997 la responsabilité du futur développement d’UML Période de révision Plusieurs versions se succèdent OMG forme un groupe qui réçoit les commentaires du public et apporte les corrections UML promu au travers outils, livres, etc Version 1.4 OMG travaille à version 2.0 Période d’industrialisation En paralllèle de révision OMG soumet UML à ISO Industrialisation

Introduction - Histoire Premières méthodes (années 70) Découpe cartésienne (fonctionnelle et hiérarchique) d'un système. Approche systémique (années 80) Modélisation des données + modélisation des traitements (Merise, Axial, IE...) Emergence des méthodes objet (1990-1995) : période de fragmentation Prise de conscience de l'importance d'une méthode spécifiquement objet Plus de 50 méthodes objet apparaissent : Aucune méthode ne s’impose Difficulté à changer de méthode et à s’adapter OMG créée en 1989 Fédère plus de 850 acteurs du monde informatique. Promouvoir des standards Unification et Normalisation des méthodes (1995-1997): période d’unification les 3 amigos se rapprochent Booch’93 (Booch method) OMT-2 (Rumbaugh) OOSE (Jacobson) Le groupe « Analyse et Conception Objet de l’OMG publie une requête RFP (Request For Proposal) => standard définissant signification des concepts OO pour les outils prenant en charge ACOO. Un consortium (dont Rational Software Corp.) soumet UML 1.0 Période de normalisation (fin 1997) UML 1.1 émerge. Toutes les réponses à la requête combinées dans UML 1.1 OMG adopte UML et assume en novembre 1997 la responsabilité du futur développement d’UML Période de révision Plusieurs versions se succèdent OMG forme un groupe qui réçoit les commentaires du public et apporte les corrections UML promu au travers outils, livres, etc Version 1.4 OMG travaille à version 2.0 Période d’industrialisation En paralllèle de révision OMG soumet UML à ISO

UML - Généralités Les "méthodologues" préconisent 3 composantes Merise : ensemble "cohérent" sur ces 3 composantes. UML exclusivement formalismes. UML est un langage pas une méthode Les "méthodologues" disent qu'une méthode, pour être opérationnelle, doit avoir 3 composantes: une démarche (les étapes, phases et tâches de mise en oeuvre) des formalismes (les modélisations et les techniques de transformation) une organisation et des moyens de mise en oeuvre Merise s'est attachée, en son temps, à proposer un ensemble "cohérent" sur ces trois composantes. Certaines ont vieilli et ont du être réactualisées (la démarche), d'autre "tiennent encore la route" (les modélisations). UML se positionne exclusivement comme un ensemble de formalismes. Il faut y associer une démarche et une organisation(RUP de Rational par exemple) pour constituer une méthode.

UML - Généralités Exprimer, élaborer des modèles objet Indépendamment de tout langage de programmation. Normalise les concepts objet UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'élaborer des modèles objet, indépendamment de tout langage de programmation.. UML est un langage formel, défini par un métamodèle. Le métamodèle d'UML décrit de manière très précise tous les éléments de modélisation les concepts véhiculés et manipulés par le langage La sémantique de ces éléments UML normalise les concepts objet.

UML - Généralités Langage formel (méta-modèle) Concepts véhiculés et manipulés Sémantique de ces éléments UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'élaborer des modèles objet, indépendamment de tout langage de programmation.. UML est un langage formel, défini par un métamodèle. Le métamodèle d'UML décrit de manière très précise tous les éléments de modélisation les concepts véhiculés et manipulés par le langage La sémantique de ces éléments UML normalise les concepts objet.

UML – 3 initiales Langage : Support de communication Spécifier : exigences Visualiser Construire Documenter : aspect formel Langage <> Processus UML est un support de communication qui facilite la représentation et la compréhension de solutions objet Sa notation permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de solutions. L'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions. Son indépendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel. La notation graphique d'UML n'est que le support du langage. La véritable force d'UML, c'est qu'il repose sur un métamodèle. UML normalise la sémantique des concepts qu'il véhicule ! Langage <> Processus : Processus = ensemble d’étapes dans une méthodologie pour résoudre un problème et développer un système satisfaisant les exigences des users. (Méthodes + techniques + Artefacts : éléments produits et utilisés durant le processus)

UML – 3 initiales Modèle Unifié Représentation d’un sujet Important de ne pas tout représenter en même temps Gérer l’abstraction Unifié Combiner les meilleures pratiques Exclure les infos hors de propos

UML – Un langage les diagrammes Représenter un système selon des vues complémentaires Représentation graphique Véhiculent une sémantique précise ( toujours la même vue d'un système) UML permet de représenter un système selon différentes vues complémentaires : les diagrammes Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du modèle. Chaque type de diagramme UML possède une structure : les types des éléments de modélisation qui le composent sont prédéfinis et véhicule une sémantique précise : il offre toujours la même vue d'un système UML permet de définir et de visualiser un modèle, à l'aide de diagrammes. Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du modèle, pas "le modèle". Chaque type de diagramme UML possède une structure (les types des éléments de modélisation qui le composent sont prédéfinis). Un type de diagramme UML véhicule une sémantique précise (un type de diagramme offre toujours la même vue d'un système). Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et dynamiques d'un système. Par extension et abus de langage, un diagramme UML est aussi un modèle (un diagramme modélise un aspect du modèle global).

UML – Les diagrammes Vues statiques (structurelles) du système : diagrammes de cas d'utilisation     diagrammes d'objets diagrammes de classes diagrammes de composants diagrammes de déploiement Vues dynamiques (comportementales) du système : diagrammes de collaboration diagrammes de séquence diagrammes d'états transitions diagrammes d'activités Collaboration + séquence = Interaction

UML et processus Les auteurs favorisent une approche Dirigée par les use cases Architecturale Itérative Incrémentale Un processus de développement logiciel = Activités collecte exigences analyse conception implémentation test deploiement Il existe différentes approches pour les appliquer (cascade, itérative, …) Mieux gérer la complexité Mieux gérer les changements dans les exigences Offrir des solutions partielles Solliciter les critiques des users / système déjà développé