3 Les diagrammes comportementaux Les diagrammes comportementaux sont focalisés sur la description de la partie dyna- mique du systéme & modéliser. Sept diagrammes sont proposés par UML 2 pour assuret cette description *# Le diagramme des cas d'utilisation (DC # le diagramme d # Ie diagramme d'activité (DAC), + le diagramme de séquence (DSE), * le diagramme de communication (DCO), + le diagramme global d'interaction (DGI), + le diagramme de temps (DTP) at-transition (machine ‘at, DET), 3.1 DIAGRAMME DES CAS D'UTILISATION (DCU) 3.1.1 Présentation générale et concepts de base Les cas d'utilisation ont été définis initialement par Ivar Jacobson en 1992 dans sa méthode OOSE. Les cas d'utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du systéme. Ils peuvent étre aussi utilisés ensuite comme moyen dorganisation du développement du logiciel, notamment pour la structuration et le déroulement des tests du logiciel.[2] crore a. tes dagrommes comportementaux Un cas d'utilisation permet de décrite Pnteraction entre les acteurs (utilisateurs du cas) et le systéme. La description de Pinteraction est réalisée suivant le point de vue de Futilisateur La représentation d'un cas d'utilisation met en jeu trois concepts 'acteur, le cas utilisation et Vinteraction entre Vacteur et le cas d'utilisation. Acteur Un acteur est un utilisateur type qui a toujours le méme comportement vis-A-vis dun cas utilisation. Ainsi les utiisateurs d'un systtme appartiennent une ou plusieurs classes d’acteurs selon les rdles qu'ls tiennent par rapport au systéme. ‘Une méme personne physique peut se comporter en autant dacteurs différents que le nombre de rales quelle joue vis-i-vis du systéme. Ainsi par exemple, V'administratcur d'un systéme de messagerie peut tre aussi utilisateur de cette méme messager. I sera considéré, en tant qu’acteur du systéme, dans le role d’administrateur dune part et dans celui dutilisateur d'autre part. Un acteur peut aussi étre un systéme exteme avec lequel le cas d'utilisation va interagir. Formalisme et exemple Un acteur peut se représenter symboliquement par un « bonhomme » et étre iden- Life par son nom. Il peut aussi Etre formalisé par une clase stéréotypée « acteur » (fig. 3.1). «acteur » Nom de Facteur Figure 3.1 — Représentations un acteur Cas d'utilisation et interaction Un eas d'utilisation correspond a un certain nombre d'actions que le systme devra cexécuter en réponse & un besoin d'un acteur. Un cas d'utilisation doit produire un résultat observable pour un ou plusieurs acteurs ou parties prenantes du systéme. Une interaction permet de décrre les échanges entre un acteur et un cas d'utili- sation.21 Deoe des un Oeup) [ea] Formalisme et exemple Un cas d'utilisation se représente par un ovale dans lequel figure son intitul Linteraction entre un acteur et un cas dlutilisation se représente comme une association, Elle peut comporter des multiplicités comme toute association entre classes (voir § 2.1 Diagramme de clase). Le formalisme de base de représentation d'un cas d'utilisation est dont figure 3.2, Interaction Nom du cas: utksaton Nom de Facteur Figure 3.2 — Formalsme de base de représentation d'un cas dutlsaton Chaque cas d'utilisation doit étre décrit sous forme textuelle afin de bien identi- fier les traitements & réaliser par le systeme en vue de la satisfaction du hesoin exprimé par Vacteur. 3.1.2 Représentation du diagramme des cas d'utilisation Tout systiéme peut étre décrit par un certain nombre de cas d'utilisation correspon- dant aux besoins exprimés par ensemble des utilisateurs. A chaque utilisateur, vu comme acteur, corresponda un certain nombre de cas d'utilisation du systme. ensemble de ces cas d'utilisation se représente sous forme d'un diagramme. Exemple La figure 3.3 montre un exemple d'un systéme de messagerie comportant quatre cas utilisation, Nous verrons, dans la suite de la présentation d'UML, qu'un cas utilisation peut avoir une ou plusieurs instances représentées par des scénarios. Chaque scénario fait Pobjet Iui-méme d'un diagramme de séquence ou de communication. En conclusion, nous dirons qu’un systeme est earactérisé par son comportement vis-a-vis de ses utilisateurs. Ce comportement se représente sous forme d'un en semble de cas d'utilisation qui correspond aux besoins des acteurs de ce systéme.[]} err. ts ogres copa Systime de messagerie| ‘Actour A Envol d'un message 1 | CChangement de droit ‘Administratour Figure 3.3 — Exemple d'un sysitme de messagerie comportant quatre cas d'utilisation 3.1.3 Relations entre cas d'utilisation Afin doptimiser la formalisation des besoins en ayant recours notamment Ala réuti- lisation de cas d'utilisation, trois relations peuvent étre décrites entre cas utilisation: une relation d'inelusion (« inel («extend ») et une relation de généralisation, »), une relation dextension Relation dinclusion Une relation d'inclusion d'un cas d'utilisation A par rapport a un cas d'utilisation B signifie qu'une instance de A contient le comportement décrit dans B. Formalisme et exemple La figure 3.4 donne le formalisme et un exemple d'une relation utilisation. ‘inclusion entre cas21 Beye dss stn 0eup) [es] ! - Créaton «include » sunpmd sons man nny 0 ~ Gestonnate nema Figure 3.4 — Formalsme et exemple dea relation dindusion entre cas dtilistion Relation dextension Une relation d’extension dun cas utilisation A par un cas d'utilisation B signiie quune instance de A peut étre étendue par le comportement décrit dans B. Deux caractéristiques sont A noter * le caractére optionnel de l'extension dans le déroulement du cas d'utilisation standard (A) + lamention explicite du point d’extension dans le cas d'utilisation standard. Formalisme et exemple La figure 3.5 donne un exemple d'une relation d'extension entre cas d'utilisation, ine note peut étre ajoutée A la représentation du cas d'utilisation permettant expliciter la condition. Relation de généralisation Une relation de g au principe de la spécialisation-généralisation déja présentée pour les classes. inie conformément ralisation de cas d'utilisation peut étre d Formalis eet exemple La figure 3.6 donne un exemple d'une relation de généralisation de cas dutilisation.[|] cherie. ts ogres copa conaon: — DN 2] ip ge ie hen Figure 3.5 — Formalsme et exemple dune relation dextension centze cas dutiisation Figure 3.6 — Exemple d'une relation de généralisation de cas d'utilisation 3.1.4 Description textuelle d’un cas d'utilisation A chaque cas d'utilisation doit étre associée une description textuelle des interac- tions entre lacteur et le systéme et les actions que le systtme doit réaliser en vue de produiee les résultats attendus par les acteurs. UML ne propose pas de présentation type de cette description textuelle. Cepen- dant, les travaux menés par Alistair Cockburn [Cockburn2001] sur ce sujet const tuent une référence en la matigre et tout naturellement nous reprenons ii 'essentiel de cette présentation.21 Deyoe des cs usin 0cup) [er] La description textuelle d'un cas d'utilisation est articulée en six points * Objectif ~ Décrire succinctement le contexte et les résultats attendus du cas utilisation. * Acteurs concemés — Le ou les acteurs concemés par le eas doivent étre iden: tifiésen précisant globalement leur rl. * Pré conditions — Si certaines conditions particulidres sont requises avant Vexécution du cas, elles sont & exprimer a ce niveau. * Post conditions ~ Par symétrie, si certaines conditions particulitres doivent tre réunies apriés Vexécution du cas, elles sont & exprimer & ce niveau. Pour notre part, par souci de simplification nous n’avons pas traité ce point dans les cexercices et études de cas présentés. * Scénario nominal ~ II s'agit la du scénario principal qui doit se dérouler sans incident et qui permet d'aboutir au résultat souhaité. * Scénarios alternatifs ~ Les autres scénarios, secondaires ou correspondant la ‘olution d'anomalies, sont & décrire & ce niveau. Le lien avec le scénario principal se fait l'aide d'une numérotation hiérarchisée (I.La, 1.1b...) rappe- lant le numéro de l'action concernée. 3.1.5 Exercices Exercce 1 Enoneé Une biblioth@que universitaire souhaite automatiser sa gestion. Cette bibliothéque est gérée par un gestionnaire chargé des inscriptions et des relances des lecteurs quand ceux-ci n’ont pas rendu leurs ouvrages au-dela du délai autorisé. Les biblio- thécaires sont chargés de gérer les emprunts et la restitution des ouvrages ainsi que acquisition de nouveaux ouvrages. existe trois catégories d'abonné. Tout d'abord les étudiants qui doivent seule- ment s'acquitter d'une somme forfataire pour une année afin d'avoir droit & tous les services de la bibliothéque. L'accés 8 la biblioth@que est libre pour tous les ensei- nants. Enfin, il est possible d’autoriser des étudiants d'une autre université & s'ins- rire exceptionnellement comme abonné moyennant le versement d'une cotisation, Le nombre d'abonné exteme est limité chaque année A environ 10 % des inscrits. Un nouveau service de consultation du catalogue général des ouvrages doit étre mis en place. Les ouvrages, souvent acquis en plusieurs exemplaires, sont rangés dans des rayons de la biblioth®que. Chaque exemplaire est repéré par une référence gérée dans le catalogue et le code du rayon ot il est rangé. ‘Chaque abonné ne peut emprunter plus de trois ouvrages. Le délai demprunt d'un ouvrage est de trois semaines, il peut cependant étre prolongé exceptionnelle- ment cing semaines, Test demandé d’élaborer le diagramme des cas d'utilisation (DCU).