Embed Size (px)
Citation preview
2004-2005. Version 1IS21
UMLUMLUNIFIED MODELING LANGAGEUNIFIED MODELING LANGAGE
Session IS2 Session IS2 –– 20042004--20052005
gérard [email protected]
2004-2005. Version 1IS2 2
notre objectif : comprendre et notre objectif : comprendre et utiliser UMLutiliser 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
2004-2005. Version 1IS2 3
UMLUMLUNIFIED MODELING LANGAGEUNIFIED MODELING LANGAGE
A définitions, terminologie 7A1 Unified Modeling Langage 7A2 les pionniers (U comme Unifié) 8A3 définitions intermédiaires 9A4 une forêt de sigles 12
B présentation d’UML 17B1 origine 17B2 L comme Langage 18B3 liste des diagrammes (version 1.5) 20B4 évolution de la norme (version 2.0) 21B5 le méta-modèle UML 22B6 principales ressources 24
2004-2005. Version 1IS2 4
C diagrammes de cas d’utilisation 25C1 but 25C2 exemple de scénario 25C3 domaines d’application 28C4 approfondissements 29C5 auto-test 33
D diagrammes de classes 35D1 but 35D2 exemple de description 35D3 auto-test 39D4 approfondissements 40
D41 composition-agrégation 40D42 accessibilité et portée 42D43 dépendances et contraintes 44D44 interfaces et stéréotypes 46
D5 auto-test 48
2004-2005. Version 1IS2 5
E diagrammes de paquetages 53E1 but 53E2 exemple 53E3 auto-test 55
F diagrammes d’objets 57F1 but 57F2 exemple 58F3 instanciation 59F4 auto-test 61
G diagrammes de séquence 63G1 but 63G2 exemple 64G3 approfondissement 66G4 auto-test 67
2004-2005. Version 1IS2 6
H diagrammes de collaboration 69H1 but 69H2 exemple 69
I diagrammes d’états-transitions 74I1 but 74I2 exemple 74I3 approfondissement 77I4 auto-test 79
J diagrammes d’activités 81J1 but 81J2 exemple 82J3 auto-test 85
K diagrammes de composants et dedéploiement 87
K1 but 87K2 exemple 88K3 auto-test 90
2004-2005. Version 1IS2 7
A A –– définitions, terminologiedéfinitions, terminologieA1. 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 marqueelle 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.
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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)
2004-2005. Version 1IS2 10
broker : courtier, programme régulant les échanges de messages
client-serveur : les traitements sont répartis entre les clients qui les demandent et un serveur qui fournit les informations
common : commun à plusieurs, distribué (dans CORBA)
connection : connexioncode engineering : (dans UML) génération du code à partir
des diagrammesdistribué : qualifie un environnement où les
ressources ne sont pas toutes au mêmeendroit (vs. client-serveur)
extensible : développable par l’utilisateurimplantation : (implementation) adaptation d’un
logiciel à un environnementimplémentation : (implementation) réalisation de la phase
finale d’un système, son entrée en fonction
2004-2005. Version 1IS2 11
méta-modèle : modèle qui décrit les éléments de modélisation
modèle : abstraction d’un système physique modélisation : élaboration de modèles objet : élément logiciel représentatif d’un
élément du monde réel (personne,document, etc)
orienté objet : qualifie un langage, une base de données, un outil, etc, manipulant ses entités en utilisant la notion d’objet
portage : 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)
2004-2005. Version 1IS2 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).
2004-2005. Version 1IS2 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 ArchitectureORB : 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 !
2004-2005. Version 1IS2 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 webXML : eXtensible Markup Language (langage de balise extensible)
2004-2005. Version 1IS2 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 OMGCOM+ : Amélioration de COMOLE : 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
2004-2005. Version 1IS2 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.
2004-2005. Version 1IS2 17
B B –– présentation d’ UMLprésentation d’ UMLB1. 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
2004-2005. Version 1IS2 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 projetphase d’élaboration : critère = besoins du projetphase de construction : critère = achèvement du code sourcephase de transition : critère = délivrance du système à l’utilisateur
2004-2005. Version 1IS2 19
– UML se veut un langage simple, expressifévolutif, extensible, spécialisableindépendant du contexte d’utilisationindépendant du processus de conceptionorienté objetpré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èmeles diagrammes structurent le modèle : ils groupent les notions liées, et se relient entre eux à travers les objets
2004-2005. Version 1IS2 20
B3. liste des diagrammes (version 1.5)classés par catégories :
diagramme… …diagram– vues simples (statiques)
de cas d’utilisation use casede classes classde paquetages packagesd’objets objects
– de comportement (dynamiques)d’états – transitions statechartd’activité activity
… avec interactionde séquence sequencede collaboration collaboration
2004-2005. Version 1IS2 21
– d’implémentationde 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.
2004-2005. Version 1IS2 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é
2004-2005. Version 1IS2 23
B6. principales ressources• URL intéressants :
• www.uml.org : 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
2004-2005. Version 1IS2 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, www.popkin.com• ArgoUML, www.argouml.org (gnu) • Poseidon for UML, www.gentleware.com
(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.
2004-2005. Version 1IS2 25
C C –– diagrammes de casdiagrammes de casd’utilisationd’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
2004-2005. Version 1IS2 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.
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 28
C3. domaines d’applicationles 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
2004-2005. Version 1IS2 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)
2004-2005. Version 1IS2 30
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 33
C5. auto-testchoisir 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)
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 35
D D –– diagramme de classesdiagramme 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 passequand 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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…………...
2004-2005. Version 1IS2 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 : 0 ou 1 instance• n..m : de n à m instances• 0..* ou * : pas de limite (0 inclus)• 1 : exactement une instance
(valeur par défaut)• n : exactement n instances • 1..* : au moins une instance • n..* : n ou plus
2004-2005. Version 1IS2 39
D3. auto-test– reproduire le diagramme ci-dessous– nommer et commenter toutes les relations entre classes
2004-2005. Version 1IS2 40
D4. approfondissements• D41. composition - agrégation
2004-2005. Version 1IS2 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 partiesla composition est une relation forte, dans laquelle la, partie ne peut appartenir qu’à un seul tout, ne peut pas exister sans le toutle 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
2004-2005. Version 1IS2 42
• D42. accessibilité et portée
2004-2005. Version 1IS2 43
la classe est représentée par un rectangle à trois compartiments : le nom, les attributs, les opérationsles attributs et opérations peuvent être étiquetés selon leur accessibilité et leur portée :
+ public- private# protected
les membres « static » sont soulignésles 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é>
2004-2005. Version 1IS2 44
• D43. dépendances et contraintes
2004-2005. Version 1IS2 45
la dépendance est une relation entre deux classes dans laquelle un changement dans l’une d’elles peutentraîner un changement dans l’autreles 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 satisfaireles 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
2004-2005. Version 1IS2 46
• D44. interfaces et stéorotypes
2004-2005. Version 1IS2 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’interfacetraditionnellement le nom de l’interface commence par un I (majuscule)
2004-2005. Version 1IS2 48
la classe « Arrêt_Navette » a le stéréotype« emplacement » qui représente une extension par l’utilisateur d’UMLl’interface est également un stéréotype, fourni en standardle nom du stéréotype est inscrit entre double << >>, et fait penser aux espaces de nommage dans le code sous-jacentl’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 diagrammele diagramme de la page suivante et le diagramme précédent sont strictement équivalents
2004-2005. Version 1IS2 49
2004-2005. Version 1IS2 50
D5. auto-testexposé : chaque étudiant d’une école a un professeur référentcertains professeurs sont référents de plusieurs étudiants, mais certains ne le sont d’aucunlequel des diagrammes suivants représente cette relation étudiant – étudiantreproduisez 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)
2004-2005. Version 1IS2 51
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 53
E E –– diagrammes de diagrammes de paquetagespaquetages
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
2004-2005. Version 1IS2 54
2004-2005. Version 1IS2 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-testles 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èle2. Si un paquetage B dépend d’un paquetage A, tout changement dans A nécessitera un changement dans B
(réponses page suivante)
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 57
F F –– diagrammes d’objetsdiagrammes d’objetsF1. 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 60
2004-2005. Version 1IS2 61
F4. auto-testune 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)
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 63
G G –– diagrammes de séquencediagrammes de séquenceG1. 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 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)
2004-2005. Version 1IS2 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 »
2004-2005. Version 1IS2 69
H H –– diagrammes de diagrammes de collaborationcollaboration
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ôlesrespectifs, 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
2004-2005. Version 1IS2 70
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 72
H3. auto-testparmi les propositions suivantes, laquelle est correcte ?
1. les diagrammes de collaboration sont des modèles dynamiques2. les numéros de séquence dans les diagrammes de collaboration sont optionnels3. les diagrammes de collaboration ne montrent pas les itérations puisqu’elles sont des éléments de détail de bas niveau4. les diagrammes de collaboration ne peuvent pas montrer un oblet qui s’envoie un message à lui-même
(réponses page suivante)
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 74
I I –– diagrammes d’étatsdiagrammes d’états--transitionstransitionsI1. 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
2004-2005. Version 1IS2 75
2004-2005. Version 1IS2 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 »
2004-2005. Version 1IS2 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 threadsconcurrents conduisant à deux sous-états d’un état composite « Vente aux enchères »; ces 2 sous-états « Enchérir » et « Autorisation de crédit » sont eux-mêmes composites
– l’entrée dans « Vente aux enchères » nécessite une fourche, et une des sorties nécessite une jointure
2004-2005. Version 1IS2 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 »
2004-2005. Version 1IS2 79
I4. auto-testparmi les propositions suivantes, laquelle est correcte ?
1. toutes les actions d’un diagramme d’états-transitions sont rattachées à des transitions2. un événement lié à un objet peut avoir pour conséquence que cet objet ne change pas d’état3. une fois qu’un objet a quitté un état, il ne peut pas retourner à cet état4. 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)
2004-2005. Version 1IS2 80
• 1 non : les actions peuvent être écrites dans l’état comme sur l’état « Copier » ci-contre où les actionssuivantes 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 auto-transitions
• 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’états-transitions
2004-2005. Version 1IS2 81
J J –– diagrammes d’activitésdiagrammes d’activitésJ1. 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
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 83
(suite page suivante)
2004-2005. Version 1IS2 84
(début page précédente)
2004-2005. Version 1IS2 85
J3. auto-testsoit le diagramme d’activité suivant : quel est le pseudo-code qui lui correspond ?
1. if (OK) thendo Celsedo A and Bdo D2. do Cdo A and Bdo D
(réponses page suivante)
2004-2005. Version 1IS2 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
2004-2005. Version 1IS2 87
K K –– diagrammes de composants diagrammes de composants et de déploiementet 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 (softwareet hardware)
2004-2005. Version 1IS2 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)
2004-2005. Version 1IS2 89
2004-2005. Version 1IS2 90
K3. auto-testchoisir 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éploiement2. un rectangle arrondi, comme pour un état dans un diagramme d’états-transitions3. un rectangle en 3 dimensions4. un rectangle avec deux onglets en haut et à gauche
(réponses page suivante)
2004-2005. Version 1IS2 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
