013 mediha cgi - sensibilisation uml

4,209 views
3,982 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,209
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
58
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Explication sur le plan: les cas d’utilisation ne sont pas dans le « cœur UML », ils ne portent pas de spécificités objet. Ils pourraient être utilisés dans une approche « fonctionnelle ». les concepts objets permettent de comprendre le « cœur d’UML » qui emploie des concepts et une terminologie objet.
  • Attention: la sensibilisation UML n’est pas un cours UML Tous les concepts UML ne seront pas étudiés, la syntaxe ne sera pas vu en détail.
  • Objectif: comprendre l’intérêt de modéliser
  • Maison selon un architecte en batiment Maison selon un analyste/concepteur informatique Maison selon un développeur L’idée est ici de dire qu’ il n’y a pas une seule manière de représenter un concept manipulé par l’utilisateur et que tout ce que l’on fait en informatique ne revient finalement qu’à proposer une représentation du monde réel afin de pouvoir ensuite manipuler les concepts du monde réel. La modélisation UML n’est donc qu’un autre mode d’expression du réel. Avec UML on va faire un dessin comme l’architecte
  • Bien que la connaissance d’UML est un pré-requis à la lecture du schéma ici présent, demandez quelle représentation est la plus facile à comprendre en « un clin œil » ?
  • Comprendre le fonct. du système: avoir une vision du système qui suffit à la compréhension (global pour un niveau de compréhension général, détaillé pour un niveau de compréhension fin et précis) Maîtriser la complexité: gérer des complexites de manière atomique plutôt que de manière globale et avoir une approche de modélisation top-down (en partant du besoin jusqu’au code) Communiquer: avoir un langage commun Automatiser: faciliter le passage au code (langage d’implémentation et SQL) à partir des modèles Accroitre la qualité: mieux identifier et cerner les problèmes , les étudier avant de les réaliser Faciliter la maintenance: faciliter l’analyse d’impact Etre un outil permettant d’organiser et de contrôler: Définir un cadre dans lequel les éléments de modélisation s’inscrivent Donner à modéliser des éléments particuliers à des rôles spécifiques
  • Dire qu’ un modèle n’est pas intrinsèquement exact. Tout dépend de l’intention à l’origine de la modélisation. Chaque modèle correspond à un point de vue par rapport au concept/sujet modélisé. Même par rapport à un même point de vue, le niveau de détail attendu d’un modèle doit être défini. On peut aussi donner l’exemple de la modélisation d’un avion. La vision sera certainement différente si on s’adresse au service de restauration, service de réparation de l’avion, service en charge des réservations…
  • Sémantique: (adjectif) Qui a rapport à la signification, au sens (nom féminin) Etude du langage et des signes linguistiques (mots, expressions, phrases) du point de vue du sens (du grec semantikis « qui signifie »). Ici, il s’agit de définir de manière précise certains concepts dans le contexte UML
  • Expliquer le trigramme UML: Unified Modeling Language Expliquer l’apport de chacun des méthodes: Booch-93 (Grady Booch): couverture complète du sycle de vie orienté sur la construction OMT-2 (James Rumbaugh): couverture complète du cyle de vie orienté sur l’analyse et l’abstraction OOSE (Ivar Jacobson): apport des cas d’utilisation pour la découverte et l’analyse des besoins
  • Expliquer que: UML couvre tout le cycle de vie projet UML peut être utilisé quelque soit le nature de l’information à modéliser
  • Axe fonctionnel: quel sont les besoins ? Axe statique: quelles informations sont nécessaires ? Axe dynamique: comment le système doit-il réagir ?
  • Système: ce qui est construit pour répondre au besoin
  • Le diagramme de contexte permet de positionner les acteurs qui interagissent avec le système.
  • Si le système a pour objectif d’informatiser les services clients rendus dans une agence bancaire. Un acteur pourra être le « Charge de Clientèle » à cause de son rôle qu’il joue vis-à-vis de ce système. Remarque: en aucun cet acteur sera nommé par son nom propre (Jean Dupond).
  • Un cas d’utilisation peut correspondre à : Un processus métier complet informatisé Une activité métier informatisée Un ensemble d’activités métiers informatisées La correspondance dépend du niveau de granularité dans la décomposition des processus métier
  • Pour expliquer la notion de scénario, faire un parallèle avec un reseau routier. Pour aller d’un point A à un point B, plusieurs chemins sont possibles. L’ensemble des scénarios ayant une fin normale (nominal + alternatifs) représentent tous les chemins possibles pour aller de A à B. Les scénarios d’exception sont des sorties anormales du scénario nominal ou des scénarios alternatifs.
  • Préciser que tous ces éléments sont des éléments contenus dans la Fiche Cas d’Utilisation.
  • Les pré-conditions étant les conditions nécessaires à l’exécution du système, elles définissent ce qui est à l’intérieur du cas d’utilisation de ce qui est à l’extérieur du cas d’utilisation.
  • Un scénario est décrit sous forme d’actions-réactions: actions de la part de l’acteur (le porteur de carte), réactions de la part du système. En noir: les actions de l’acteur En rouge: les réactions du système
  • Les numéros d’étape sont indentés par rapport au point de branchement.
  • Chaque objet possède ses propres caractéristiques. Suivant le domaine d’étude, les caractéristiques auxquelles on va s’intéresser peuvent différer.
  • Dans le domaine d’étude « Le Monde », on s’intéresse à la représentation physique. Dans le domaine d’étude « Entreprise », on s’intéresse à la représentation sociale.
  • Attributs: définit l’état Opérations: définit le comportement Remarque: inutile de parler de visibilté.
  • Préciser que la spécialisation/généralisation est un cas particulier de l’héritage. Autre forme d’héritage: la délégation
  • Diagramme de collaboration: identique au diagramme de séquence avec une représentation spatiale alors que le diag de séquence a une représentation temporelle. Diagramme d’objet = diagramme de classe avec une vue « instance »
  • Préciser qu’un diagramme de classes se rapproche d’un MCD en Merise L’objectif est avant tout de modéliser la manière sont sont structurées les données: attributs à l’intérieur d’une classe et relations entres les classes.
  • Préciser qu’un sens de lecture du nom de l’association peut être défini en ajoutant une flèche à côté du nom. Cette possibilité dépend malheureusement des capacités des outils. Ce qu’est un rôle, une multiplicité, une relation Que différents types de relations existent selon la nature du lien entre les objets (agrégation, composition, généralisation/spécialisation)
  • On pourra préciser que le diagramme peut faire intervenir des objets et des sous-systèmes. Diagrammes boite noire: peut être utilisé pour décrire la dynamique d’un cas d’utilisation (on n’entre pas dans les détails du système) Diagramme boite blanche: utilisé pour décrire le contenu d’une fonctionnalité (au cœur du système) Diagramme d’interaction entre sous-systèmes ..
  • Un diagramme d’activités peut se comparer à un MCT ou MOT en Merise
  • Swimlane ou ligne d’eau positionne les activités effectuées par un rôle « Fork » indique que plusieurs activités se déclenchent en même temps « Join » indique que le résultat des 2 activités (3 et 3 bis) sont nécessaires pour exécuter l’activité 4
  • Bien préciser qu’un élément appartient à un seul package. Il peut cependant être représenté dans des diagrammes définis dans d’autres packages. « La photo n’est pas l’objet »
  • Bien préciser qu’un élément appartient à un seul package. Il peut cependant être représenté dans des diagrammes définis dans d’autres packages. « La photo n’est pas l’objet »
  • Le package Client est indépendant. Le package Contrat dépend d’élements du package Client et Compte. Le package Compte dépend d’éléments du package Client. Eviter les dépendances cycliques, bi-directionnelles…
  • Expliquer que dans la MCIP l’utilisation des diagrammes d’E/T n’est préconisée que pour la modélisation de cycle de vie d’objets.
  • On suppose que l’état du cours n’est représenté que pour l’inscription d’étudiants à un cours
  • Dire qu’un composant est un module qui représente toutes sortes d’éléments physiques qui entrent dans la fabrication des applications informatiques. Un module peut être un simple fichier, un package ou des bibliothèques chargés dynamiquement. Le terme composant peut également représenter une famille de composants. Ex dans le cas d’une application web: - composant IHM statique (pages html) - composant IHM dynamique (pages jsp) - composant fonctionnel métiers (classes java) - accesseurs physiques (code cobol) - contrôleur (servlet) - ...
  • Faire le lien entre les packages et les composants Préciser qu’une relation de dépendances indique qu’un composant fait référence aux services offerts par un autre composant. Ce type de dépendance reflète un choix de réalisation. Une relation de dépendance est une flèche pointillée qui pointe de l’utilisateur vers le fournisseur. La relation de dépendance peut être spécialisée par un stéréotype afin de préciser la nature des choix de réalisation qui entraînent la relation de dépendance.
  • Objectif: Montrer la disposition physique des différents matériels (nœuds du système) Positionner les composants dans les nœuds Un nœud est un « composant » physique, il est représenté par un cube. En général, un seul diagramme de déploiement suffit pour modéliser l’équipement d’un système. Les relations entre les nœuds symbolisent des supports de communication « a priori » bidirectionnel. Une relation peut-être stéréotypée. Ce stéréotype permet généralement de préciser le protocole de communication entre es nœuds (TCP/IP, RMI, RNIS…)
  • Un nœud correspond à une machine physique. Sur chaque nœud, on positionne les différents composants.
  • Exigences: définition du besoin et déclinaison du besoin en exigences Analyse: détermination de la solution fonctionnelle Conception: détermination de la solution technique
  • Niveau analyse=Modélisation d’une solution fonctionnelle Niveau conception= Modélisation d’une solution technique
  • Parler du caractère obligatoire des diagrammes: Aucun diagramme est obligatoire (fonction de la nature du projet, de son contexte, des exigences) D’une manière générale: Les diagrammes fortement recommandés sont: Diagramme de cas d’utilisation pour l’identification des exigences fonctionnelles Diagrammes de classes pour la modélisation des données Diagrammes de séquence pour l’identification des messages échangés entre acteurs Les diagrammes à usage contextuel (à utiliser si nécessaire): Diagrammes d’activités pour modéliser les règles de gestion et les algos complexes Diagrammes d’états-transition pour modéliser le cycle de vie d’un objet Diagramme de composants pour spécifier l’architecture physique Diagramme de déploiement pour définir les nœuds du système et positionner les composants sur les noeuds
  • 013 mediha cgi - sensibilisation uml

    1. 1. Programme Harmonie Sensibilisation UML 1
    2. 2. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 2
    3. 3. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 3
    4. 4. Objectifs  Apprécier les intérêts de la modélisation visuelle  Savoir quels sont les diagrammes UML disponibles  Comprendre les objectifs de chaque diagramme UML  Comprendre comment sont modélisés les aspects statiques et dynamiques d’un système informatique  Comprendre comment est organisé un modèle UML  Comprendre la syntaxe UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 4
    5. 5. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 5
    6. 6. Une certaine vision du monde… Maison + superficie 1..* 1..* Et age Por t e + numéro + largeur Public class Maison { private Vector etages; private Vector portes; private float superficie; public Maison() { … } … }PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 6
    7. 7. Une certaine vision du monde… Une maison est constituée de plusieurs étages. Chaque maison possède au moins un étage. Une maison comporte un certain nombre de portes, au moins une. Une maison est caractérisée par sa superficie, chaque étage possède un numéro et chaque porte comporte une largeur précise. Maison + superficie 1..* 1..* Et age Por t e + numéro + largeurPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 7
    8. 8. Objectifs d’une modélisation  Comprendre le fonctionnement du système  Maîtriser la complexité et la cohérence du système  Communiquer sans ambiguïté au sein de l’équipe  Permettre l’automatisation de certaines tâches  Accroître la qualité du produit livré  Faciliter la maintenance  Etre un outil de travail permettant de  Organiser les travaux de l’équipe de réalisation  Contrôler l’avancement des travauxPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 8
    9. 9. Points de vue – Niveau de détail Plan de Modèle circulation d’urbanisme   Ville   Modèle Modèle d’équipement de la populationPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 9
    10. 10. Un langage commun  Nécessité de définir un langage commun pour modéliser  Sémantique précise des différents concepts  Notation graphique  Règles d’utilisation des concepts du langagePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 10
    11. 11. Origines d’UML UML Unification des concepts et des notations Intégration des « meilleures pratiques » Booch OMT - 2 OOSE ’93 Standard géré par l’OMG Version utilisée UML 1.5 Dernière version UML 2.0 http://www.omg.orgPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 11
    12. 12. A quoi sert UML ?  UML est un langage pour  Comprendre et décrire un besoin de manière non ambiguë  Spécifier un système (simple ou complexe)  Concevoir une solution  Documenter la solution  Communiquer au sein d’une équipe  UML est à usage général  Système logiciel, matériel, organisation,..  Domaine bancaire, assurance, avionique, télécommunication…  Processus de développement en cascade, itératif…PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 12
    13. 13. Vision générale d’UML Fonctionnel Description des services rendus par le système Modéliser le problème suivant 3 axes Description comportementale Description structurelle du système du système Statique DynamiquePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 13
    14. 14. Vision générale d’UML Fonctionnel Diagramme des cas d’utilisation Modéliser le problème suivant 3 axes Diagramme d’objetsDiagramme de séquence Diagramme de classesDiagramme de collaboration Diagramme de composantsDiagramme d’activité Diagramme de déploiementDiagramme états - transitions Statique DynamiquePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 14
    15. 15. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 15
    16. 16. Les cas d’utilisation  A quoi servent-ils ? Pour quoi faire ?  Déterminer les frontières du système  Comprendre le fonctionnement du système du point de vue de l’utilisateur  Représenter les interactions entre les utilisateurs et le système  Préparer la phase d’analyse des exigences UML n’est pas suffisant ici, il est nécessaire d’ajouter:  Des descriptions textuelles  Détail du cas d’utilisation  Ajout des exigences non-fonctionnelles  Ajout des règles de gestion  Compléments aux éléments modélisés avec UML  Les besoins de restitution  Les écrans  L’éditiquePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 16
    17. 17. Les cas d’utilisation Les concepts UML manipulés sont  Diagramme de cas d’utilisation  Acteur  Déclencheur UC1 Acteur A  Récepteur Act eur UC2  Cas d’utilisation Acteur B UC3 Cas d ut ilisat ion Acteur C  Diagramme de contexte Acteur A Système Acteur Y Acteur X PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 17
    18. 18. Les cas d’utilisation Définition : Acteur  Un acteur est une entité externe au système  Qui interagit avec le système  Qui attend des services de la part du système  Qui est une personne physique ou un autre système informatique  Un acteur est nommé par le rôle qu’il joue vis-à-vis du système  Les interactions avec le système sont représentées par des cas d’utilisationPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 18
    19. 19. Les cas d’utilisation Définition : Cas d’utilisation  Un cas d’utilisation modélise un service rendu par le système  Décrit des interactions entre un acteur et le système  Est déclenché par un événement émis par un acteur  Correspond à une unité d’intention complète de la part de l’acteur vis-à- vis du système  Apporte une valeur ajoutée notable à l’acteur Créer compte Chargé de Clientèle Créer un client Autoriser Responsable d’agence créditPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 19
    20. 20. Les cas d’utilisation Contenu d’un cas d’utilisation  Le déroulement d’un cas d’utilisation est contrôlé par les acteurs  Les cas d’utilisation ne s’enchaînent pas !  Plusieurs acteurs peuvent participer à un cas d’utilisation  La dynamique d’un cas d’utilisation est décrite par une série de scénarios  Scénario nominal ou scénarios alternatifs  Scénarios d’exception  Un scénario est une succession d’événements envoyés par l’acteur au système et de réponses de la part du système Fin anormale Début Fin normalePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 20
    21. 21. Les cas d’utilisation La Fiche Cas d’UtilisationUn cas d’utilisation estdécrit textuellement parune « Fiche Casd’Utilisation »Dans le cadre d’Harmonieun modèle de documentformalise la « Fiche Casd’Utilisation » PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 21
    22. 22. Les cas d’utilisation Contenu de la Fiche Cas d’Utilisation  Nom du cas d’utilisation: Nom décrit sous forme de verbe à l’infinitif, suivi d’un complément.  Résumé : Résume l’intention du cas d’utilisation. Peut être utilisé au début du processus d’identification des cas d’utilisation.  Valeur ajoutée : Ce qu’apporte les cas d’utilisation pour l’acteur (les acteurs) déclencheur d’un point de vue métier.  Acteurs : Acteurs participant (déclencheurs et récepteurs) à la réalisation du cas d’utilisation  Pré-conditions : Ce qui doit être vrai au niveau du système pour pouvoir déclencher le cas d’utilisation  Scénarios : Description textuelle des échanges entre acteurs et système  Post-conditions : Ce qui a changé dans le système une fois le cas d’utilisation terminé avec succès ou échec  Vision synthétique : Diagramme d’activité résumant le cas d’utilisation  Règles de gestion : Règles applicables au cas d’utilisation  Contraintes opérationnelles : Exigences non fonctionnelles associées au cas d’utilisation  Besoins de restitution : éléments de restitution (écrans ou rapports d’édition) associés au cas d’utilisationPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 22
    23. 23. Les cas d’utilisation Exemple : GAB  Cas d’utilisation : Retirer de l’argent Retirer de  Acteur : Porteur de carte l’argent Porteur de carte  Pré-conditions  Aucune carte n’est dans le lecteur  De l’argent est disponible  Post-conditions de succès  Le GAB a été débité du nombre de billets correspondant au montant retiré  Post-conditions d’échec  Le GAB n’a pas délivré les billets demandés par le porteur de carte  Le GAB a avalé la carte du porteurPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 23
    24. 24. Les cas d’utilisation Exemple : GAB Scénario nominal 1- Le porteur de carte introduit sa carte dans le lecteur de cartes du GAB 2- Le GAB vérifie que la carte introduite est bien une carte 3- Le GAB demande au porteur de carte de saisir son code d’identification 4- Le porteur de carte saisit son code d’identification 5- Le GAB compare le code d’identification avec celui codé sur la puce de la carte 6- Le GAB demande une autorisation au système dautorisation 7- Le système dautorisation donne son accord et indique le solde hebdomadaire. 8- Le GAB demande au porteur de carte de saisir le montant désiré du retrait 9- Le porteur de carte saisit le montant désiré du retrait. 10- Le GAB contrôle le montant demandé par rapport au solde hebdomadaire 11- Le GAB demande au porteur de carte sil veut un ticket 12- Le porteur de carte demande un ticket 13- Le GAB rend sa carte au porteur de carte 14- Le porteur de carte reprend sa carte 15- Le GAB délivre les billets et un ticket 16- Le porteur de carte prend les billets et le ticketPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 24
    25. 25. Les cas d’utilisation Exemple : GAB Scénarios alternatifs  A1 : code d’identification erroné L’enchaînement A1 démarre au point 5 du scénario nominal. 5.1 Le GAB indique au client que le code est erroné, pour la première ou deuxième fois 5.2 Le GAB enregistre l’échec sur la carte Le scénario nominal reprend au point 3  A2 : montant demandé supérieur au solde hebdomadaire L’enchaînement A2 démarre au point 10 du scénario nominal. 10.1 Le GAB indique au client que le montant demandé est supérieur au solde hebdomadaire Le scénario nominal reprend au point 3 Scénario d’exception  E1 : code d’identification erroné L’enchaînement A1 démarre au point 5 du scénario nominal. 5.1 Le GAB indique au client que le code est erroné, pour son troisième essai 5.2 Le GAB enregistre l’échec sur la carte 5.3 Le GAB avale la carte.PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 25
    26. 26. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 26
    27. 27. Concepts Objets Pourquoi une approche objet ? Approche Fonctionnelle Approche Objet Fonction Conduire Pilote principale Avion Sous-fonction 1 Sous-fonction 2 Dirige atterrisageSous-fonction Sous-fonction Sous-fonction Sous-fonction Tour de 1.1 1.2 2.1 2.2 contrôle• Besoin d’identifier toutes les fonctions dès le • Approche par « morceau »début • Décomposition du problème• La « fonction » induit la structure (difficulté • Adaptation / Évolution du système plus facilede faire évoluer l’architecture) PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 27
    28. 28. Concepts Objets Les avantages d’une approche objet  Décomposition du « problème » en morceaux plus facilement gérables  Décomposer / diviser pour comprendre  Composer / réunir pour construire  Intégration/Tests  Intégration de composants élémentaires  Cohérence des éléments intégrés  Facilité d’évolution et de maintenance  Ajout/Evolution de fonctionnalités plus faciles à intégrer  Etude d’impact plus facile Les points forts:  Construction du complexe à partir de l’élémentaire  Capacité à regrouper ce qui est séparé  Intégrer statiquement et dynamiquement les constituants du systèmePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 28
    29. 29. Concept objet Définition: Objet  Exemple d’objets: Pierre Duval Sophie DurandLes caractéristiques communes qui les qualifient diffèrent selon le domaine d’étude. Une représentation physique Taille Une représentation sociale  Pointure Métier   Couleur des yeux Fonction   … Salaire  …   Mais ces personnes physiques ont une identité propre. Ce sont des objets de leur domaine d’étude PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 29
    30. 30. Concept objet Définition: classe  Une classe est une représentation abstraite d’un concept qui existe dans un domaine modélisé  Une classe est un descripteur d’objet Le monde Entreprise Salarié Personne Est une classePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 30
    31. 31. Concepts objet Définition : Objet  Un objet est caractérisé par  Une identité (unique)  Un état (porté par la valeur de ses attributs et ses liens avec les autres objets)  Un comportement  L’exécution d’un système repose sur la collaboration entre les objets qui le composentPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 31
    32. 32. Concepts objet Définition : Classe Abstraction = modèle ConcessionnaireDomaine d’étude = Monde réel Modélisation Voiture Est une classe Voiture Modélisation Moteur Réservoir Production PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 32
    33. 33. Concepts objet Définition : Classe  Les objets d’une même classe (on parle d’instances de la classe) possèdent la même définition  Attributs (valorisés par chaque objet)  Opérations  Relations  De manière individuelle, chaque objet  Possède ses propres valeurs pour les différents attributs  Possède ses propres liens avec les autres objets  Peut réaliser telle ou telle opération en fonction de son propre étatPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 33
    34. 34. Concepts objet Classe et Objets La classe Voiture Des objets VoitureNom de la classe Voiture la voiture de Paul - couleur: bleu - couleur - marque: Renault Attributs - marqu - vitesse: 0 - vitesse e la voiture de Pierre + demarrer ( ) - couleur: verte + tourner ( ) - marque: Peugeot - vitesse: 45 Opérations + accelerer ( ) PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 34
    35. 35. Concepts objet Classification  Objectif  Factoriser des données ou des traitements communs  Rendre spécifique un comportement  Classification = généralisation et spécialisation  Généralisation : regroupement des caractéristiques communes à plusieurs classes dans une super-classe plus générale  Spécialisation : Ajout de caractéristiques spécifiques dans une sous-classe ou adaptation des caractéristiques transmises Moyen de transport - vitesse maximum - nombre de passagers + démarrer ( ) Vélo Bateau - nombre de vitesses - tirant deau + changer de vitesse ( ) + jeter lancre ()PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 35
    36. 36. Les diagrammes UML Diagramme de cas d’utilisation Diagramme de séquence Diagramme de classes <<interface>> implements <<maître>> <<caractéristiques>> uc1 I_composant M_composant Classe C Objet 1 Objet 2 Objet 3 Objet 4 +Service A -Attribut a -Attribut b Acteur 1 +Service B +Service C +Service D -Attribut c -Attribut d Classe A Classe BActeur 1 -Attribut e -Attribut f uc2 <<rôle>> R_classe G +Opération a +Opération b -Attribut g +Opération c +Opération h 0..1 nom m 1..* nom n uc3 <<rôle>> R_classe E <<rôle>> R_classe F nom o * Classe D uc4Acteur 2 Acteur 3 /Attribut i +Opération d -Attribut h +Opération i +Opération f +Opération g Etat 4 entry/ action exit/ action Etat 5 Diagramme d’activités Diagramme d’objets Diagramme d’états Activité 1 Etat 2 entry/ action Objet 1 nom a Objet 2 : classe a do/ activity Etat 3 nom b nom c Activité 2 Activité 3 décision Activité 4 Objet 3 : classe a Objet 4 nom d Activité 5 Activité 6 nom e nom f Objet 5 Acteur 1 Objet 6 message 3 Etat 1 Etat 6 Diagramme de collaboration Diagramme de composants Diagramme de déploiement Composant 1 Objet 3 message 4 Objet 2 Nœud 1 « base de données » message 1 BD 1 Composant 1 Composant 2 message 5 message 2 Noeud 2 Composant 3 Objet 4 Objet 1 Composant 2 PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 36 message
    37. 37. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de collaboration  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 37
    38. 38. Diagramme de classes Objectifs  A quoi cela sert ? Pour quoi faire ?  Modéliser les données (étape préparant la réalisation du MLD et MPD)  Définir les traitements applicables aux objets d’une classe  Objectifs  Modéliser les relations structurelles entre les classes  Obtenir un diagramme statique des entités impliquées  Représenter un point de vue sur le modèle Diagramme de classes <<interface>> implements <<maître>> <<caractéristiques>> I_composant M_composant Classe C -Attribut a +Service A -Attribut b +Service B -Attribut c +Service C -Attribut d +Service D Classe A Classe B -Attribut e -Attribut f -Attribut g <<rôle>> +Opération a R_classe G +Opération b +Opération c +Opération h nom m nom n 0..1 1..* <<rôle>> <<rôle>> * R_classe E R_classe F nom o Classe D /Attribut i -Attribut h +Opération d +Opération i +Opération f +Opération gPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 38
    39. 39. Diagramme de classe association 1 Banque - nom Client - nom * - adresse 1 < appartient à titulaire 1..* Compte - numero - solde rôle + crediter() + débiter() Entreprise Particulier- numeroSiret - prenom - /age - ageMajorite multiplicité •1 Nombre d’instances d’une •0..1 classe qui peuvent être •0..* ou * mises en relation avec une seule instance de la classe •1..* associée •1..4, 8PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 39
    40. 40. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 40
    41. 41. Diagramme de séquence Objectifs  A quoi cela sert ? Pour quoi faire ?  Identifier les traitements (quoi faire)  Identifier l’appelant et l’appelé de chaque traitement (qui appelle qui)  Objectifs  Permet de décrire une interaction entre des objets  Objets = acteurs, système, instance de classe  Les objets s’envoient des messages afin de réaliser une tâche déterminée  Met en avant l’enchaînement chronologique des messages Objet 1 Objet 2 Objet 3 Objet 4 Acteur 1 Diagramme de séquencePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 41
    42. 42. Diagramme de séquence Object1 : Actor1 Object2 Object3 Object4Axe du temps 1 : message1 Objet 2 : message2 3 : message3 Message 4 : message4 Retour Note permettant de commenter des séquences optionnelles 5 : destroy « self » Message Sil le faut 6 : message5 ( param1 ) Objet détruit Ligne de vie PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 42
    43. 43. Diagramme de séquence Exemple: « achat d’un livre »unClient : Client LeStock : Stock livre : Livre unArticle : Article monPanier : Panier manager : StockManager 1 : create 2 : DonneListeLivre 3 : ChoixLivre ( livre ) 4 : EnleveLivre (livre ) 5 : create 6 : Associe ( livre ) 7 : DemandePrixUnitaire 8 : Ajoute ( article ) 9 : CalculSolde PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 43
    44. 44. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activités  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 44
    45. 45. Diagramme d’activités Objectifs  A quoi cela sert-il ? Pour quoi faire ?  Décrit le comportement interne d’une opération  Donne une vision procédurale d’activités  Utiliser pour décrire:  un algorithme  une règle de gestion  la vision synthétique des scénarios d’un cas d’utilisationPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 45
    46. 46. Début du « workflow » Diagramme d’activités Représentation UML Rôle 2 Rôle 1 Rôle 3 Possibilité de« Swimlane » Activité 1 Une activité décomposer des activitésPermet de préciser les responsablesdes activités Activité 2 « Fork » Activité 3 Activité 3bis « Join » Condition Décision [ Résultat OK] Activité 4 Dossier X Objet résultat de l’activité ou modifié par l’activité Fin du « workflow» PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 46
    47. 47. Diagramme d’activités Exemple: « Achat d’un café dans un distributeur » Début du « workflow » Choisir une boisson Mettre le café dans le Remplir le réservoir Prendre une tasseUne activité filtre deau Mettre le filtre dans la machine Mettre la machine en marche Mélanger le café Verser café Fin du « workflow» PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 47
    48. 48. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités d’analyse et de conception avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 48
    49. 49. Packages  A quoi cela sert-il ? Pour quoi faire ?  Organiser la modélisation  Faciliter la maintenance et les évolutions  Faciliter l’analyse d’impact  Faciliter le travail en équipe  Objectifs  Permettre d’organiser les éléments d’un modèle en les regroupant (Similaire au classement de fichiers dans des répertoires sur un disque)  Découper la problématique du système à réaliser en grands « domaines »PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 49
    50. 50. Packages – Règles de construction  Chaque package doit posséder des critères d’appartenance précis et non ambigus (critères fonctionnels souvent retenus)  Un élément de modélisation appartient à un et un seul package Le nom complet d’un élément d’un modèle est nomPackage::nomElement  Un package peut contenir d’autres packagesPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 50
    51. 51. Packages Package « Client » contenant les éléments de modélisation UML relatifs au concept Client. clientDépendance inter-packages contrat compte Préférer des packages faiblement couplés et fortement cohérentsPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 51
    52. 52. Packages  Un « bon » découpage d’un modèle en package permet de mieux  Planifier le travail  Organiser la modélisation (l ’architecture !)  Faire de l’analyse d’impact  Isoler des anomalies  Faciliter la maintenance et les évolutionsPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 52
    53. 53. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 53
    54. 54. Diagramme états-transitions  Un diagramme d’états-transitions est une représentation du cycle de vie d’un objet Etat 4 Etat 5 entry/ action exit/ action Etat 3 entry/ action do/ activity Diagramme d’états Etat 1 Etat 6PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 54
    55. 55. Diagramme états-transitions  Il permet de spécifier entre autres :  Les différents états de la vie d’un objet  Etat = une période durant la vie d’un objet caractérisée par : – Valeur des différents attributs – Attente par l’objet d’un certain nombre d’événements – Réalisation éventuelle d’une activité  Les événements pouvant être reçus dans chaque état  Ils matérialisent le flot d’informations échangé  Les transitions d’état à état autoriséesPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 55
    56. 56. Diagramme d’états: exemple Diagramme d’états de la classe Cours Début du cycle de vie Etat Ouvert aux inscriptions Initialisé ouverture aux inscriptions / Proposer cours sur le site entry/ Initialiser com pteur entry/ Initialiser cours event dem ande dinscription/ Inscrire ; incrémenter compteur annulation du cours [ Com pteur = Max ou Date lim ite atteinte ] annulation du cours Activité Fermé aux inscriptions Annulé entry/ Cloturer les inscriptions entry/ Avertir étudiants inscrits annulation du cours do/ Finalis er coursEtat final Transition PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 56
    57. 57. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 57
    58. 58. Diagramme de composants  A quoi cela sert-il ? Pour quoi faire ?  Décrire les éléments physiques dans l’environnement de réalisation  Montrer les choix de réalisation  Un composant UML peut être :  Programme (Cobol, C++, C, Java, EAR, WAR…)  Librairie (DLL, JAR, EJB-JAR, Assembly…)  Fichier (.h, .cpp, .cbl, .java, jcl…) Diagramme de composants Composant 1 Composant 2 Composant 3PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 58
    59. 59. Diagramme de composants Composant de type Pr og. Cobol 1 programme COBOL Dépendance entre composants Pr og. Cobol 2Composant de « hautniveau » (Ex: ejb-jar dans lemonde J2EE) Big Jav a Component Interface du composant I nt er f ace du composant «reside» «reside» Fichier contenant la Composant 1 Composant 2 définition d’une classe en Java PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 59
    60. 60. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 60
    61. 61. Diagramme de déploiement  A quoi cela sert-il ? Pour quoi faire ?  Décrire l’infrastructure d’accueil d’un système (architecture physique)  Nœuds et liaisons entre les nœuds (type de lien, protocoles)  Répartir les différents composants sur les noeuds Diagramme de déploiement Noeud 1 « base de données » BD 1 Composant 1 Noeud 2 Composant 2PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 61
    62. 62. Diagramme de déploiement Exemple DMZ1 DMZ2 iiop : 1402 http : 80 Serveur Mainframe Serveur Web Firewall ApplicationFirewall DMZ2 WAS5.1 DMZ1 Apache iiop : 1402 sqlnet Serveur Serveur DB2 Oracle YYY XXX PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 62
    63. 63. Plan du cours  Objectifs de la formation  Introduction  Les cas d’utilisation  Concepts Objet  Le cœur d’UML  Diagramme de classe  Diagramme de séquence  Diagramme d’activité  Les packages  Diagramme états – transitions  Diagramme de composants  Diagramme de déploiement  Les activités de la méthode avec UMLPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 63
    64. 64. Les activités de la méthode avec UML  UML est un langage et non une méthode  UML n’impose donc pas un usage particulier des différents éléments présentés précédemment  C’est la méthode qui définit comment seront utilisés les différents éléments UML au cours du cycle de vie d’un projet  Définition des différents niveaux de détail des différents modèles produits (on parle de niveaux d’abstractions)  Définition des différents éléments d’UML à utiliser à chaque étape du cycle de vie projetPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 64
    65. 65. Les activités de la méthode avec UML  La plupart des méthodes s’appuyant sur le formalisme UML définissent 3 niveaux d’abstraction  Niveau « Exigences »  Niveau « Analyse »  Niveau « Conception »  Ces niveaux permettent une expression graduelle des exigences  En partant d’une expression proche de l’utilisateur  Pour aller vers une expression proche du codePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 65
    66. 66. Les activités de la méthode avec UML Modèle fonctionnel Modèle d’analyseLa modélisation devient de plus en Modèle de conceptionplus précise et proche du code final Code PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 66
    67. 67. Les activités de la méthode avec UML  Niveau fonctionnel « Exigences »  Utilisation des cas d’utilisation et diagrammes de cas d’utilisation Détermination du besoin  Niveau « Analyse »  Modélisation des concepts « métier »  Classes représentant uniquement des concepts manipulés par le métier  Pas d’introduction de classes « techniques » ou d’éléments provenant du langage d’implémentation Détermination de la solution fonctionnelle  Niveau « Conception »  Modèle faisant intervenir l’architecture technique en vigueur sur le projet  Utilisation de « modèles de conception » type (Design Patterns) Détermination de la solution techniquePRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 67
    68. 68. Les activités de la méthode avec UML  PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 68
    69. 69. Les activités de la méthode avec UMLModélisationmétierDécouverte duprocessus métierExigences NewActivityDéfinition desexigences utilisateur ... NewActivity2 NewActivity3 NewActivity4 Décision NewActivity6 NewActivity5 NewActivity7vis-à-vis du système Cas d’utilisation 1 Cas d’utilisation n Diagramme d’activitésAnalyse - banque Banque Object1 : Actor1 1 : message1 Object2 Object3 Object4 Etat_1 [condition]/action Etat_2Modélisation de la create 2 : message2 possède evenement «Destroy» 3 : message3 * - client Compt e 4 : message4 Do/activité + numerosolution fonctionnelle Client 1 - compte + nom + crediter ( ) - titulaire appartient à 1..* + debiter ( ) 5 : destroy + adresse + / age + solde ( ) Sil le faut 6 : message5 ( param1) + ageMajorite Diagramme d’états-transition Diagramme de classes Diagramme de séquenceConception - banque Banque Etat_1 [condition]/action Etat_2 NewActivity create Do/activité evenement «Destroy» Modélisation de la * Client possède - client Compt e + numero NewActivity2 NewActivity4 Décision NewActivity5solution technique + nom + adresse 1 - titulaire appartient à - compte + crediter ( ) 1..* + debiter ( ) NewActivity3 NewActivity6 NewActivity7 + /age + solde ( ) Diagramme d’états-transitions + ageMajorite Object1 : Actor1 Object2 Object3 Object4 Diagramme d’activités MLD + MPD Diagramme de classes 1 : message1 2 : message2 3 : message3 4 : message4 5 : destroy Diagramme de composants + diagramme de déploiement Sil le faut 6 : message5 ( param1 ) Diagramme de séquences PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 69
    70. 70. Les activités de la méthode avec UML Les modèles Modélisation  Chaîne de Processus - Recherche des activités métier qui définissent un processus métier Modèle de Evènementiel processus métier - Organisation de ces activités dans un flux métier - Découverte des exigences fonctionnelles et non fonctionnelles Exigences  Diagramme de contexte Modèle de Diagramme de cas d’utilisation - Élaboration en collaboration avec la MOA de la cinématique des cas cas d’ d’utilisation du système utilisation Diagramme d’activités -Description des activités d’une exigence Analyse  Diagramme de classes - Recherche des concepts métiers, de leurs propriétés et des relations structurelles qui les lient -> modélisation de l’aspect statique du cas d’utilisation  Diagramme de séquence - Recherche des messages échangés entre objets (flux Modèle d’événements) -> modélisation de la dynamique du cas d’utilisation d’analyse  Diagramme d’états transition -Recherche des différents états possibles d’un objet ->  Diagramme d’activités modélisation du cycle de vie -Description détaillée d’une exigenceConception  Diagramme de classes Modèle de  Diagramme de séquence conception - Prise en compte des contraintes techniques et des exigences non fonctionnelles sur le modèle d’analyse  Diagramme d’états transition  Diagramme d’activités Diagramme de composants - Organisation des composants  Diagramme de déploiement -Détermination du schéma de BD Modèle Logique de Données et Modèle Physique de Données PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 70
    71. 71. Les activités de la méthode avec UML  Discipline Exigences Diagramme de Diagramme Dossier des Fiche de Fiche cas d’utilisation d’activités exigences cas d’utilisation Exigence  Discipline Analyse & Conception Dossierd’architecture Dossier Diagramme de Diagramme de Diagramme d’analyse classes séquence d’états transitions Dossier Diagramme de Diagramme de de conception composants déploiement PRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 71
    72. 72. FIN 72
    73. 73. Maîtrise Documentaire Informations sur le document Nom Modèle utilisé PRHA-NOS-PR-0244 Modele de support cours T1.1.ppt Nom Harmonie PRHA-UML-FO-0719-Sensibilisation-UML-V1.ppt Revue du présent document Validation du présent document Nom Fonction Date Nom Fonction DateFormateurs harmonie Comité de lecture Dominique Marichal Directeur de mission 2/11/05Formateurs harmonie Formation des formateurs 31/05/05 Thierry Meyer SEPG Manager 08/02/06 Versions Version Date Responsable Nature des modifications V 91 2/11/05 PLU Création V91 T1 07/02/06 TDE Rectification Diag Etat classe Cours p 56 V1 08/02/06 APH DiffusionPRHA-UML-FO-0719-Sensibilisation-UML 08/02/2006 73

    ×