CoursUML-SlimMesfar-Total

1 794 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 794
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
119
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

CoursUML-SlimMesfar-Total

  1. 1. 1 Conception des Systèmes d’Information Langage de modélisation UML Unified Modeling Language Dr. Slim Mesfar Mail : mesfarslim@yahoo.fr
  2. 2. Ch1 : Introduction  Notion de système d’information  Présentation de UML2  Présentation des différentes étapes de développement logiciel Chapitre 2 : Analyse fonctionnelle  Diag de contexte statique  Diag de CU avec description textuelle des CU Chapitre 3 : Analyse dynamique  Diag de contexte dynamique  Diag de séquence système  Diag d'activités (modélisation processus métier et CU) Chapitre 4 : Analyse statique  Diag de classes d’analyse (+ contraintes, stéréotypes)  Diag d’objets  Diag de package Chapitre 5 : Conception  Diag de séquence objet (stéréotypes de Jacobson)  Diag de classes de conception (navigabilité, traduction de l’analyse)  Diag de communication / de collaboration  Diag état transition  Diag de composants  Diag de déploiement Chapitre 6 : Implémentation  Génération à partir d’un diagramme de classe : - D’une base de données - Code source JAVA/C++… 2 Plan du cours
  3. 3. 3 Les systèmes d’information • Des exemples de SI – Une application de gestion de stocks d’un supermarché – Un site web de vente en ligne – Une bibliothèque numérique – Un portail avec intranet pour une école/ institut – ... Introduction générale
  4. 4. 4 Les systèmes d’information • Qu’est ce qu’un SI ? un SI est un ou plusieurs logiciels manipulant un ensemble d’informations structurées et cohérentes. Par exemple : l’intra d’une école supérieure : des cours, des élèves, des profs, des horaires, des projets, des groupes, des notes, etc. On peut les consulter, les créer, les modifier, les détruire. � Plus largement, aujourd’hui, tout logiciel peut être considéré comme un système d’information. Introduction générale
  5. 5. 5 Les systèmes d’information • Autrement dit : un SI est un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures… permettant d’acquérir, de traiter, de stocker des informations (sous formes de données, textes, images, sons, etc.) dans et entre des organisations. � Nécessité de collaboration entre les intervenants pour garantir la bonne conduite du processus de développement d’un SI � Nécessité d’un langage de communication unifié Introduction générale
  6. 6. 6 Sommaire • Historique • La Modélisation • Les Diagrammes UML Chapitre 1 : Introduction et historique d’UML
  7. 7. 7 Historique
  8. 8. 8 BOOCH • Pionnier de l’Orienté-Objet – Article en 1981: ‘ Object Oriented Development ’ – Au début, méthode pour le développement d’applications en Ada pour le ‘ Department of Defense ’ – Etendue au C++ • Distingue 2 niveaux: – Logique • Diagrammes de classes • Diagramme d’instances • Diagramme états/transitions – Physique • Diagrammes de modules (principe des packages) • Diagramme de processus Les Principales Méthodes Objet Grady Booch Historique
  9. 9. 9 OMT • Object Modeling Technique – Livre de James Rumbaugh (1991) • 3 axes – Statique : identifie les propriétés des objets et leurs liaisons avec les autres objets – Dynamique : définit le cycle de vie des objets : comportement des objets, les différents états par lesquels ils passent, et les événements déclanchant ces changements d’états – Fonctionnel : précise les fonctions réalisées par les objets par l’intermédiaire des méthodes. James Rumbaugh Les Principales Méthodes Objet Historique
  10. 10. 10 OOSE • Object Oriented Software Engineering – Souvent appelée Objectory • 5 modèles – Description des besoins – Analyse – Conception – Implantation – Test • 3 types d ’objets – entités – contrôles – interfaces • Notion de Cas d’Utilisation: Use Cases Ivar Jacobson Les Principales Méthodes Objet Historique
  11. 11. 11 Méthodes Objets • En 1994, plus de 50 méthodes OO – Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad- Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis, COMMA, HOOD, Ooram, DOORS... • Les notations graphiques sont toutes différentes • L’industrie a besoin de standards Les Principales Méthodes Objet Historique
  12. 12. 12 Naissance d’UML • 1993-1994: Booch’93, OMT-2 – Les 2 méthodes sont leaders sur le marché – Elles sont de plus en plus proches • Octobre 1994 – J. Rumbaugh (OMT) rejoint G. Booch – Annonce de l’unification des deux méthodes • Octobre 1995: Méthode Unifiée v0.8 • Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint à son tour J. Rumbaugh et G. Booch • Janvier 97 : Soumission à l’OMG de la version UML 1.0 – OMG: Object Management Group • Organisme à but non lucratif fondé en 1989 • Plus de 700 entreprises y adhèrent • Septembre 97 : UML 1.1 Historique
  13. 13. 13 Conclusion • UML: Prendre le meilleur de chacune des méthodes – OOSE (Jacobson): Use Cases – OMT (Rumbaugh): Analyse – Booch: Conception, Architecture • Depuis 1997, UML est dans le domaine public • A partir Juin 2004 : Version UML 2.x avec divers apports : – Plus de possibilités de représentation, de précision et de capacités de modélisation (ex : diagrammes de séquence totalement refondus) – Meilleur support de l’ingénierie des systèmes – Possibilité de définir et de raffiner les systèmes jusqu’aux couches logicielles – … � Plus proche des MDAs • Actuellement : Version UML 2.4.1 (depuis Aout 2011) La Convergence vers UML Historique
  14. 14. 14 La Modélisation
  15. 15. 15 UML ? • Est une notation, pas une méthode • Est un langage de modélisation objet • Convient à tous les langages objets – SmallTalk – C++ (Héritage multiple) – Java (Interface) Définition La Modélisation
  16. 16. 16 Un modèle permet de : – mieux comprendre le système à développer, – visualiser le système comme il est ou comme il devrait l'être, – valider le modèle vis à vis des clients, – spécifier les structures de données et le comportement du système, – fournir un guide pour la construction du système, – documenter le système et les décisions prises. La Modélisation A quoi sert la modélisation?
  17. 17. 17 Qu’apporte la modélisation objet? • plus grande indépendance du modèle par rapport aux fonctionnalités demandées • des fonctionnalités peuvent être rajoutées ou modifiées sans que le modèle objet change • plus proche du monde réel La Modélisation A quoi sert la modélisation?
  18. 18. 18 La Modélisation Objectifs d’UML •Représenter des systèmes entiers, •Créer un langage de modélisation utilisable à la fois par les humains et les machines, •Rechercher un langage commun qui est utilisable par toutes les méthodes et adapté à toutes les phases du développement Pourquoi UML?
  19. 19. 19 La Modélisation UML ? �UML n’est pas une méthode �UML est un langage de modélisation objet �UML est adopté par toutes les méthodes objet �UML est une norme dans le domaine public •visualiser •spécifier •construire •documenter •S.I des entreprises •Banques et les services financiers •Télécommunications •Transport •Défense et aérospatiale •Scientifique •Applications distribuées par le WEB Utilisé pour Utilisé dans
  20. 20. 20 Architecture 4+1 La Modélisation • Vue des cas d'utilisation : c'est la description du modèle « vue » par les acteurs du système. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI).
  21. 21. 21 Architecture 4+1 La Modélisation •Vue logique : c'est la définition du système vu de l'intérieur. Elle explique comment peuvent être satisfaits les besoins des acteurs (c'est le COMMENT). •Vue d'implémentation : cette vue définit les dépendances entre les modules. •Vue de comportement ou des processus : c'est la vue temporelle et technique, qui met en œuvre les notions de tâches concurrentes, stimuli, contrôle, synchronisation, etc. •Vue de déploiement : cette vue décrit la position géographique et l'architecture physique de chaque élément du système (c'est le OÙ).
  22. 22. 22 Axes de Modélisation avec UML Statiques DynamiquesFonctionnels Diagramme de Classes Diagramme d’Objets Diagramme de Composants Diagramme de Déploiement Diagramme de paquetages Diagramme de structure composite (UML 2.x) Diagramme de Use Case Diagramme de Séquence Diagramme de communication (UML 2.x) Diagramme global d’interaction (UML 2.x) Diagramme de temps (UML 2.x) Diagramme d'Etats-Transitions Diagramme d'activités Cycle de Développement La Modélisation
  23. 23. 23 Modélisation fonctionnelle La Modélisation • Diagramme des cas d'utilisation (use-cases) : il permet d'identifier les possibilités d'interaction entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités que doit fournir le système.
  24. 24. 24 Modélisation statique La Modélisation •Diagramme de classes : il représente les classes intervenant dans le système. •Diagramme d'objets : il sert à représenter les instances de classes (objets) utilisées dans le système. •Diagramme de composants : il permet de montrer les composants du système d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données...) •Diagramme de déploiement : il sert à représenter les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux.
  25. 25. 25 Modélisation statique La Modélisation •Diagramme des paquetages : un paquetage étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le modèle UML, le Diagramme de paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles de définitions. •Diagramme de structure composite (UML 2.x) : permet de décrire sous forme de boîte blanche les relations entre composants d'une classe.
  26. 26. 26 Modélisation dynamique La Modélisation •Diagramme de séquence : représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs. •Diagramme de communication (UML 2.x) : représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets. •Diagramme global d'interaction (UML 2.x) : permet de décrire les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences (variante du diagramme d'activités).
  27. 27. 27 Modélisation dynamique La Modélisation • Diagramme de temps (UML 2.x) : permet de décrire les variations d'une donnée au cours du temps. •Diagramme états-transitions : permet de décrire sous forme de machine à états finis le comportement du système ou de ses composants. • Diagramme d'activités : permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.
  28. 28. 28 Cycle de développement du logiciel
  29. 29. � Expression des besoins � Spécification � Analyse � Conception � Implémentation � Validation � Tests de vérification � Maintenance et évolution Les différentes étapes du développement logiciel
  30. 30. � L’ Expression des besoins - Interview de l’expert métier � La Spécification – Ce que le système doit être et comment il peut être utilisé. � L’Analyse – L’objectif est de déterminer les éléments intervenant dans le système à construire, ainsi que leur structure et leurs relations . Elle doit décrire chaque objet selon 3 axes :  Axe fonctionnel : savoir-faire de l’objet.  Axe statique : structure de l’objet.  Axe dynamique : cycle de vie de l’objet au cours de l’application (États et messages de l’objet). Ces descriptions ne tiennent pas compte de contraintes techniques (informatique).
  31. 31. � La Conception : Elle consiste à apporter des solutions techniques aux descriptions définies lors de l’analyse : • architecture technique • performances et optimisation • stratégie de programmation On y définit les structures et les algorithmes. Cette phase sera validée lors des tests. � L’implémentation C’est la réalisation de la programmation.
  32. 32. � La Validation Le développement d’une application doit être lié à un contrat ayant une forme d’un cahier des charges, où doivent se trouver tous les besoins de l’utilisateur. Ce cahier des charges doit être rédigé avec la collaboration de l’utilisateur et peut être par ailleurs complété par la suite. Tout au long de ces étapes, il doit y avoir des validations en collaboration également avec l’utilisateur. Une autre validation doit aussi être envisagée lors de l’achèvement du travail de développement, une fois que la qualité technique du système est démontrée. Elle permettra de garantir la logique et la complétude du système.
  33. 33. � Les tests de vérification Ils permettent de réaliser des contrôles pour la qualité technique du système. Il s’agit de relever les éventuels défauts de conception et de programmation (revue de code, tests des composants,...). Il faut instaurer ces tests tout au long du cycle de développement et non à la fin pour éviter des reprises conséquentes du travail (programmes de tests robustes ; Logiciels de tests).
  34. 34. � Maintenance et évolution Deux sortes de maintenances sont à considérer :  Une maintenance corrective, qui consiste à traiter les “buggs ”.  Une maintenance évolutive, qui permet au système d’intégrer de nouveaux besoins ou des changements technologiques.
  35. 35. Le développement d’un logiciel repose sur les activités suivantes : � Détermination des besoins (quel est le cahier des charges ?) � Analyse (que fera le logiciel ?) � Conception (comment le fera-t-il ?) � Implémentation (quel code exécutera-t-il ?) � Test (sera-t-il conforme à l’analyse et au cahier des charges ?) Une organisation de ces activités forme un processus de développement. Résumé des différentes étapes du développement logiciel
  36. 36. 36 Chap 2 : Analyse fonctionnelle
  37. 37. 37 Analyse fonctionnelle Permet d’élaborer le cahier des charges ou le document de spécification des besoins du logiciel � permet de structurer les besoins des utilisateurs, les objectifs correspondants d'un système � On recense, l'ensemble des fonctionnalités d'un système en examinant les besoins fonctionnels de chaque acteur.
  38. 38. 38 Détermination des besoins Besoins (« requirement ») = exigence de ce que le système devrait satisfaire � Détermination des besoins attendus par chaque acteur : � le QUI ? � le QUOI ? Analyse fonctionnelle
  39. 39. 39 Détermination des besoins • Besoins fonctionnels – À quoi sert le système – Ce que doit faire le système, les fonctions utiles – Description des données manipulées • Besoins non fonctionnels : des restrictions ou des contraintes qui pèsent sur un service du système – description des contraintes, – Pour chaque fonction et pour le système global, il est possible d’exprimer différents types de contraintes. Exemple : portabilité, compatibilité, fiabilité, sécurité, … Les différents types de besoins
  40. 40. 40 Analyse fonctionnelle Méthodologie : 1. Identifier les acteurs, a. humains ou systèmes connexes b. principaux ou secondaires 2. Etablir le diagramme de contexte statique 3. Identifier les cas d'utilisation (UC) 4. Description des UC a. graphiquement b. textuellement
  41. 41. 41 2.1. Les diagrammes de contexte statique
  42. 42. 42 Le diagramme de contexte statique • Le diagramme de contexte statique permet de positionner le système dans son environnement selon un point de vue matériel. • Le système est donc décrit physiquement est non pas en termes de fonctionnalités • De plus, pour chaque type d’élément matériel extérieur au système, il est précisé le nombre minimal et maximal, appelés cardinalités, qui sont mis en jeu
  43. 43. 43 2.2. Les diagrammes de cas d’utilisation
  44. 44. • Le diagramme de cas d’utilisation décrit les fonctionnalités d’un système d’un point de vue utilisateur, sous la forme d’actions et de réactions ; l’ensemble des fonctionnalités est déterminé en examinant les besoins fonctionnels de tous les utilisateurs potentiels. • Le but est d’identifier : – les catégories d’utilisateurs : chacune d’entre elles, appelée acteur, est susceptible de mettre en oeuvre une ou plusieurs fonctionnalités du système ; – les besoins du système : chaque fonctionnalité, appelée cas d’utilisation, doit répondre à l’un des besoins nécessités par une ou plusieurs catégories d’utilisateurs. 44 Le diagramme des cas d’utilisation (Use cases)
  45. 45. • Le diagramme des cas d’utilisation se base sur le cahier des charges pour être construit ; il fait donc partie, en termes de gestion de projet, de la spécification du système. • Processus de construction du diagramme de cas d’utilisation 45 Le diagramme des cas d’utilisation (Use cases)
  46. 46. 46 Le diagramme des cas d’utilisation (Use cases) Les diagrammes UML
  47. 47. 47 1. Acteur : entité (humain ou machine) externe qui agit sur le système (opérateur, composant interne…) : Le diagramme des cas d’utilisation (Use cases) Identification des acteurs •permettant d’en déterminer les limites •jouant un rôle par rapport à lui •déclenchant un stimulus initial entraînant une réaction du système •Un acteur est décrit précisément en quelques lignes :
  48. 48. 48 1. Acteur Le diagramme des cas d’utilisation (Use cases) Identification des acteurs 4 catégories d’acteurs : •acteurs principaux : personnes utilisant les fonctions principales du système. Dans le cas d'un distributeur de billets, il s'agit des clients. •acteurs secondaires : personnes qui effectuent des tâches administratives ou de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la personne qui recharge la caisse du distributeur. •matériel externe : dispositifs matériels autres que les ordinateurs comme les périphériques. Dans le cas d'un distributeur de billets, il s'agit de l'imprimante, du lecteur de carte, de la trieuse de billets. •autres systèmes : les systèmes avec lesquels le système interagit. Dans le cas d'un distributeur de billets, il s'agit du groupement bancaire qui gère l'ordinateur central qui relie tous les distributeurs.
  49. 49. 49 Le diagramme des cas d’utilisation (Use cases) La Modélisation des besoins en UML 2. Use case : ensemble d’actions réalisées par le système, en réponse à une action d’un acteur. L’ensemble des uses cases décrit les objectifs (le but) du système. Exemple. identification, retrait de liquide. • Scénarios d’un CU Séquence particulière de messages dans le CU pendant une interaction particulière (“chemin” dans le cas d’utilisation),
  50. 50. 50 Description détaillée de chaque cas d’utilisation � Chaque cas d ’utilisation doit être décrit en détail � Commencer par les CU prioritaires � Description utile pour la suite du développement � Description détaillée plus ou moins formelle � langue naturelle mais structurée, � vocabulaire précis, � ... Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML
  51. 51. 51 Informations à décrire � Quand le CU commence, pré-conditions � Quand le CU se termine, post-conditions � Le chemin correspondant au déroulement normal � Les variantes possibles et les cas d’erreurs (les points d’extensions) � Les interactions entre le système et les acteurs � Les informations échangées � Les éventuels besoins non fonctionnels Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML
  52. 52. 52 Exemple de description détaillée d’un CU Précondition : Le distributeur contient des billets, il est en attente d ’une opération, il n’est ni en panne, ni en maintenance Début : lorsqu’un client introduit sa carte bancaire dans le distributeur. Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Si de l ’argent a pu être retiré, la somme d’argent sur le compte est égale à la somme d’argent qu’il y avait avant, moins le montant du retrait. Sinon la somme d ’argent sur le compte est la même qu’avant. Retirer de l’Argent Retirer de l’Argent Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML
  53. 53. 53 Retirer de l’Argent Scénario nominal : (1) le client introduit sa carte bancaire (2) le système lit la carte et vérifie si la carte est valide (3) le système demande au client de taper son code (4) le client tape son code confidentiel (5) le système vérifie que le code correspond à la carte (6) le client choisi une opération de retrait (7) le système demande le montant à retirer … Variantes : (A) Carte invalide : au cours de l ’étape (2) si la carte est jugée invalide, le système affiche un message d ’erreur, rejète la carte et le cas d ’utilisation se termine. (B) Code erroné : au cours de l ’étape (5) ... Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML Exemple de description détaillée d’un CU
  54. 54. 54 Contraintes non fonctionnelles : (A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l’action de l ’utilisateur. (B) Résistance aux pannes : si une coupure de courant ou une autre défaillance survient au cours du cas d ’utilisation, la transaction sera annulée, l ’argent ne sera pas distribué. Le système doit pouvoir redémarrer automatiquement dans un état cohérent et sans intervention humaine. (C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits d ’argent simultanément ... Retirer de l’Argent Retirer de l’Argent Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML Exemple de description détaillée d’un CU
  55. 55. 55 Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML •Relations entre les cas d’utilisation -« utilise» ou « include »: définit le fait qu’un use case contient le comportement défini dans un autre use case. Cas d'utilisation B << Utilise >> Cas d'utilisation A -« étend » ou « extend »: définit le fait qu’une instance d’un use case peut être augmentée avec un comportement quelconque défini dans un use case étendu Cas d'utilisation A Cas d'utilisation B << Etend >> - « généralisation » Un cas A est une généralisation d’un cas B si B est un cas particulier de A.
  56. 56. 56 Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML •Relations entre les cas d’utilisation
  57. 57. 57 Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML •Relation d’héritage entre les acteurs secrétaire médecin Consulter fiche patient Remplir fiche consultation créer fiche patient
  58. 58. Erreurs usuelles - rôles 58 Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML
  59. 59. Erreurs usuelles - factorisation 59 Le diagramme des cas d’utilisation (Use case) La Modélisation des besoins en UML Gérer client
  60. 60. 60 Chap 3 : Analyse dynamique
  61. 61. 61 3.1. Les diagrammes de contexte dynamique
  62. 62. 62 Le diagramme de contexte dynamique • Le diagramme de contexte dynamique permet de positionner le système dans son environnement selon le point de vue des communications. • Il reprend les éléments du contexte statique et précise les échanges d’informations qui sont réalisés entre le système et les éléments matériels extérieurs au système. • Le système est donc décrit physiquement et logiquement.
  63. 63. 63 3.2. Les diagrammes de séquence système
  64. 64. 64 Le diagramme de séquence Les diagrammes UML Deux différents types de diagrammes de séquence : • Diagramme de séquence système au niveau de l’analyse dynamique �représentation des différents scénarios des cas d’utilisation � interaction entre les acteurs et le système (une boite noire) selon un ordre chronologique •Diagramme de séquence détaillé au niveau de la conception � représentation des collaborations entre des objets pour la réalisation d’un cas d’utilisation, selon un point de vue temporel. � représentation de la chronologie des envois de messages entre les objets. S. Mesfar
  65. 65. 65 Le diagramme de séquence Les diagrammes UML Du diagramme de séquence système à la conception S. Mesfar
  66. 66. 66 Le diagramme de séquence Les diagrammes UML • Il y a autant de diagrammes de séquence qu’il y a de scénarios • Un Scénario montre une séquence particulière d’interactions entre objets, dans un seul contexte d’exécution du système • Un scénario peut être vu comme une réponse à un besoin ou une partie d’un besoin du diagramme des Uses Cases. • On y fait intervenir des objets / système complet, des messages et des événements Représentation de Scénarios objet1 : Classe objet2 : Classe Objets de type Classe S. Mesfar
  67. 67. 67 Le diagramme de séquence Les diagrammes UML �l'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe : La ligne de vie. La disposition des objets sur l'axe horizontal n'a pas de conséquence particulière sur la sémantique du diagramme. S. Mesfar
  68. 68. Numérotation des messages • Les messages peuvent être numérotés séquentiellement A B 1: Message A B 1: Message 1 C 1.1: message 2 Le diagramme de séquence Les diagrammes UML S. Mesfar 68
  69. 69. Durée d’activation(période d’activation) – correspond au temps pendant lequel un objet effectue une action – est représentée par une bande rectangulaire : • Le long de la ligne de vie de l’objet • Dont les extrémités représentent le début et la fin de l’activité. Un objet Durée d’activation Objet 1 Objet 2 Remarque : souvent quand l’objet est en activité continue, on néglige la représentation de cette période d’activation Le diagramme de séquence Les diagrammes UML S. Mesfar 69
  70. 70. 70 Le diagramme de séquence Les diagrammes UML Notation Graphique Objet S. Mesfar Appelant: Ligne téléphonique: Appelé: décroche() tonalité numérotation() indication sonnerie indication sonnerie() décroche
  71. 71. Transmission de données • Les messages peuvent véhiculer des données entre les acteurs et le système ou entre les objets A B 1: Message (donnee1, donnee2) Le diagramme de séquence Les diagrammes UML S. Mesfar 71
  72. 72. 72 Le diagramme de séquence Les diagrammes UML Représentation graphique Système comme une boite noire S. Mesfar
  73. 73. 73 Le diagramme de séquence Les diagrammes UML •Spécificités des diagrammes de séquences �un objet peut s’envoyer un message, Un objet: Message réflexif S. Mesfar
  74. 74. 74 Le diagramme de séquence Les diagrammes UML Représentation graphique enrichie S. Mesfar
  75. 75. 75 Le diagramme de séquence Les diagrammes UML •Spécificités des diagrammes de séquences �un message peut entraîner la création ou la destruction d’autres objets, Créer Détruire Un objet: Un autre objet: S. Mesfar
  76. 76. Les types de messages Dans un diagramme de séquences trois principaux types de messages sont distingués : •message synchrone (flèche avec une extrémité pleine) Bloque l’émetteur jusqu'à prise en compte du message par le destinataire. Le flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le récepteur actif) à la prise en compte du message. •message asynchrone (flèche avec une extrémité non pleine) N'interrompt pas l'exécution de l’émetteur. Le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré (jamais traité). Le diagramme de séquence Les diagrammes UML S. Mesfar 76
  77. 77. Les réponses aux messages Dans le cas des envois synchrones, le retour peut être implicite en fin d'activités et ne nécessitera pas de représentation particulière Dans le cas des envois asynchrones, le retour doit être explicite Le diagramme de séquence Les diagrammes UML S. Mesfar 77
  78. 78. Les types de messages Sd diagramme1 Objet1: Objet2: Objet3::client Message 1( ) Message 2( ) Message 3( ) Message 5( ) Message 6( ) Retour Message 3( ) Message synchrone Message asynchrone Message 4( ) Activation d’un objet Le diagramme de séquence Les diagrammes UML S. Mesfar 78
  79. 79. Exemple Le diagramme de séquence Les diagrammes UML S. Mesfar 79
  80. 80. Comité de programme Comité d'organisation PAPIERAuteur RAPPORTLecteur Appel( ) Enregistrer le papier Papier enregistré Affecter_lecteur( ) Note( ) Rédiger( ) Envoi Enreg_papier(true) Evalué( ) Papier évalué Exemple2 Le diagramme de séquence Les diagrammes UML S. Mesfar 80
  81. 81. Exemple3 Le diagramme de séquence Les diagrammes UML S. Mesfar 81
  82. 82. Autres types de messages Dans un diagramme de séquence, il peut y avoir d’autres types de messages tels que: Le diagramme de séquence Les diagrammes UML •message minuté (timeout) : Bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans une contrainte), en attendant la prise en compte du message par le récepteur. L'expéditeur est libéré si la prise en compte n'a pas eu lieu pendant le délai spécifié. • message dérobant : Le message est mis en attente dans une liste d'attente de traitement chez le récepteur. S. Mesfar 82
  83. 83. S. Mesfar 83 Le diagramme de séquence Les diagrammes UML Pseudo-code L’ajout de pseudo-code sur la partie gauche du diagramme permet la représentation des boucles et des branchements alternatifs � les diagrammes de séquence peuvent représenter la forme générale d’une interaction , au-delà de la seule prise en compte d’un scénario particulier �
  84. 84. S. Mesfar 84 Le diagramme de séquence Les diagrammes UML Pseudo-code �
  85. 85. Diagramme de séquences : Fragment d’interaction ou fragments combinés Un fragment d’interaction se représente globalement comme un diagramme de séquence dans un rectangle avec indication dans le coin à gauche du nom du fragment. Un port d’entrée et un port de sortie peuvent être indiqués pour connaître la manière dont ce fragment peut être relié au reste du diagramme. Dans le cas où aucun port n’est indiqué c’est l’ensemble du fragment qui est appelé pour exécution Le diagramme de séquence Les diagrammes UML S. Mesfar 85
  86. 86. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 86
  87. 87. Un fragment d’interaction dit combiné correspond à un ensemble d’interactions auquel on applique un opérateur. Un frag combiné se représente globalement comme un diagramme de séquence avec indication dans le coin à gauche du nom de l’opérateur. 13 opérateurs ont été définis dans UML : alt, opt, loop, par, strict/weak, break, ignore/consider, critical, negative, assertion et ref. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 87
  88. 88. L’opérateur alt : correspond à une instruction de test avec une ou plusieurs alternatives possibles. Il est aussi permis d’utiliser les clauses de type sinon. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 88
  89. 89. L’opérateur opt : L’opérateur opt (optional) correspond à une instruction de test sans alternative (sinon). Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 89
  90. 90. L’opérateur loop correspond à une instruction de boucle qui permet d’exécuter une séquence d’interaction tant qu’une condition est satisfaite. Il est possible aussi d’utiliser une condition portant sur un nombre minimum et maximum d’exécution de la boucle en écrivant : loop min, max. Dans ce cas, la boucle s’exécutera au minimum min fois et au maximum max fois Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 90
  91. 91. L’opérateur par L’opérateur par (parallèle) permet de représenter deux séries d’interactions qui se déroulent en parallèle. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 91
  92. 92. Les opérateurs strict et weak sequencing Les opérateurs strict et weak permettent de représenter une série d’interactions dont certaines s’opèrent sur des objets indépendants : � L’opérateur strict est utilisé quand l’ordre d’exécution des opérations doit être strictement respecté. � L’opérateur weak est utilisé quand l’ordre d’exécution des opérations n’a pas d’importance. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 92
  93. 93. Les opérateurs strict et weak sequencing Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 93
  94. 94. Les opérateurs break L’opérateur break permet de représenter une situation exceptionnelle correspondante à un scénario de rupture par rapport au scénario général. Le scénario de rupture s’exécute si la condition de garde est satisfaite. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 94
  95. 95. Les opérateurs ignore et consider Les opérateurs ignore et consider sont utilisés pour des fragments d’interactions dans lesquels on veut montrer que certains messages peuvent être soit absents sans avoir d’incidence sur le déroulement des interactions (ignore), soit obligatoirement présents (consider). Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 95
  96. 96. Les opérateurs ignore et consider Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 96
  97. 97. Les opérateurs critical L’opérateur critical permet d’indiquer qu’une séquence d’interactions ne peut être interrompue compte tenu du caractère critique des opérations traitées. On considère que le traitement des interactions comprises dans la séquence critique est atomique. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 97
  98. 98. L’opérateur critical Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 98
  99. 99. Les opérateurs neg L’opérateur neg (negative) permet d’indiquer qu’une séquence d’interactions est invalide. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 99
  100. 100. Les opérateurs assert L’opérateur assert (assertion) permet d’indiquer qu’une séquence d’interactions est l’unique séquence possible en considérant les messages échangés dans le fragment. Toute autre configuration de message est invalide. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 100
  101. 101. Les opérateurs ref L’opérateur ref permet d’appeler une séquence d’interactions décrite par ailleurs constituant ainsi une sorte de sous-diagramme de séquence. Fragment d’interaction Le diagramme de séquence Les diagrammes UML S. Mesfar 101
  102. 102. 102 3.3. Les diagrammes d'activités
  103. 103. Digramme d'activités UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états- transitions). • Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. • Le passage d'une activité vers une autre est matérialisé par une transition. • Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont automatiques). Le diagramme d'activités Les diagrammes UML
  104. 104. Digramme d'activités En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls les mécanismes complexes ou intéressants méritent d'être représentés. • Buts : 1. Décrire le comportement générique d’un cas d’utilisation 2. Décrire en détail le comportement d’une opération 3. Modéliser les processus métiers Le diagramme d'activités Les diagrammes UML
  105. 105. Le diagramme d’activités est organisée par rapport aux actions et destinée à représenter le comportement interne d’une opération ou d’un cas d ’utilisation. Mesurer température Chauffer Refroidir AérerArrêter chauffage [trop froid] [trop chaud] « synchronisation » Le diagramme d'activités Les diagrammes UML
  106. 106. • Exemple de Diagramme d'activités : Le diagramme d'activités Les diagrammes UML
  107. 107. Le but du diagramme d'activités • Diagramme d'activités est utilisé pour: – Modéliser un workflow dans un use case ou entre plusieurs use cases. – Spécifier une opération (décrire la logique d’une opération) • Le diagramme d'activités est le plus approprié pour modéliser la dynamique d’une tâche, d’un use case lorsque le diagramme de classe n’est pas encore stabilisé. Le diagramme d'activités Les diagrammes UML
  108. 108. Notion du diagramme d'activités Diagramme d'activités = • ensemble d'activités liés par: – Transition (sequentielle) – Transitions alternatives (conditionnelle) – Synchronisation (disjonction et conjonctions d'activités) – Itération • + 2 états: état de départ et état de terminaison • Swimlanes: représente le lieu, le responsable des activités. Le diagramme d'activités Les diagrammes UML
  109. 109. Notion du diagramme d'activités •Etat de départ •Etat de terminaison •Transition •Transition Alternative [ ] [ ] Le diagramme d'activités Les diagrammes UML
  110. 110. Notion du diagramme d'activités Synchronisation disjonctive et conjonctive Le diagramme d'activités Les diagrammes UML
  111. 111. Notion du diagramme d'activités Itération Le diagramme d'activités Les diagrammes UML
  112. 112. Exemple de Diagramme d'activités : Swimlanes / partitions Ou couloirs d’activités Le diagramme d'activités Les diagrammes UML
  113. 113. Le diagramme d'activités Les diagrammes UML Exemple de Diagramme d'activités :
  114. 114. Les nœuds de contrôle • Il existe plusieurs types de nœuds de contrôle: – nœud initial(initial node); – nœud de fin d'activités(final node); – nœud de décision(decision node); – nœud de fusion(merge node); – nœud de bifurcation(fork node); – nœud d’union(join node). Le diagramme d'activités Les diagrammes UML
  115. 115. Le diagramme d'activités Les diagrammes UML
  116. 116. diagramme d'activités • Partitions / swimlanes ou couloirs d’activités Le diagramme d'activités Les diagrammes UML
  117. 117. 117 Chap 4 : Analyse statique
  118. 118. 118 Analyse statique L’analyse statique permet de représenter l’ensemble des classes, d’interfaces et de paquetages ainsi que leurs relations. • Une classe décrit un ensemble d’objets (instances de la classe). • Une association décrit un ensemble de liens (instances de l’association).
  119. 119. 119 4.1. Les diagrammes de classes d’analyse
  120. 120. 120 Le diagramme de classes Les diagrammes UML Utilisation • Lors de l’analyse et de la conception: – Définitions formelles des objets qui composent le système à partir des cas d’utilisation et des diagrammes d’interaction (séquence ou collaboration). – Bases conceptuelles pour les diagrammes d’état-transition, de déploiement, ... • Lors de l’implémentation : – Génération automatique des structures statiques du système (classes, relations, ...).
  121. 121. 121 Le diagramme de classes Les diagrammes UML �Le plus important de la modélisation O.O. �Le seul obligatoire lors d’une telle modélisation � fournit une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation �Vue statique : les éléments principaux sont : les classes et leurs relations
  122. 122. 122 Le diagramme de classes Les diagrammes UML Notion de classe Définition : Une classe est une description d’un ensemble d’objets ayant une sémantique, des attributs, des méthodes et des relations en commun. Un objet est une instance d’une classe. Objet de type VoitureClasse
  123. 123. • Une classe est une description abstraite d’un ensemble d’objets ayant : – des propriétés similaires, – un comportement commun, – des relations communes avec d’autres objets – des sémantiques communes • Chaque classe possède : – une composante «statique» : attributs ou champs possédant une valeur – une composante «dynamique» : méthodes qui représentent le comportement commun des objets de la classe Liste des attributs Liste des méthodes Nom de la classe 123S. Mesfar Le diagramme de classes : Qu’est ce qu’une classe ? Les diagrammes UML
  124. 124. 124 Le diagramme de classes Les diagrammes UML Notion de classe Attribut = propriété nommée d ’une classe la portée standard d’un attribut est limité à un objet • Syntaxe – visibilité nom : type = valeur initiale • Visibilité – + public : propriété ou classe visible partout – # protégé : propriété ou classe visible dans la classe et par tous ses descendants – - privé : propriété ou classe visible uniquement dans la classe – ~ package : propriété ou classe visible uniquement dans le paquetage où la classe est définie • Attribut de classe – quand cette portée s’applique à la classe elle même, on parle d’attribut de classe (représenté par le symbole $ ou souligné) • Attribut dérivé – attribut qui peut être déduit d’un ou plusieurs autres attributs (représenté par le symbole /)
  125. 125. 125 Le diagramme de classes Les diagrammes UML Notion de classe Méthode = service que l’on peut demander à un objet pour réaliser un comportement • Syntaxe – visibilité nom (paramètres) : type retour • Mêmes notions que l’attribut – visibilité – méthode de classe
  126. 126. 126 Le diagramme de classes Les diagrammes UML Notion de classe Notation Complète Visibilité Static Dérivé Paramètre Retour Initialisation Nom de la Classe Fenetre + taille : Rectangle = 100,100 - visible : Boolean = true couleur : Color = blue #$ tailleMax : Rectangle #$ tailleMin : Rectangle /#$ tailleMoyenne : Rectangle + afficher() : Position + cacher() # setTaille(taille : Rectangle) } }Attributs Méthodes
  127. 127. • Un diagramme de classes représente la structure du système sous la forme de classes et de relations entre ces classes • Un diagramme d’objets illustre les objets et les liens qui les unissent 127S. Mesfar Le diagramme de classes et le diagramme d’objets Les diagrammes UML
  128. 128. Le concept d’encapsulation • L'encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d'une structure en cachant l'implémentation de l'objet c-à-d en empêchant l'accès aux données par un autre moyen que les méthodes proposés pour la manipulation de l’objet. � L'encapsulation permet donc de garantir l'intégrité des données contenues dans l'objet. • L'encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces niveaux de visibilité définissent les droits d'accès aux données selon que l'on y accède par une méthode de la classe elle-même, d'une classe héritière, ou bien d'une classe quelconque. S. Mesfar 128 Le diagramme de classes Les diagrammes UML
  129. 129. Le concept d’encapsulation – Quatre niveaux de protection : • Public (+) : accès à partir de toute entité interne ou externe à la classe • Protégé (#) : accès à partir de la classe ou des sous- classes • Privé (-) : accès à partir des opérations de la classe • Package (~ ou rien) : accès à partir des classes du même package 129S. Mesfar Le diagramme de classes Les diagrammes UML
  130. 130. S. Mesfar 130 Héritage • Héritage – Mécanisme de transmission des propriétés (attributs, comportement) d’une classe vers ses sous classes – Ce qui est générique est défini au niveau de la super-classe, ce qui est spécifique est défini au niveau de la sous-classes • Généralisation/spécialisation – Généralisation : mise en commun des propriétés communes entre différentes classes dans une super-classe. – Spécialisation : création d’une sous-classe par mise en avant de propriétés spécifiques non communes à toutes les classes de la super- classe Le diagramme de classes Les diagrammes UML
  131. 131. S. Mesfar 131 Héritage : exemple Généralisation Spécialisation personne étudiantpersonnel EnseignantAdministratif Le diagramme de classes Les diagrammes UML
  132. 132. Exemple d’héritage 132S. Mesfar Le diagramme de classes Les diagrammes UML
  133. 133. S. Mesfar 133 Héritage multiple � une classe peut hériter des propriétés de plusieurs super-classes personne étudiantpersonnel EnseignantAdministratif Doctorant Le diagramme de classes Les diagrammes UML
  134. 134. Exemple d’héritage multiple 134S. Mesfar Le diagramme de classes Les diagrammes UML
  135. 135. Contraintes de généralisation • Une classe peut être spécialisée selon plusieurs critères • Certaines contraintes peuvent être posées sur les relations de généralisation • Par défaut, la généralisation symbolise une décomposition exclusive 135S. Mesfar Le diagramme de classes Les diagrammes UML
  136. 136. Contraintes de généralisation {disjoint} ( = { exclusif } ) • La contrainte {Disjoint} (ou {exclusif}) indique la participation exclusive d’un objet à l’une des collections spécialisées 136S. Mesfar Le diagramme de classes Les diagrammes UML
  137. 137. Contraintes de généralisation {chevauchement} (={ inclusif }) • La contrainte {chevauchement} (ou {inclusif}) indique la participation possible d’un objet à plusieurs collections spécialisées 137S. Mesfar Le diagramme de classes Les diagrammes UML
  138. 138. Contraintes de généralisation {Complète} ≠ {Incomplète} • La contrainte {Complète} indique la généralisation est terminée : tout ajout de sous-classe est alors impossible • à l’inverse, la contrainte {Incomplète} indique une généralisation extensible 138S. Mesfar Le diagramme de classes Les diagrammes UML
  139. 139. Le polymorphisme • Alors que l'héritage concerne les classes (et leur hiérarchie), le polymorphisme est relatif aux méthodes des objets. • On distingue généralement trois types de polymorphisme : 1. Le polymorphisme ad hoc (également appelé surcharge) : permet de définir des opérateurs dont l'utilisation sera différente selon le type des paramètres qui leur sont passés � par exemple, il est possible de surcharger l'opérateur + et de lui faire réaliser des actions différentes selon qu'il s'agit d'une opération entre deux entiers (addition) ou entre deux chaînes de caractères (concaténation) 2. Le polymorphisme paramétrique (également appelé généricité) : représente la possibilité de définir plusieurs fonctions de même nom mais possédant des paramètres différents (en nombre et/ou en type) � Il rend ainsi possible le choix automatique de la bonne méthode à adopter en fonction du type de donnée passée en paramètre S. Mesfar 139 Le diagramme de classes Les diagrammes UML
  140. 140. Le polymorphisme 3. Le polymorphisme d'héritage (également appelé redéfinition) : représente la possibilité de redéfinir une méthode dans des classes héritant d'une classe de base. Il est alors possible d'appeler la méthode d'un objet sans se soucier de son type intrinsèque � faire abstraction des détails des classes spécialisées d'une famille d'objet, en les masquant par une interface commune (qui est la classe de base). – Par exemple, un jeu d'échec comporte plusieurs objets roi, reine, fou, cavalier, tour, pion, héritant chacun de l'objet pièce. La méthode mouvement() pourra, grâce au polymorphisme d'héritage, d’effectuer le mouvement approprié en fonction de la classe de l'objet référencé au moment de l'appel. Cela permettra notamment au programme d’appeler pièce.mouvement() sans avoir à se préoccuper de la classe de la pièce. S. Mesfar 140 Le diagramme de classes Les diagrammes UML
  141. 141. Exemple de polymorphisme d’héritage S. Mesfar 141 Le diagramme de classes Les diagrammes UML
  142. 142. • Une association représente une relation entre les classes d’objets Classe A Classe B Société Personne Voiture Personne Classe A 142S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  143. 143. • Une association qui contient des attributs et qui ne participe pas à des relations avec d’autres classe est appelée classe attribuée. Classe A Classe B Classe C Attributs 143S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  144. 144. • Une association ternaire entre salle, étudiant et enseignant est réifiée comme une classe cours ayant deux attributs : début et fin Enseignant Salle Classe Cours Début Fin 144S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  145. 145. • Généralement, on note les associations par une forme verbale, soit active, soit passive Classe A Classe B Société Personne Voiture Personne Forme verbale < travaille pour Est la proprièté de > 145 S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  146. 146. Nommage des rôles • Toute association binaire possède 2 rôles • un rôle définit la manière dont une classe intervient dans une relation • Le nommage des associations et le nommage des rôles ne sont pas exclusifs l’un de l’autre • Intérêt des rôles dans le cas où plusieurs associations lient deux classes : distinction des concepts attachés aux associations Société Personne< travaille pour employeur employé Avion PersonnePilote Passagers 146S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  147. 147. Association réflexive • Nommage des rôles indispensable à la clarté du diagramme Personne Enfants Parents 2 * 147S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  148. 148. Multiplicité des associations • La multiplicité est une information portée par le rôle, qui quantifie le nombre de fois où un objet participe à une instance de relation • Multiplicité = indique le nombre d’instances d’une classe qui peut être mise en relation avec une seul instance de la classe associée – 1 : obligatoire – 0..1 : optionnel – 0..* ou * : quelconque – 1..* : au moins 1 – 1..5, 10 : entre 1 et 5, ou 10 148S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  149. 149. Multiplicité des associations • 1 : Chaque personne travaille pour une et une seule société (toutes les personnes ont un emploi) • 0 .. * : Une société emploie de zéro à plusieurs personnes Société Personne< travaille pour employeur employé 1 0..* 149S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  150. 150. Contraintes sur les associations • Contrainte d’association : porte sur une relation ou sur un groupe de relations (notée {contrainte }) • Par exemple, placée sur un rôle, la contrainte {ordonnée} définit une relation d’ordre entre les objets de la collection (les comptes) qui sont liés à une personne Personne ComptePropriétaire {ordonnée}1 0..n 150S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  151. 151. Contraintes sur les associations • La contrainte {sous-ensemble} indique qu’une collection est incluse dans une autre collection • La contrainte {Ou-exclusif} précise que, pour un objet donné, une seule association parmi un groupe d’associations est valide Classe Personne Université Personne {Sous ensemble} Parents d’élève Délégués * * {OU-exclusif} Enseignants Étudiants * * 151 S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  152. 152. Restriction des associations • La restriction (dite qualification en UML) d’une association consiste à sélectionner un sous-ensemble d’objets parmi l’ensemble des objets qui participent à une association réalisée au moyen d’une clé, ensemble d’attributs particuliers. • Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique 152S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  153. 153. Association particulière : Agrégation • Une agrégation est une association non symétrique : l’une des extrémités joue un rôle prédominant par rapport à l’autre • Elle se justifie lorsque une classe B « fait partie » intégrante d’une classe A. • Exemple: 153S. Mesfar Livre MotChapitre 1..* 1..*1..* 1..* Le diagramme de classes : Les associations Les diagrammes UML
  154. 154. Agrégation particulière : Composition • La composition est une forme particulière d’agrégation • Le composant est « physiquement » contenu dans l’agrégat • La composition implique une contrainte sur la valeur de la multiplicité du coté de l’agrégat : (0 ou 1) 154S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  155. 155. Agrégation particulière : Composition • La composition peut être modélisée au moyen d’attributs • La notation par composition doit être retenue lorsque d’un attribut participe à des relations 155S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
  156. 156. 156 Composition Le diagramme de classes : Les associations Les diagrammes UML
  157. 157. 157 Le diagramme de classes : Les associations Les diagrammes UML Une Université contient au moins un département. Des départements peuvent avoir différents professeurs. Détruire une université détruit ses départements, mais en aucun cas ne met fin à la vie des professeurs. En C++ : class Professeur; class Departement { ... private: // Agrégation Professeur* enseignants[5]; . .. }; class Universite { ... private: // Composition Departement facultes[20]; ... };
  158. 158. 158 4.2. Les diagrammes d’objets
  159. 159. Un diagramme de d’objets : • Représente les liens structurels entre instances de classes • Facilite la compréhension de structures complexes • Trois représentations possibles des instances : 159S. Mesfar Le diagramme d’objets Les diagrammes UML
  160. 160. • les valeurs des attributs sont optionnelles ainsi que les liens entre objets 160S. Mesfar Le diagramme d’objets Les diagrammes UML
  161. 161. Diagramme d’objets : liens entre objets • Les liens des associations réflexives peuvent relier un objet à lui même 161S. Mesfar Le diagramme d’objets Les diagrammes UML
  162. 162. Diagramme d’objets : liens entre objets • Les liens d’arité supérieure à 2 ou la multiplicité peuvent être représentés : 162S. Mesfar Le diagramme d’objets Les diagrammes UML
  163. 163. Diagramme d’objets : liens entre objets • Les objets composés de sous-objets peuvent être visualisés : • Les objets composites sont instances de classes composites : 163S. Mesfar Le diagramme d’objets Les diagrammes UML
  164. 164. Diagramme d’objets : structures complexes • Les diagrammes d’objets facilitent la compréhension et l’élaboration d’un diagramme de classes : 164S. Mesfar Le diagramme d’objets Les diagrammes UML
  165. 165. 165 Chap 5 : La conception
  166. 166. Rappel des concepts de base • Classe – attribut – méthode • Association – rôle – cardinalité – Agrég./Comp./Associative/Qualifiée o1 o2 o1 o2 o3 o4 o5 o1 o2 o3  Objet  Lien  Inclusion ensembliste  Héritage M1 M0 La conception Les diagrammes UML
  167. 167. De quoi parle-t-on ? Analyse Objets du monde réel Objets du logiciel Algorithme du monde réel (scénario) Comment ‘logique’ ? Conception Objets du langage Algorithme du logiciel (scénario) Comment ‘physique’ ? Code Modèle conceptuel Modèle logique Modèle physique La conception Les diagrammes UML
  168. 168. • Deux niveaux de conception : – Logique : indépendante de l’environnement de réalisation. – Physique : liée à des particularités des langages de programmation ou de l’environnement d’exécution 168 La conception Les diagrammes UML
  169. 169. 169 � Un des principaux soucis de l’activité de conception est de développer un design qui facilite l’ajustement du système aux changements. Pendant la conception:  Importante qualité logicielle en jeu � évolutivité  anticipation du changement � Modularisation La phase de conception vise à :  déterminer quels seront les composants du logiciel à développer,  préciser les caractéristiques de ces composants,  concevoir les algorithmes permettant à ces composants d’effectuer les activités dont ils sont responsables. La conception Les diagrammes UML
  170. 170. 170 5.1. Les diagrammes de package
  171. 171. Chapitre 9: Architecture et conception de logiciel 171 Différentes façons de subdiviser un système – Un système distribué est divisé en clients et serveurs – Un système est divisé en sous-systèmes – Un sous-système peut être subdivisé en paquetages – Un paquetage est composé de classes – Une classe est composée de méthodes Le diagramme de package Les diagrammes UML
  172. 172. Packages Le diagramme de package Les diagrammes UML
  173. 173. Soit le cas ’’Réservation de vols dans une agence de voyages’’ 1° Des compagnies aériennes proposent différents vols. 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie. 3° Un client peut réserver un ou plusieurs vols, pour des passagers différents. 4° Une réservation concerne un seul vol, et un seul passager. 5° Une réservation peut être annulée ou confirmée. 6° Un vol a un aéroport de départ et un aéroport d’arrivée. 7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée. 8° Un vol peut comporter des escales dans des aéroports 9° Une escale a une heure d’arrivée et une heure de départ. 10° Chaque aéroport dessert une ou plusieurs villes Le diagramme de package – Etude de cas Les diagrammes UML
  174. 174. CompagnieAerienne VolPropose 1..* � Modélisation de la phrase : 1° Des compagnies aériennes proposent différents vols. CompagnieAerienne et Vols sont 2 objets métiers : 2 classes • Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs CompagnieAerienne VolPropose 1..* affréteur 1..* Le diagramme de package – Etude de cas Les diagrammes UML
  175. 175. � Modélisation de la phrase : 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie. � Tout objet peut avoir un état (diagramme d’états). � Dans un diagramme de classes tout concept dynamique est modélisé en opération. � Il faut représenter la 2° phrase par 2 opérations : ouvrirReservation( ) et fermerReservation( ) � Dans quelle classe ? Responsabilité d’une classe CompagnieAerienne Propose 1..* affréteur 1..* Vol état (ouvert, fermé) CompagnieAerienne Propose 1..* affréteur 1..* Vol ouvrirVol( ) fermerVol( ) � Les opérations sont déclarées dans l’objet dans lequel elles doivent s’exécuter � Les autres pourront déclencher ces opérations par envoi de messages � Le classe CompagnieAerienne a une association avec la classe vol. Le diagramme de package – Etude de cas Les diagrammes UML
  176. 176. � Modélisation des phrases : 7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée. � Les dates et les heures de départ et d’arrivée ne représentent que des valeurs : attributs. CompagnieAerienne Propose 1..* affréteur 1..* Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee � Pour savoir si un élément doit être représenté en attribut ou en objet : � S’il n’ y a que sa valeur qui est intéressante : c’est plutôt un attribut. � Si plusieurs questions peuvent concerner l’élément, alors il faut le représenter en objet. Le diagramme de package – Etude de cas Les diagrammes UML
  177. 177. � Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. � Modélisation peu parlante. � Par quoi peut-on représenter l’élément ‘’Aéroport’’ ? 3 réponses sont envisageables : 1. Soit avec une classe et une association de multiplicité 2 { ordered} 2 Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee aeroportDepart aeroportArivvee Aéroport nom Le diagramme de package – Etude de cas Les diagrammes UML
  178. 178. � Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. � Modélisation non correcte. Tout aéroport peut être de départ et d’arrivée. 2. Soit avec 2 classes 1 Vols ouvrirReservation() fermerReservation() dateDepart heureDepart dateArrivee heureArrivee aeroportDepartr aeroportArivvee Aéroport nom AeroportDepart AeroportArrivee1 Le diagramme de package – Etude de cas Les diagrammes UML
  179. 179. � Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. � Le rôle de chaque association précise son sens. 2. Soit avec 2 associations 1 Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Aéroport Nom … 1 Départ Arrivée Le diagramme de package – Etude de cas Les diagrammes UML
  180. 180. � Modélisation des phrases : 10° Chaque aéroport dessert une ou plusieurs villes Aéroport dessert 1..* Ville 0..* � Si on considère que desservir une ville signifie l’aéroport le plus proche, il n’ en y a qu’un : la multiplicité est de 1 � Si on considère que desservir une ville signifie les aéroports dans un rayon de 35 km : la multiplicité est de 0..* � On ne peut pas savoir la multiplicité de ‘’Aéroport’’ Le diagramme de package – Etude de cas Les diagrammes UML
  181. 181. � Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports 9° Une escale a une heure d’arrivée et une heure de départ. Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Aéroport nom1 1 Depart Arrivee Escale heureArrivee heureDepart 0..* � Une escale a les propriétés heure d’arrivée et heure de départ, c’est donc un objet. � Quelles sont alors les multiplicités entre ‘’Vols’’ et ‘’Escale’’, entre ‘’Escale’’ et ‘’Aeroport’’ et entre ‘’Aeroport’’ et ’Vols’’ ? 0..* 0..* 1 1 0..* Le diagramme de package – Etude de cas Les diagrammes UML
  182. 182. � Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports 9° Une escale a une heure d’arrivée et une heure de départ. � ‘’Escale’’ a peu d’informations propres. Elle n’est qu’une partie de ’’Vol’’ . � On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n’est pas totalement un aéroport. � La meilleure solution serait de la modéliser comme une classe d’association entre et ’Vols’’ et ‘’Aéroport’’. Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Aéroport nom 1 1 Départ Arrivée Escale heureArrivee heureDepart Escale 0..*0..* 0..* 0..* {Ordered} Le diagramme de package – Etude de cas Les diagrammes UML
  183. 183. � Modélisation des phrases : 4° Une réservation concerne un seul vol, et un seul passager. 5° Une réservation peut être annulée ou confirmée. � La réservation et le passager sont 2 concepts métier : 2 classes d’objets � Un réservation concerne un seul vol et un seul passager: donc 2 associations entre ‘’Vol’’ et ’’Réservation’’ et entre ’’Réservation’’ et ‘’Passager’’. � La 5° phrase se traduit par l’ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’. Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Passager 1 1 concerne Réservation Annuler( ) Confirmer( ) concerne Le diagramme de package – Etude de cas Les diagrammes UML
  184. 184. � Modélisation des phrases : 3° Un client peut réserver un ou plusieurs vols, pour des passagers différents. � Il faut discerner un client d’un passager a effectué 0..* 0..* 0..* Vol Passager 1 1 concerne Réservation Annuler( ) Confirmer( ) concerne Client 1 Le diagramme de package – Etude de cas Les diagrammes UML
  185. 185. � Le diagramme des classe complet est : Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Aéroport nom 1 1 départ arrivée InfosEscale heureArrivee heureDepart escale 0..*0..* 0..* 0..* {ordered} Ville 0..* Passager 1 concerne Réservation Annuler( ) Confirmer( ) Client a effectué 0..* 1 0..* 1 concerne CompagnieAerinne Propose 1..* 1..* nom Prénom adresse téléphone e-mail nom nom Prénom nom date numéro Le diagramme de package – Etude de cas Les diagrammes UML
  186. 186. � Diagramme des classe complet et annoté InfosEscale heureArrivee heureDepart Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Aéroport nom 1 1 départ arrivée escale 0..*0..* 0..* 0..* {ordered} Ville 0..* Passager 1 concerne Réservation Annuler( ) Confirmer( ) Client a effectué 0..* 1 0..* 1 concerne Propose 0..1 1..* nom Prénom adresse tél e-mail nom Prénom nom {frozen} {frozen} CompagnieAerinne nom numéro date numéro Le diagramme de package – Etude de cas Les diagrammes UML
  187. 187. � Le diagramme des classe complet devient : InfosEscale heureArrivée heureDépart ‘’ métaclasse ‘’ VolGenerique ouvrirVol( ) fermerVol( ) jour heureDépart heureArrivée /durée périodevalidité Aéroport nom 1 1 départ arrivée escale 0..*0..* 0..* 0..* {ordered} Ville 0..* 1 concerne Réservation Annuler( ) Confirmer( ) Client a effectué 0..* 1 0..* 1 concerne Propose 0..1 1 nom Prénom adresse téléphone e-mail Passager nom Prénom nom {frozen} {frozen} CompagnieAérienne nom numéro date numéro Vol ouvrirVol( ) fermerVol( ) dateDépart dateArrivée {frozen}{AddOnly} décrit 0..* 1 1..* 0..* propose Affréteur Le diagramme de package – Etude de cas Les diagrammes UML
  188. 188. � Le diagramme des classes peut être réorganisé en packages InfosEscale heureArrivee heureDepart ‘’ metaclasse ‘’ VolGenerique ouvrirVol( ) fermerVol( ) jour heureDepart heureArrivee /durée periodevalidite Aéroport nom 1 1 départ arrivée escale 0..*0..* 0..* 0..* {ordered} Ville 0..* 1 concerne Réservation Annuler( ) Confirmer( ) Client a effectué 0..* 1 0..* 1 concerne Propose 0..1 1..* nom Prénom adresse tééphonel e-mail Passager nom Prénom nom {frozen} {frozen} CompagnieAerinne nom numéro date numero Vol ouvrirVol( ) fermerVol( ) dateDepart dateArrivee {frozen}{AddOnly} décrit 0..* 1 1..* 0..* propose Affréteur Le diagramme de package – Etude de cas Les diagrammes UML
  189. 189. � Réduire la dépendance mutuelle afin d’augmenter la modularité et l’évolutivité d’une application 0..* 1 concerne {frozen} Réservation Annuler( ) Confirmer( ) date numéro Réservations Vol ouvrirVol( ) fermerVol( ) dateDepart dateArrivee Vol Le diagramme de package – Etude de cas Les diagrammes UML
  190. 190. Réservations Réservation Annuler( ) Confirmer( ) Client a effectué 0..* 1 0..* 1 concerne nom Prénom adresse téléphone e-mail Passager nom Prénom {frozen} date numéro Vol InfosEscale heureArrivee heureDepart ‘’ metaclasse ‘’ VolGenerique ouvrirVol( ) fermerVol( ) jour heureDepart heureArrivee /durée periodevalidite Aéroport nom 1 1 départ arrivée escale 0..*0..* 0..* 0..* {ordered} Ville Propose 0..1 1 nom CompagnieAerinne nom numéro Vol ouvrirVol( ) fermerVol( ) dateDepart dateArrivee {frozen}{AddOnly} decrit 0..* 1 1..* 0..* propose Affréteur 0..* 1 concerne {frozen} Le diagramme de package – Etude de cas Les diagrammes UML
  191. 191. Généralisation et réutilisation � On veut élargir ce domaine aux voyages par bus que des transporteurs assurent. � Un voyage en bus à une ville de départ et un ville d’arrivée avec des dates et des heures associées. � Un trajet peut comporter des arrêts dans des villes intermédiaires. � Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers VoyageEnBus OuvrirVoyage( ) fermerVoyage( ) dateDepart dateArrivee VoyagesBus ReservationsBus ReservationBus Annuler( ) Confirmer( ) date numéro 0..* 1 concerne {frozen} Le diagramme de package – Etude de cas Les diagrammes UML
  192. 192. concerne VoyagesBus InfosArret heureArrivee heureDepart VoyageEnBus ouvrirVoyage( ) fermerVoyage() dateDepart heureDepart dateArrivee heureArrivee /durée 1 1 départ arrivée arrêt 0..*0..* 0..* 0..* {ordered} Propose 0..1 1 Voyagiste nom référence Ville nom ReservationsBus 0..* 1..* concerne Client nom Prénom adresse téléphone e-mail Passager nom Prénom {frozen} ReservationBus Annuler( ) Confirmer( ) date numéro a effectué 0..* 1 {frozen} Le diagramme de package – Etude de cas Les diagrammes UML
  193. 193. Fusion des 2 modèles 1. Il faut isoler les classes communes dans des packages 2. Il faut factoriser les propriétés communes AVION Vols ReservationVols BUS ReservationBus VoyagesBus Lieux � Le diagramme de package – Etude de cas Les diagrammes UML
  194. 194. Il faut isoler les classes communes dans des packages � Vol (from Vols) ReservationVol (from ReservationsVols) ReservationBus (from ReservationsBus) VoyageEnBus (from VoyagesBus) concerne concerne {frozen} {frozen} 1 1 Réservations 0..* 1 concerneClient nom Prénom adresse tél e-mail Passager nom Prénom Réservation Annuler( ) Confirmer( ) date numéro {frozen} a effectué 0..*1 Classe abstraite Le diagramme de package – Etude de cas Les diagrammes UML
  195. 195. VolsVoyagesBus LieuxPackage réutilisable ReservationsBus Réservations ReservationsVols Packages spécialisés Package généralisé Le diagramme de package – Etude de cas Les diagrammes UML
  196. 196. 196 5.2. Les diagrammes de classes de conception
  197. 197. Stéréotypes • Mécanisme d’extensibilité • Sémantique du concept est insuffisante � le stéréotype permet la métaclassification �Ajouter de nouvelles classes sans perdre la sémantique � Faciliter l’unification des sous-systèmes et catégories Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  198. 198. 198 Stéréotype : définition • Un stéréotype permet d’étendre les classes déjà existantes en leur donnant une signification sémantique différente. • Si la classe A est un stéréotype de la classe B, alors A se comporte comme B tout en ayant une signification sémantique différente. • Représentation UML: <<stéréotype>> Nom de la Classe Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  199. 199. 199 Utilisation des stéréotypes Stéréotypes prédéfinis pour les classes d’analyse (proposés par Jacobson): • Boundary ou frontière ou interface • Control ou contrôle • Entity ou entité Représentation de Jacobson Nom du stéréotype Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  200. 200. 200 Stéréotypes… : boundary • La classe stéréotypée <<Boundary>> modélise la communication entre les acteurs et les composantes internes du système (les interfaces homme/machine, les interfaces des systèmes (protocole de communication,…) , interfaces des matériels (écran, clavier, imprimante,…)) <<boundary>> InterfaceRechercheSimple Auteur ISBN Titre Rechercher() Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  201. 201. 201 Stéréotypes… : Entity • La classe stéréotypée <<Entity>> modélise les informations persistantes du système. Exemples : classes qui contiennent des informations d’un étudiant, d’un employé, … <<Entity>> Livre code :entier titre : chaîne ISBN : entier nbrexemplaires:entier Getcode() GetTitre() FindByISBN (ISBN:entier) setNbrexemp(nbreexemplaires:entier) Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  202. 202. 202 Stéréotypes… : control «Control classes are generally used to represent coordination, sequencing, transactions, and control of other objects. And it is often used to encapsulate control related to a specific use case » [I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, Addison Wesley, 1999] Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  203. 203. 203 Stéréotypes… : control • La classe stéréotypée <<control>> assure la coordination entre classes • Elle contrôle le séquencement, ou coordonne l'exécution des objets contrôlés. • Elle contrôle la concurrence entre classes contrôlées, • Elle est l'implantation d'un objet intangible, • Au départ , on crée une classe "control" pour chaque use-case; cette classe gère le flot d'évènements dans le use-case, • Au fur et à mesure de l'avancement de l'analyse, les classes "control« peuvent être supprimées, découpées ou regroupées. <<control>> CTRLrecherche rechercherLivres() Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  204. 204. 204 <<control>> CTRLrecherche rechercherLivres() • Classes stéréotypées en relation <<Entity>> Livre auteur :entier titre : chaîne ISBN : entier nbrexemplaires:entier Getcode() GetTitre() FindByISBN (ISBN:entier) setNbrexemp(nbreexemplaires:entier) <<boundary>> InterfaceRechercheSimple Auteur ISBN Titre Rechercher() 0..* 0..* <Déclencherrech Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  205. 205. 205 • Les associations entre les classes stéréotypées suivent des règles assez strictes : – Les « boundary » ne peuvent être reliées qu’aux « control » – Les « control » ont accès aux « boundary », aux « entity » et aux autres contrôles – Les « entity » ont accès aux autres « entity » et ne sont reliées qu’aux « control » � Pour aller plus loin : utiliser des partons de conception (les design patterns) Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  206. 206. 206 Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  207. 207. Exemple de la localisation d’un DAB 207 Le diagramme de classe : de l’analyse à conception Les diagrammes UML
  208. 208. Conception détaillée Deux niveaux de conception : - une étape logique: indépendante de l’environnement de réalisation: • Conception détaillée des classes: trouver la meilleure manière de concevoir les structure logique, • Conception détaillée des associations (typage, portée, rémanence/persistance): – assurer la gestion des liens – traiter les classes associatives – optimiser la navigation • Délégation: dépendance des relations d’agrégation et de composition. • Raffiner la généralisation/spécialisation (héritage simple ou multiple): – propriétés structurelles – Interface – propriétés comportementales - une étape physique: liée à des particularités des langages de programmation ou de l’environnement d’exécution Raffinementdesdiagrammesstructurels 208 Le diagramme de classe de conception Les diagrammes UML
  209. 209. Conception détaillée des classes • Définir le type des attributs identifiés en analyse. – Type de base + composé • Structure • Enumération • Spécifier les Structures de Données. • Spécifier les visibilités des attributs et méthodes + prise en compte des propriétés (ordered, addOnly, frozen) • Spécifier les méthodes + celles spécifiques à l’implantation • Montrer les dépendances + Classes spécifiques Le diagramme de classe de conception Les diagrammes UML
  210. 210. Structure – Définition : Ensemble d’attributs pouvant être regroupés. <<structure>> Date jour mois années <<structure>> Adresse numRue rue codePostal ville pays 210 Le diagramme de classe de conception Les diagrammes UML
  211. 211. Enumération – Définition : Ensemble de littéraux d’énumération, ordonné. <<enumeration>> Jour Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche <<enumeration>> Titre Secretaire President Tresorier VicePresident Membre Le diagramme de classe de conception Les diagrammes UML
  212. 212. Visibilité des éléments • Restreindre l'accès aux éléments d'un modèle • Contrôler et éviter les dépendances entre classes (et paquetages) + public visible à l’extérieur de la classe # protégé visible que dans la classe et ses sous-classes  privé visible dans la classe uniquement ~ package visible dans la package uniquement $ élément de classe Remarques: • Utile lors de la conception et de l'implémentation, pas avant ! -N'a pas vraiment de sens dans le modèle d’analyse- • La sémantique exacte dépend du langage de programmation ! 212 Le diagramme de classe de conception Les diagrammes UML
  213. 213. Déclaration d'attributs [/] [ visibilité ] nom [ : type ] [card ordre] [ = valeur-initiale ] [ { props... } ] exemples: age +age /age - solde : Integer = 0 # age : Integer [0..1] # numsecu : Integer {frozen} # motsClés : String [*] {addOnly} $nbPersonne : Integer  Adapter le niveau de détail au niveau d'abstraction  La non précision de visibilité � privée Le diagramme de classe de conception Les diagrammes UML
  214. 214. Déclaration d'opérations [ visibilité ] nom [ ( params ) ] [ : type ] [ { props... } ] getAge() + getAge() : Integer - updateAge( in date : Date ) : Boolean # getName() : String [0..1] +getAge() : Integer +addProject() +$main( in args : String [*] {ordered} )  Adapter le niveau de détail au niveau d'abstraction  La non précision de visibilité � public Le diagramme de classe de conception Les diagrammes UML
  215. 215. Conception détaillée des classes : classes spécifiques • Classe utilitaire � Exemple: fonctions mathématiques d’une bibliothèque « Utilitaire » Math Math Le diagramme de classe de conception Les diagrammes UML
  216. 216. 217 Contraintes de gestion de l’association Par exemple : • { ordered } : les éléments de la collection sont ordonnés • { frozen } : fixé lors de la création de l ’objet, ne peut pas changer • { addOnly } : impossible de supprimer un élément RelevéDeCompte Ligne Opération *{ordered,addOnly} lignes Le diagramme de classe de conception Les diagrammes UML
  217. 217. 218 Rôle : traduction B * R A B 1 A R bs rs * b 1 a rolea carda carda rolea Le diagramme de classe de conception Les diagrammes UML
  218. 218. 219 Classe associative: traduction B * A B 1 A R bs * b 1 a as * * Le diagramme de classe de conception Les diagrammes UML R
  219. 219. Relation ternaire: traduction Le diagramme de classe de conception Les diagrammes UML
  220. 220. B * {ordered} R Role ordonné : traduction générale par index A B 1 A R bs rs ib : integer * b Pour tout a, tous les rs ont un indice ib différent et couvrant l'intervalle de 1 au nombre de bs. 1 a rolea carda carda rolea Le diagramme de classe de conception Les diagrammes UML
  221. 221. Pour tout a, tous les bs ont un indice iRb différent et couvrant l'intervalle de 1 au nombre de bs. B * {ordered} R Rôle ordonné 1 - * : traduction par index A B * A bs bsa a 1 iRb : integer 1 Le diagramme de classe de conception Les diagrammes UML
  222. 222. 224 Navigabilité d’une Association �La navigabilité permet de spécifier dans quel(s) sens il est possible de traverser l'association à l'exécution. �On interdit la navigation par une croix (X) du côté qui n'est pas atteignable. �On peut représenter les associations navigables dans un seul sens par des attributs. Les attributs sont toujours navigables. Le diagramme de classe de conception Les diagrammes UML
  223. 223. exist getAll nb empty Spécifier les méthodes pour la gestion des liens set get a b R M1 M0 0..10..1 Remarque : i. Les méthodes (ajout/suppression) doivent préserver la cohérence des cardinalités et les contraintes (exemple : AddOnly) ii. Les méthodes de navigation doivent être cohérentes avec le sens de navigation iii. En cas de cardinalité > 1 � possibilité de prévoir un attribut de type collection (surtout à définir lors de l’implémentation !! ) remove removeAll removeIdx add setAll insert a b R M1 M0 0..*0..1 Le diagramme de classe de conception Les diagrammes UML
  224. 224. Classes de conception Le diagramme de classe de conception Les diagrammes UML
  225. 225. Classes de conception Le diagramme de classe de conception Les diagrammes UML
  226. 226. Classes de conception Le diagramme de classe de conception Les diagrammes UML
  227. 227. Classes de conception Le diagramme de classe de conception Les diagrammes UML
  228. 228. Classes de conception Le diagramme de classe de conception Les diagrammes UML
  229. 229. 232 5.3. Notions d’abstraction et d’interfaces
  230. 230. 233 Le diagramme de classes Notion de classe abstraite Les diagrammes UML Une classe abstraite est une classe dont au moins une méthode est abstraite Une méthode abstraite est définie uniquement par son intitulé sans code abstract void calcul_long(); Dans les classes dérivées, la méthode abstraite doit être décrite  La méthode abstraite ne peut pas être private On ne peut pas créer un objet d’une classe abstraite Une classe abstraite est un type, il est possible de définir des variables ou paramètres de ce type; mais il faut affecter un objet d’une classe concrète, descendante
  231. 231. 234 Le diagramme de classes Notion de classe abstraite Les diagrammes UML But d’une classe abstraite Une classe abstraite permet de définir les caractéristiques communes à plusieurs classes. Une classe abstraite permet à un développeur : de fournir à d'autres développeurs une partie de l'implémentation d'une classe de laisser aux autres développeurs la manière d'implémenter le reste de la classe d'imposer aux autres développeurs d'implémenter certaines méthodes s'ils veulent pouvoir utiliser ses classes
  232. 232. • Exemple: deux classes Cercle, Carre qui possèdent des méthodes communes: – float surface() – void afficheInfo() dont les implémentations sont très différentes 235 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
  233. 233. • Solution : abstract class Figure{ private String nom; public String getNom( ){ return nom; } public abstract void afficheinfos( ); public abstract float surface( ); } 236 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
  234. 234. • Les règles usuelles d'héritage s'appliquent aux classes abstraites. • Les classes dérivées de Figure peuvent implémenter complètement, partiellement, ou pas du tout, les méthodes abstraites de Figure. • Suite de la solution : Figure f; f = new Cercle (…); f.surface( ); // utiliser la liaison dynamique ... 237 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
  235. 235. • Si A est déclarée comme classe abstraite alors on ne peut pas créer d'instance de la classe. • En revanche, on peut (on devrait) déclarer des variables de type A, et les instancier par n'importe quel objet de n'importe quelle classe concrète (non abstraite) dérivée de A. 238 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
  236. 236. 239 Le diagramme de classes Notion d’interface Les diagrammes UML Une interface est une classe abstraite ayant les caractéristiques suivants: toutes les méthodes sont abstraites et public, alors qu’une classe abstraite peut avoir des méthodes non abstraites tous les attributs sont static, alors qu’une classe abstraite peut avoir des attributs ordinaires toute classe peut hériter de plusieurs interfaces une interface peut hériter d’une ou plusieurs interfaces mais elle ne peut pas hériter d’une classe il n’est pas nécessaire d’indiquer abstract pour les méthodes et static pour les attributs
  237. 237. 240 Le diagramme de classes Notion d’interface Les diagrammes UML « interface » NomInterface NomClasse ou NomClasse Une classe qui implémente une interface doit définir le corps (les instructions) de toutes ses méthodes abstraites implémente
  238. 238. interface Chapeau{ void ajoute(Object o); Object tire(); boolean estVide(); } class ChapeauDoubleFond implements Chapeau{... } class ChapeauTripleFond implements Chapeau{... } class TourCartes{ … public void ajouteChapeau(Chapeau c){... } } 241 Le diagramme de classes Notion d’interface Les diagrammes UML
  239. 239. • Le code de TourCartes n'est pas lié à une implémentation particulière de Chapeau. TourCartes t=new TourCartes(); Chapeau c=new ChapeauDoubleFond(); t.ajouteChapeau(c); • Le seul moment où est mentionné le choix d'implémentation est lors de la construction de l'objet. 242 Le diagramme de classes Notion d’interface Les diagrammes UML
  240. 240. • Intérêt : – Séparation interface publique/implémentation – Permet une forme d’héritage multiple : • Par exemple, une classe C2 peut étendre une classe C1 et implémenter une interface I • Rôles : – rôle des interfaces: déclaration des méthodes publiques – rôle des classes: implémentation de ces méthodes 243 Le diagramme de classes Notion d’interface Les diagrammes UML
  241. 241. Une démarche couramment utilisée pour bâtir un diagramme de classes consiste à : 1. Trouver les classes du domaine étudié. Cette étape empirique se fait généralement en collaboration avec un expert du domaine. Les classes correspondent généralement à des concepts ou des substantifs du domaine. 2. Trouver les associations entre classes. Les associations correspondent souvent à des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme << est composé de >>, << pilote >>, << travaille pour >>. S. Mesfar 244 Etapes de l’élaboration d’un diagramme de classes Les diagrammes UML
  242. 242. 3. Trouver les attributs des classes. Les attributs correspondent souvent à des substantifs, ou des groupes nominaux, tels que << la masse d’une voiture >> ou << le montant d’une transaction >>. Les adjectifs et les valeurs correspondent souvent à des valeurs d’attributs. NB: Souvent, on ajoute des attributs à toutes les étapes du cycle de vie d’un projet (implémentation comprise). 4. Organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage. 5. Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première construction. La modélisation objet est un processus non pas linéaire mais itératif. S. Mesfar 245 Etapes de l’élaboration d’un diagramme de classes Les diagrammes UML
  243. 243. 246 5.4 : Les Diagrammes de collaboration / communication S. Mesfar
  244. 244. Notation • Les diagrammes de collaboration montrent des interactions entre objets, en insistant plus particulièrement sur la structure spatiale statique qui permet la mise en collaboration d’un groupe d’objets. • Les diagrammes de collaboration expriment à la fois le contexte d’un groupe d’objets (au travers des objets et des liens) et l’interaction entre ces objets (par la représentation de l’envoi de messages). � Les diagrammes de collaboration sont une extension des diagrammes d’objet. S. Mesfar 247 Le diagramme de communication / collaboration Les diagrammes UML
  245. 245. Notation •Les diagrammes de collaboration sont un recoupement des diagrammes d’objets et des diagrammes de séquences. •Chaque objet intervient de la même façon que dans les diagrammes de séquence •Les messages sont obligatoirement numérotés S. Mesfar 248 Le diagramme de communication / collaboration Les diagrammes UML
  246. 246. Notation Objet 1 Objet 2 Objet 3 1 : message 4 : message 2 : message 3 : message S. Mesfar 249 Le diagramme de communication / collaboration Les diagrammes UML
  247. 247. Exemple S. Mesfar 250 Le diagramme de communication / collaboration Les diagrammes UML
  248. 248. Rôles et connecteurs Le rôle permet de définir le contexte d'utilisation de l'interaction. �Si la ligne de vie est un objet, celui-ci peut avoir plusieurs rôles au cours de sa vie. Les relations entre les lignes de vie sont appelées connecteurs . �Un connecteur se représente de la même façon qu'une association mais la sémantique est plus large : un connecteur est souvent une association transitoire. S. Mesfar 251 Le diagramme de communication / collaboration Les diagrammes UML
  249. 249. Notation (…) La place de l’utilisateur � La notation permet de faire figurer un acteur dans un diagramme de collaboration afin de représenter le déclenchement des interactions par un élément externe au système. Grâce à cet artifice, l’interaction peu être décrite de manière plus abstraite sans entrer dans les détails des objets de l’interface utilisateur. � Le premier message est envoyé par l’acteur, représenté par un symbole graphique (type bonhomme) semblable au modèle des cas d’utilisation, ou bien par un objet muni d’un stéréotype qui précise sa qualité d’acteur. S. Mesfar 252 Le diagramme de communication / collaboration Les diagrammes UML
  250. 250. Représentation des messages Les flèches représentant les messages sont tracées à côté des connecteurs qui les supportent. Attention Bien faire la distinction entre les messages et les connecteurs : on pourrait avoir un connecteur sans message, mais jamais l'inverse. S. Mesfar 253 Le diagramme de communication / collaboration Les diagrammes UML
  251. 251. Multiplicité Les connecteurs permettent de rendre compte de la multiplicité. S. Mesfar 254 Le diagramme de communication / collaboration Les diagrammes UML
  252. 252. Numéros de séquence des messages Pour représenter les aspects temporels, on adjoint des numéros de séquence aux messages. �Des messages successifs sont ordonnés selon un numéro de séquence croissant (1, 2, 3, ... ou encore 3.1, 3.2, 3.3, ...). �Des messages envoyés en cascade (ex : appel de méthode à l'intérieur d'une méthode) portent un numéro d'emboîtement avec une notation pointée •1.1, 1.2, ... pour des messages appelés par une méthode dont l'appel portait le numéro 1 •2.a.1, 2.a.2, ... pour des messages appelés par une méthode dont l'appel portait le numéro 2.a S. Mesfar 255 Le diagramme de communication / collaboration Les diagrammes UML
  253. 253. Equivalence avec un diagramme de séquence S. Mesfar 256 Le diagramme de communication / collaboration Les diagrammes UML
  254. 254. Equivalence avec un diagramme de séquence S. Mesfar 257 Le diagramme de communication / collaboration Les diagrammes UML
  255. 255. Messages simultanés Lorsque des messages sont envoyés en parallèle, on les numérote avec des lettres •1.a, 1.b,... pour des messages simultanés envoyés en réponse à un message dont l'envoi portait le numéro 1 S. Mesfar 258 Le diagramme de communication / collaboration Les diagrammes UML
  256. 256. S. Mesfar 259 Classes Collaboration Le diagramme de communication / collaboration Les diagrammes UML
  257. 257. Opérateurs de choix et de boucle Pas d'opérateurs combinés dans les diagrammes de communication •*[<clauseItération>] représente une itération. �La clause d'itération peut être exprimée dans le format i:=1..n •[<clauseCondition>] représente un choix. La clause de condition est une condition booléenne. Elle représente la condition d’arrêt S. Mesfar 261 Le diagramme de communication / collaboration Les diagrammes UML
  258. 258. Syntaxe des messages �Syntaxe complète des messages est : [<numeroSéquence>][<expression>]:<message> �« message » a la même forme que dans les diagrammes de séquence, « numéroSéquence » représente le numéro de séquencement des messages et « expression » précise une itération ou un branchement conditionnel. �Exemples : �2 : affiche(x,y) : message simple. �1.3.1 : trouve("Hadock") : appel emboîté. �4 [x < 0] : inverse(x,couleur) : conditionnel. �3.1 *[i:=1..10] : recommencer() : itération. S. Mesfar 262 Le diagramme de communication / collaboration Les diagrammes UML
  259. 259. Collaborations et interactions �Les collaborations donnent lieu à des interactions �Les interactions documentent les collaborations �Les collaborations organisent les interactions. �Les interactions se représentent indifféremment par des diagrammes de communication ou de séquence S. Mesfar 263 Le diagramme de communication / collaboration Les diagrammes UML
  260. 260. UML - Le langage Objet unifié x : ClasseA y : ClasseB [ x ] 1: message message soumis à la condition x x : ClasseA y : ClasseB 1.a : message1 z : ClasseC1.b : message2 message1 et message 2 en parallèle x : ClasseA y : ClasseB 1.1 : message1 z : ClasseC1.2 : message2 message1.1 et message1.2 envoyés successivement vers y et z x : ClasseA y : ClasseB 1 : * [ 1..n ] message message envoyé n fois x : ClasseA : ClasseB // 1: message message envoyé en parallèle à plusieurs instances de la classe B x : ClasseA y : ClasseB 1.a, 2.c / 5: message message envoyé à y lorsque 1.a et 2.c sont satisfaits (synchronisation) : Voir diag. d’activités x : ClasseA y : ClasseB 1 : a : = message a récupère la valeur renvoyée par l’exécution du message (récupération d’un résultat)S. Mesfar Le diagramme de communication / collaboration Les diagrammes UML
  261. 261. Buts : 1. Décrire l’interaction des objets entre eux 2. Illustrer les scénarios des use cases 3. Valider les choix d’analyse et de conception (prototypage) 4. Aider au raffinement des diagrammes de classes de conception 265 S. Mesfar Le diagramme de communication / collaboration Les diagrammes UML
  262. 262. 266 5.5 : Les Diagrammes Etats-transitions S. Mesfar
  263. 263. Concepts liés à la phase d’analyse � Un état réfère l’ensemble des valeurs qui décrit un objet à un moment spécifique. � En d’autres termes, l’état d’un objet est déterminé par les valeurs associées à ses attributs. � Quand les messages sont reçus, les opérations associées aux classes des objets considérés amènent des modifications de ces valeurs. 267 Le diagramme Etats-Transitions Les diagrammes UML

×