UML UNIFIED MODELING LANGAGE

Transcription

1 UML UNIFIED MODELING LANGAGE Session gérard colo 1

2 notre objectif : comprendre et utiliser UML apprendre à utiliser un environnement de développement connaître les principaux diagrammes, leur finalité et leur utilisation savoir conduire une analyse en utilisant UML 2

3 UML UNIFIED MODELING LANGAGE A définitions, terminologie 7 A1 Unified Modeling Langage 7 A2 les pionniers (U comme Unifié) 8 A3 définitions intermédiaires 9 A4 une forêt de sigles 12 B présentation d UML 17 B1 origine 17 B2 L comme Langage 18 B3 liste des diagrammes (version 1.5) 20 B4 évolution de la norme (version 2.0) 21 B5 le méta-modèle UML 22 B6 principales ressources 24 3

4 C diagrammes de cas d utilisation 25 C1 but 25 C2 exemple de scénario 25 C3 domaines d application 28 C4 approfondissements 29 C5 auto-test 33 D diagrammes de classes 35 D1 but 35 D2 exemple de description 35 D3 auto-test 39 D4 approfondissements 40 D41 composition-agrégation 40 D42 accessibilité et portée 42 D43 dépendances et contraintes 44 D44 interfaces et stéréotypes 46 D5 auto-test 48 4

5 E diagrammes de paquetages 53 E1 but 53 E2 exemple 53 E3 auto-test 55 F diagrammes d objets 57 F1 but 57 F2 exemple 58 F3 instanciation 59 F4 auto-test 61 G diagrammes de séquence 63 G1 but 63 G2 exemple 64 G3 approfondissement 66 G4 auto-test 67 5

6 H diagrammes de collaboration 69 H1 but 69 H2 exemple 69 I diagrammes d états-transitions 74 I1 but 74 I2 exemple 74 I3 approfondissement 77 I4 auto-test 79 J diagrammes d activités 81 J1 but 81 J2 exemple 82 J3 auto-test 85 K diagrammes de composants et de déploiement 87 K1 but 87 K2 exemple 88 K3 auto-test 90 6

7 A définitions, terminologie A1. Unified Modeling Language le logo officiel d UML (page de garde) et détail agrandi ci-contre montre les initiales TM (Trade Mark) : UML est une marque elle est la propriété de l OMG (v. plus loin «une forêt de sigles») UML est le résultat de l unification en 1997, par une norme, des 3 principaux langages de modélisation qui existaient alors. 7

8 A2. les pionniers (U comme Unifié) Grady BOOCH (General Electric) a créé en 1993 OOD : Object Oriented Design, (conception orientée objet), adapté aux gros projets Ivar JACOBSON (Ericsson) a créé en 1995 OOSE : Object Oriented Software Engineering, qui introduit les use cases (cas d utilisation) John RUMBAUGH (Rational Rose) a créé en 1996 OMT : Object Modeling Technique, méthode de spécification (vs Merise) OOD + OOSE + OMT = UML 8

9 A3. définitions intermédiaires ce chapitre pourra être complété en cours d année, en fonction des rencontres que nous ferons (d où le n de version). Il est destiné à préciser le sens d un mot, sa traduction, etc, dans le cadre de cette session. par exemple, dans le paragraphe précédent nous avons utilisé le mot «spécification», dont la sémantique particulière en informatique peut ne pas être connue de tout le monde. de même, dans le passage de l anglais au français, certaines traductions qui paraissent faciles sont déroutantes, comme pour «common» dans CORBA (v. plus loin) 9

10 broker client-serveur common connection code engineering distribué extensible implantation implémentation : courtier, programme régulant les échanges de messages : les traitements sont répartis entre les clients qui les demandent et un serveur qui fournit les informations : commun à plusieurs, distribué (dans CORBA) : connexion : (dans UML) génération du code à partir des diagrammes : qualifie un environnement où les ressources ne sont pas toutes au même endroit (vs. client-serveur) : développable par l utilisateur : (implementation) adaptation d un logiciel à un environnement : (implementation) réalisation de la phase finale d un système, son entrée en fonction 10

11 méta-modèle modèle modélisation objet orienté objet portage : modèle qui décrit les éléments de modélisation : abstraction d un système physique : élaboration de modèles : élément logiciel représentatif d un élément du monde réel (personne, document, etc) : qualifie un langage, une base de données, un outil, etc, manipulant ses entités en utilisant la notion d objet : adaptation d une application à un système différent de celui sur laquelle elle a été conçue reverse engineering : (dans UML) génération inversée, c està-dire construction du diagramme à partir du code spécification : description formelle d un système (constitution, fonctionnement) 11

12 A4. une forêt de sigles tous ne sont pas à connaître par cœur, mais il faut pouvoir s y reporter et comprendre leur signification profonde. la présentation des sigles qui nous concernent dans cette session, est effectuée en les rattachant à l organisme de normalisation auquel ils se rattachent : OMG, ISO, W3C, Microsoft, IBM, etc comme le glossaire de la section précédente, cette section pourra être développée en cours de session, en fonction de nos rencontres (d où le n de version). 12

13 OMG : Object Management Group. association de professionnels de l informatique orientée objet, ayant défini plusieurs normes : UML : Unified Modeling Language (langage de modélisation unifié) CORBA : Common Object Request Broker Architecture (Standard de programme de gestion d échange d objets distribués) OMA : Object Management Architecture ORB : Object Request Broker (Objet dans un environnement CORBA) IDL : Interface Definition Language (Langage d interfaçage des objets sous CORBA) XMI : XML Metadata Interchange (Standard d échanges de données UML basé sur XML) : en IRC (Internet Relay Chat) OMG = Oh my god! 13

14 ISO : International Standard Organization, a défini de nombreux standard dont le fameux SGML : SGML : Standard Generalized Markup Language (standard général de langage de balise) définissant les documents hypertexte de toutes sortes, et dont sont issus HTML et XML, qui eux sont gérés par W3C W3C : World Wide Web Consortium créé en 1994 par Tim Burners-Lee, pour la mise au point de normes ouvertes et libres : HTML : HyperText Markup Language, format de documents du web XML : extensible Markup Language (langage de balise extensible) 14

15 Microsoft : a défini de nombreux standard pour les objets qui lui sont propres : COM : Component Object Model (Standard de gestion d échange d objets distribués) qui est propre à l environnement Microft, et qui s oppose à CORBA dans l environnement OMG COM+ : Amélioration de COM OLE : Object Linking and Embedding, (liaison et incorporation d objets), technique s appuyant sur COM et permettant d incorporation dans un document de documents provenant d autres applications IBM (devenu propriétaire de Rational),au titre de ce qui nous intéresse ici : RUP : Rational Unified Process, méthodologie de développement orientée objet, et utilisant le Web 15

16 MDL : (d après le mot MoDeL) extension de fichier au format Rational Rose Internet divers : autres «normes» régies par RFC : IRC : Internet Relay Chat, serveur permettant de dialoguer en direct à plusieurs, inventé en 1988 par Jarkko Oikarinen, aidé par plusieurs centaines de contributeurs depuis. RFC : Request For Comment, documentation générale des standard, des protocoles, etc, sur Internet. Il ne s agit pas à proprement parler de normes, mais de documents respectés par la communauté Internet. 16

17 B présentation d UML B1. origine la connaissance d un langage de programmation de suffit pas à l application des principes orientés objet besoin de rigueur et d expressivité besoin de comparer des architectures différentes besoin d une vue synthétique d une spécification, d un système 17

18 B2. L comme Langage UML est un langage graphique, comme l est un plan, un croquis, un diagramme, etc UML n est pas une méthodologie de développement, contrairement à RUP, par exemple RUP : Rational Unified Process, méthodologie de développement logiciel orientée objet, qui définit quatre phases successives, devant satisfaire à un critère prédéfini, avant que la phase suivante ne puisse être engagée : phase d étude : critère = portée du projet phase d élaboration : critère = besoins du projet phase de construction : critère = achèvement du code source phase de transition : critère = délivrance du système à l utilisateur 18

19 UML se veut un langage simple, expressif évolutif, extensible, spécialisable indépendant du contexte d utilisation indépendant du processus de conception orienté objet présentant des vues logiques, d installation (implantation) et de mise en œuvre (implémentation) chaque diagramme donne un angle de lecture, en les combinant on a une vue complète du système les diagrammes structurent le modèle : ils groupent les notions liées, et se relient entre eux à travers les objets 19

20 B3. liste des diagrammes (version 1.5) classés par catégories : diagramme vues simples (statiques) de cas d utilisation de classes de paquetages d objets diagram use case class packages objects de comportement (dynamiques) d états transitions d activité avec interaction de séquence de collaboration statechart activity sequence collaboration 20

21 d implémentation de composants et déploiement components & deployment B4. évolution de la norme (version 2.0) depuis cette année(2004), UML existe dans une nouvelle norme, UML 2.0, qui apporte comme principale nouveauté : un nouveau diagramme (diagramme d architecture) et quelques nouveaux concepts sur les diagrammes de la norme précédente. a priori, nous ne les aborderons pas. 21

22 B5. le méta-modèle UML UML est également un méta-modèle, et la norme en décrit précisémment : les concepts les graphiques (partie émergée de l iceberg) le langage ceci permet la comparaison et le portage, d assurer la cohérence et la génération de code le choix des symboles et des diagrammes est nécessairement arbitraire, c est le principe même d une norme de choisir, et la valeur de ce choix vient de son universalité 22

23 B6. principales ressources URL intéressants : : le site UML de l OMG uml.free.fr : un cours très bien fait www-130.ibm.com/developerworks/rational, excellent site dédié aux utilisateurs de rational etc : pour chaque produit, l éditeur propose une adresse de support de développement, comme IBM pour Rational, ci-dessus livres : UML en action, Roques, Vallée (un des rares en Français) UML Reference manuel,par les «amigos» Rumbaugh, Jacobson et Booch. UML distilled, Fowler 23

24 logiciels : Rational Rose, IBM (la référence historique) Together, Borland (la rolls, notamment pour ses possibilités de «reverse engineering»!) Popkin System Architect, ArgoUML, (gnu) Poseidon for UML, (versions commerciales et free community edition) etc le métamodèle et la norme XMI assurent la compatibilité des développements (théoriquement) et les possibilités de portage. 24

25 C diagrammes de cas d utilisation C1. but décrire ce qu un système fait du point de vue d un observateur extérieur insister sur ce que (what) fait le système, et non sur comment (how) il le fait très bien adapté à la description d un scénario C2. exemple de scénario un patient appelle une clinique médicale pour un RV (non urgent). le réceptionniste recherche une date possible, et programme le RV pour cette date 25

26 le patient est un acteur, représenté par une figurine. un acteur initie un événement inclus dans le scénario, ici c est une personne, mais ce peut être autre chose, seul le rôle joué importe. le cas d utilisation «Prendre un RV» est entouré d une ellipse. la liaison entre l acteur et le cas d utilisation est une association, représentée par une ligne continue simple. 26

27 dans l image ci-dessous, nous avons complété le diagramme précédent, qui comprend maintenant 4 acteurs, et 4 cas d utilisation : remarquez qu un cas d utilisation peut avoir de multiples acteurs 27

28 C3. domaines d application les diagrammes de cas d utilisation sont utiles dans 3 domaines principalement détermination des besoins : ajouter de nouveaux cas d utilisation crée souvent de nouveau besoins au fur et à mesure que le système est analysé et que le projet prend forme communication avec les clients : La simplicité des notations rend les diagrammes de cas d utilisation très adaptés au dialogue avec les clients génération de cas de tests : La collection des scénarios pour un cas d utilisation peut suggérer une suite de cas de tests pour ces scénarios 28

29 C4. approfondissements les diagrammes de cas d utilisation donnent la vue d un système par un observateur extérieur au système ils comportent des acteurs (actors), des cas d utilisation (use cases), et des associations (communications) le simple diagramme de cas d utilisation qui nous a servi d exemple, peut être étendu pour introduire de nouveaux concepts, tels que : limites du système (system boundaries) généralisations (generalizations) inclusions (includes) extensions (extensions) 29

30 30

31 le rectangle «limite du système» sépare le système analysé des acteurs, qui lui sont externes ; il en porte également le nom. Poséidon ne propose pas cette représentation une généralisation montre qu un cas d utilisation est une spécialisation d un autre : «Règlement honoraires» est un parent, et «Prise en charge par l assurance» un enfant ; l enfant peut être substitué à son parent si nécessaire : la généralisation est une ligne continue avec une flèche triangulaire dirigée vers le parent les inclusions sont très utiles lorsqu un cas d utilisation peut être mis en facteur commun entre plusieurs autres cas d utilisation 31

32 «Prendre un RV» et «Prescription» sont deux cas d utilisation qui incluent «Vérifier la fiche du patient» comme sous-tâche ; dans le diagramme l association d inclusion est représentée par une ligne pointillée terminée par une flèche ouverte pointant vers le cas d utilisation inclus, et libellée «include» une extension indique qu un cas d utilisation est une variation ou une précision d un autre ; elle est représentée dans le diagramme par une ligne pointillée terminée par une flèche ouverte pointant vers le cas d utilisation de base, et libellée «extend» ; le point d extension, qui détermine quand le cas d utilisation étendu est approprié, est écrit à l intérieur du cas de base 32

33 C5. auto-test choisir dans les propositions ci-après celle qui contient 3 concepts intéressants dans un diagramme de cas d utilisation 1 : objet, activité, association 2 : acteur, message, activité 3 : objet, cas d utilisation, activité 4 : acteur, cas d utilisation, association (réponses page suivante) 33

34 1 : objet, activité, association objet : non activité : non association : oui 2 : acteur, message, activité acteur : oui message : non activité : non 3 : objet, cas d utilisation, activité objet : non cas d utilisation : oui activité : non 4 : acteur, cas d utilisation, association acteur : oui cas d utilisation : oui association : oui 34

35 D diagramme de classes D1. but donner une vue d un système, en montrant ses classes et les relations entre ses classes Les diagrammes de classes sont statiques : ils montrent ce qui interagit, mais pas ce qui se passe quand il y a une interaction Adapté à la description d un modèle, d une structure D2. exemple de description une commande client à partir d un catalogue d articles la classe centrale est la commande, associée au client qui achète, et au paiement qu il effectue 35

36 «Client», «Commande» et «Paiement» sont des classes. «Paiement», dont le titre est en italique est une classe abstraite. l association entre «Client» et «Commande» n est pas orientée ; celle entre «Commande» et «Paiement» l est : présence d une flèche ouverte de navigation, indiquant que «Commande» est propriétaire de l association la cardinalité (multiplicity) d une association est indiquée à ses extrémités 36

37 représentation d une classe une classe est représentée par un rectangle divisé en 3 parties : nom de la classe, attributs, opérations les liens (ou associations) entre classes, lorsqu ils existent sont des associations orientées ou non des agrégations ou des compositions des généralisations... 37

38 associations et instanciation il y a une association entre deux classes si une instance d une classe doit connaître une instance de l autre classe pour effectuer ses opérations cardinalité : convention 0..1 n..m 0..* ou * 1 n 1..* n..* : 0 ou 1 instance : de n à m instances : pas de limite (0 inclus) : exactement une instance (valeur par défaut) : exactement n instances : au moins une instance : n ou plus 38

39 D3. auto-test reproduire le diagramme ci-dessous nommer et commenter toutes les relations entre classes 39

40 D4. approfondissements D41. composition - agrégation 40

41 nous avons vu que les associations, qui relient un tout à ses parties sont de deux types, composition et agrégation, que nous illustrons ici avec 3 classes : la classe «Salle de cinéma» est un tout, et les classes «Caisse» et «Film» en sont des parties la composition est une relation forte, dans laquelle la, partie ne peut appartenir qu à un seul tout, ne peut pas exister sans le tout le diagramme montre que la «Caisse» n appartient qu à une seule «Salle de cinéma». La collection de «Film(s)» n est pas reliée aussi fortement à la «Salle de cinéma» : c est une agrégation 41

42 D42. accessibilité et portée 42

43 la classe est représentée par un rectangle à trois compartiments : le nom, les attributs, les opérations les attributs et opérations peuvent être étiquetés selon leur accessibilité et leur portée : + - # public private protected les membres «static» sont soulignés les attributs, les valeurs de retour des opérations et les paramètres des opérations ont un type, et éventuellement un espace de nommage (namespace) la syntaxe des opérations est la suivante : <<espace de nommage>><étiquette><nom>(<liste de paramètres typés>):<type retourné> 43

44 D43. dépendances et contraintes 44

45 la dépendance est une relation entre deux classes dans laquelle un changement dans l une d elles peut entraîner un changement dans l autre les dépendances sont notées en pointillé, avec une flèche à l extrémité dont le changement est à prendre en compte : dans l exemple de la vue précédente, un changement dans «Société» peut entraîner un changement dans «Stage» une contrainte est une condition que toute implémentation du projet devra nécessairement satisfaire les contraintes sont notées en clair entre accolades, exemple ci-dessus : {non annulée} dans l exemple, la contrainte indique que la «Session» peut faire partie de l «Emploi du temps» si elle n a pas été annulée 45

46 D44. interfaces et stéorotypes 46

47 le scénario de l exemple ci-dessus est le suivant : un séminaire itinérant (classe «Séminaire), composé de 1 à n conférences (classe «Conférence») se tient en des endroits et à des dates qui doivent être coordonnées entre les hôtels hébergeant les participants, et les horaires des navettes desservant ces hôtels : classes «Horaire_Navette» et «Arrêt_Navette» dans l exemple, il y a 3 classes interface (abstraites) dont les opérations (abstraites) sont les mêmes que dans les classes interfacées : l interface «Ilocalisation» est interfacée avec «Arrêt_Navette» et avec «Séminaire», les relations étant dénommées réalisations et représentées par une ligne pointillée et un triangle pointant sur l interface traditionnellement le nom de l interface commence par un I (majuscule) 47

48 la classe «Arrêt_Navette» a le stéréotype «emplacement» qui représente une extension par l utilisateur d UML l interface est également un stéréotype, fourni en standard le nom du stéréotype est inscrit entre double << >>, et fait penser aux espaces de nommage dans le code sous-jacent l interface peut aussi être représentée par un simple cercle dont les réalisations sont représentées par des traits continus : on perd un peu d information au bénéfice d une plus grande clarté du diagramme le diagramme de la page suivante et le diagramme précédent sont strictement équivalents 48

49 49

50 D5. auto-test exposé : chaque étudiant d une école a un professeur référent certains professeurs sont référents de plusieurs étudiants, mais certains ne le sont d aucun lequel des diagrammes suivants représente cette relation étudiant étudiant reproduisez dans Poséidon ces 4 diagrammes sur une seule page (les diagrammes proposés sont sur la page suivante, et les réponses sur la page d après) 50

51 51

52 1 non : au minimum, les cardinalités devraient être inversées, avec une agrégation, la cardinalité la plus grande doit être du côté du losange 2 oui : le diagramme montre bien que plusieurs étudiants peuvent avoir le même professeur référent 3 non : les cardinalités sont correctes, mais l association n est pas une agrégation. De toutes façons, compte-tenu des cardinalités, le losange est du mauvais côté 4 non : ce diagramme signifie que chaque professeur est le référent d exactement un étudiant, et que chaque étudiant peut avoir plusieurs professeurs référents 52

53 E diagrammes de paquetages E1. but simplifier les diagrammes de classes complexes, en groupant les classes en paquetages (packages) un paquetage est donc une collection d éléments UML logiquement reliés entre eux E2. exemple le diagramme de la page suivante montre un modèle de gestion de business dans lequel les classes ont été regroupées en paquetages 53

54 54

55 un paquetage apparaît comme un rectangle muni d un onglet (tab)à la partie supérieure le nom du paquetage est soit dans cet onglet, soit dans le rectangle lui-même Les flèches pointillées sont des dépendances : un paquetage dépend d un autre si une modification dans cet autre peut le modifier. E3. auto-test les deux affirmations suivantes sont-elles correctes? 1. les classes dans un diagramme de classes peuvent être regroupées en paquetages pour illustrer l organisation générale du modèle 2. Si un paquetage B dépend d un paquetage A, tout changement dans A nécessitera un changement dans B (réponses page suivante) 55

56 1 oui : les paquetages sont une excellente méthode pour éliminer, plus ou moin, les détails compliqués dans un diagramme de classes 2 non : ce n est pas tout-à-fait exact ; si le paquetage A change, le paquetage B peut être amené à changer, mais pas obligatoirement 56

57 F diagrammes d objets F1. but les diagrammes d objets sont très utiles pour représenter de petits morceaux de diagrammes de classes aux relations complexes c est particulièrement vrai pour les relations de type récursif, dont la compréhension n est pas évidente F2. exemple le diagramme de classes de la page suivante contient une classe «Département» (d une université par exemple), pouvant comporter 0 à n sous-départements de la même classe, donc pouvant à leur tout comporter d autres départements de façon récursive 57

58 Exercice : avant de retravailler ce diagramme pour en faire un diagramme d objet : 1 ) entraînez-vous à le dessiner, jusqu à ce que vous soyez capable de le refaire intégralement en moins d une minute 2 ) décrivez-en oralement, l ensemble des éléments, jusqu à ce que vous soyez sûr de bien montrer que vous le comprenez parfaitement 58

59 F3. instanciation pour éclairer le diagramme de classes précédent, nous utilisons une instanciation de la classe «Département» dans un diagramme d objets chaque rectangle dans le diagramme d objets correspond à une seule instance de classe : ici ce sont toutes des instances de la même classe dans les diagrammes UML les noms d instances sont soulignés : ils sont composés du nom de l instance proprement dit, séparé par «:» du nom de la classe instanciée 59

60 60

61 F4. auto-test une seule des propositions ci-après est exacte à propos des diagrammes d objets 1 : ce type de diagramme montre des objets dans un état particulier et des relations sémantiques entre ces objets 2 : dans un diagramme d objets, les noms des instances sont en italique ou en majuscules 3 : les diagrammes d objets et les diagrammes de classes sont complètement interchangeables (réponses page suivante) 61

62 1 oui : les instances de classe sont des états particuliers des objets, et les liens entre elles sont bien des relations sémantiques 2 non : les noms des instances sont soulignés ; ceci vaut également pour tous les diagrammes UML 3 non : le diagramme de classes est une abstraction du diagramme d objets, qui en montre une instance particulière 62

63 G diagrammes de séquence G1. but les diagrammes étudiés jusqu à présent étaient tous des vues statiques d un modèle avec ce diagramme, nous abordons les diagrammes de comportement : le diagramme de séquence est de plus un diagramme avec interaction c est un diagramme dynamique qui montre comment les objets collaborent il détaille l enchaînement des opérations, quels (what) messages sont envoyés, et quand (when) ces diagrammes sont organisés dans le temps : le temps se déroule de haut en bas 63

64 les objets concernés sont présentés de gauche à droite, selon le moment où ils prennent part à la séquence G2. exemple le diagramme de la page suivante contient une séquence «réservation d une chambre d hôtel» la séquence est initiée par l intermédiaire d un écran de réservation qui envoie un message à un hôtel : si l hôtel a une chambre disponible il effectue la réservation et envoie une confirmation pour chaque objet de cette vue, «écran», «Hôtel», «Réservation», «Confirmation», une ligne de temps verticale est affichée : elle est représentée par une ligne pointillée lorsqu elle ne sert que de repère, sinon, elle affiche un rectangle représenant sa durée de vie 64

65 cette vue fait également apparaître un commentaire (rectangle jaune au coin corné), qui peut être relié à un ou plusieurs objets; les commentaires sont disponibles dans tous les diagrammes UML 65

66 une itération est effectuée par l hôtel sur lui-même pour symboliser la recherche de la disponibilité sur chaque jour de la durée de séjour G3. approfondissement un message est dit asynchrone s il permet à l expéditeur d effectuer d autres tâches pendant sa durée d exécution Les conventions UML pour la représentation des messages sont les suivantes 66

67 G4. auto-test lequel des morceaux de diagrammes de séquence suivants représente cette action : «l objet A envoie à l objet B plusieurs messages nommés msg» (réponses page suivante) 67

68 1 non : le diagramme ne montre pas l existence de l objet B, avant l envoi des messages 2 non : où sont les barres d activation? 3 oui : l astérisque signifie que le message est envoyé plusieurs fois (0..*) 4 non : cette notation n est pas représentative du fait que le nombre de messages est indéterminé; même s il était déterminé il faudrait préférer la notation UML : «0..n», «n..m» ou «n» 68

69 H diagrammes de collaboration H1. but les diagrammes de collaboration sont également des diagrammes dynamiques ils expriment la même chose que les diagrammes de séquence, mais sans se focaliser sur la chronologie et la durée d action des objets, mais plutôt sur leurs rôles respectifs, et l articulation de ces rôles. les rôles des objets, leurs interactions et les messages sont représentés par les différents liens H2. exemple reprenons l exemple de la réservation d hôtel, vue sous l angle de l interaction entre les objets 69

70 70

71 les objets (rôles) sont intitulés soit comme des classes (précédés par «:») soit comme des objets, soit les deux chaque message d un diagramme de collaboration a un numéro de séquence composé comme suit : le premier message a le préfixe 1 lui-même et les messages du même niveau (envoyés dans le même appel) sont suffixés 1, puis 2, etc cette numérotation se propage par ajout de suffixe à chaque niveau, en fonction du «quand» de chaque message 71

72 H3. auto-test parmi les propositions suivantes, laquelle est correcte? 1. les diagrammes de collaboration sont des modèles dynamiques 2. les numéros de séquence dans les diagrammes de collaboration sont optionnels 3. les diagrammes de collaboration ne montrent pas les itérations puisqu elles sont des éléments de détail de bas niveau 4. les diagrammes de collaboration ne peuvent pas montrer un oblet qui s envoie un message à lui-même (réponses page suivante) 72

73 1 oui : un diagramme de collaboration n est pas une vue statique d un système; il montre les objets en action 2 non : les numéros de séquence sont nécessaires pour montrer l ordre dans lequel les messages sont envoyés 3 non : l itération est une partie importante de l aspect dynamique des diagrammes de collaboration; notre exemple montre un auto-lien représentant une itération 4 non : le message envoyé par un objet à lui-même apparaît comme une boucle sur un des sommets de l objet; notre exemple en montre une 73

74 I diagrammes d états- transitions I1. but les objets ont des comportements et des états l état d un objet dépend de conditions diverses et de son activité le diagramme d états-transitions se propose de montrer les différents états d un objet et les transitions entre ces états I2. exemple le système modélisé attend la frappe d un identifiant et d un mot de passe, valide ou non cette saisie, puis en cas de non-validation ré-essaie ou abandonne, et en cas de validation, débute une transaction 74

75 75

76 les états sont représentés par des rectangles arrondis; les actions attendues dans un état donné sont indiquées par «entry/», «do/» (par exemple dans l état «Validation»), ou «exit/» l état initial éventuel est un rond noir le ou les états finals sont indiqués par des ronds noirs cerclés les transitions sont indiquées par des flèches d un état à l autre; les événements ou conditions qui déclenchent ces transitions sont écrits à côté de ces flèches dans notre diagramme il y a deux auto-transitions : dans «saisir Identifiant» et dans «saisir Pin» 76

77 I3. approfondissement les états d un diagramme d états-transitions peuvent être imbriqués les états peuvent également être regroupés dans des états composites imbriquer des états est nécessaire quand une activité implique des sous-activités concurrentes ou asynchrones le diagramme suivant illustre ces notions : il modélise une vente aux enchères avec deux threads concurrents conduisant à deux sous-états d un état composite «Vente aux enchères»; ces 2 sous-états «Enchérir» et «Autorisation de crédit» sont euxmêmes composites l entrée dans «Vente aux enchères» nécessite une fourche, et une des sorties nécessite une jointure 77

78 s il n y a pas de sortie par la transition «refus et abandon» ou par la transition «rejet», l état final «Achat» nécessite l occurrence des deux sous-états «Enchérir» et «Autorisation de crédit» 78

79 I4. auto-test parmi les propositions suivantes, laquelle est correcte? 1. toutes les actions d un diagramme d étatstransitions sont rattachées à des transitions 2. un événement lié à un objet peut avoir pour conséquence que cet objet ne change pas d état 3. une fois qu un objet a quitté un état, il ne peut pas retourner à cet état 4. deux transitions issues du même état peuvent se chevaucher (overlap), c est-à-dire qu elles peuvent être issues du même événement (réponses page suivante) 79

80 1 non : les actions peuvent être écrites dans l état comme sur l état «Copier» ci-contre où les actions suivantes se produisent : Montrer_timer : l objet entre dans l état Copier_fichiers : l objet est dans l état Effacer_timer : l objet sort de l état 2 oui : c est le cas par exemple dans les autotransitions 3 non : dans notre exemple, on voit des allers-retours entre «saisir Identifiant» et «saisir PIN» 4 non : les transitions ne peuvent pas se chevaucher, les états ne peuvent pas se chevaucher : aucune ambiguïté n est permise dans un diagramme d étatstransitions 80

81 J diagrammes d activités J1. but les diagrammes d activités se proposent de représenter le déroulement d un cas d utilisation, c est-à-dire la succession des tâches à entreprendre pour obtenir un résultat donné : une activité se comprend une succession d étapes les transitions sont automatiques entre la fin d une étape et le début de la suivante les diagrammes d états-transitions mettent l accent sur la traversée d un processus (process) par un objet, alors que, les diagrammes d activités se focalisent sur le flux d activités concourant à la réalisation d un processus 81

82 c est le comment (how) de la description d un système que nous avons soigneusement évité dans les diagrammes de cas d utilisation (voir C1) J2. exemple trois classes sont impliqués dans notre scénario : le client, le DAB et la banque le processus débute, comme dans le diagramme d états-transitions par un état initial représenté par un rond noir, et se termine de même par un état final représenté par un rond noir cerclé comme dans le diagramme de séquence, le temps s écoule de haut en bas les activités sont des rectangles arrondis 82

83 (suite page suivante) 83

84 (début page précédente) 84

85 J3. auto-test soit le diagramme d activité suivant : quel est le pseudo-code qui lui correspond? 1. if (OK) then do C else do A and B do D 2. do C do A and B do D (réponses page suivante) 85

86 1 oui : A et B seront exécutés si OK est false; l ordre d exécution de A et B est sans importance, mais les deux doivent être exécutés (barre de synchronisation) avant l exécution de D 2 non : soit C sera exécuté, soit A et B, mais jamais tous les trois 86

87 K diagrammes de composants et de déploiement K1. but les composants sont des modules de code les composants se proposent de schématiser l articulation et les dépendances des application (software); ils sont physiquement analogues aux diagrammes de classe les diagrammes de déploiement (plus simplement utilisé pour diagrammes de composants et de déploiement) montrent les configuration physiques, tant logicielles que matérielles des systèmes (software et hardware) 87

88 K2. exemple le diagramme de déploiement ci-après montre les relations software et hardware dans une application de transactions immobilières les représentations des composants physique «hardware» sont des nœuds (node), rectangles en 3 dimensions (box). les représentations des composants logiciels «software» sont des composants proprement dits (component); normalement ils sont représentés par des rectangles munis de deux petits onglets en haut et à gauche (double tabbed rectangle) : Poséidon les représente bien comme cela dans la barre d outils, mais pas dans les diagrammes (rectangle simple, avec le mot <<component>> ) la classe «interface» qui sert à représenter les points de liaison entre nœuds, a déjà été vue par ailleurs (voir diagrammes de classes D44) 88

89 89

90 K3. auto-test choisir parmi les propositions suivantes, celle qui vous paraît être la réponse correcte à la question : quel est le symbole d un composant dans un diagramme de déploiement? 1. il n y en a pas, parce que les composants ne sont pas permis dans un diagramme de déploiement 2. un rectangle arrondi, comme pour un état dans un diagramme d états-transitions 3. un rectangle en 3 dimensions 4. un rectangle avec deux onglets en haut et à gauche (réponses page suivante) 90

91 1 non : les composants sont des modules de code, installés dans nœuds du système physique du diagramme de déploiement 2 non : c est bien une forme rectangulaire, mais pas avec les coins arrondis 3 non : le rectangle 3D sert à représenter les nœuds physiques du système 4 oui : la forme correcte est bien un rectangle avec onglets, bien que Poséidon ne le représente pas ainsi dans la version utilisée 91