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

Présentation au sujet: "UML support à la COO 2ème année IUT Calais-Boulogne Bénédicte Talon"— Transcription de la présentation:

1 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

2 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

3 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

4 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

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

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

7 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

8 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

9 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.

10 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.

11 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.

12 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

13 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).

14 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

15 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.

16 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.

17 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

18 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 ( ) : 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 ( ): 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

19 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 ( ) : 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 ( ): 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

20 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.

21 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.

22 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.

23 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)

24 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

25 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).

26 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

27 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é