Vous êtes sur la page 1sur 45

Diagrammes de cas dutilisation

Introduction
Bien souvent, la matrise douvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation qui permettent de recueillir, danalyser et dorganiser les besoins, et de recenser les grandes fonctionnalits dun systme. Il sagit donc de la premire tape UML danalyse dun systme. Un diagramme de cas dutilisation capture le comportement dun systme, dun sous-systme, dune classe ou dun composant tel quun utilisateur extrieur le voit. Il scinde la fonctionnalit du systme en units cohrentes, les cas dutilisation, ayant un sens pour les acteurs. Les cas dutilisation permettent dexprimer le besoin des utilisateurs dun systme, ils sont donc une vision oriente utilisateur de ce besoin au contraire dune vision informatique. Il ne faut pas ngliger cette premire tape pour produire un logiciel conforme aux attentes des utilisateurs. Pour laborer les cas dutilisation, il faut se fonder sur des entretiens avec les utilisateurs.

lments des diagrammes de cas dutilisation


2.2.1 Acteur

Un acteur est lidalisation dun rle jou par une personne externe, un processus ou une chose qui interagit avec un systme. Il se reprsente par un petit bonhomme (figure 2.1) avec son nom (i.e. son rle) inscrit dessous.

Figure 2.1: Exemple de reprsentation dun acteur

Il est galement possible de reprsenter un acteur sous la forme dun

Figure 2.2: Exemple de reprsentation dun acteur sous la forme dun classeur

2.2.2 Cas dutilisation

Un cas dutilisation est une unit cohrente reprsentant une fonctionnalit visible de lextrieur. Il ralise un service de bout en bout, avec un dclenchement, un droulement et une fin, pour lacteur qui linitie. Un cas dutilisation modlise donc un service rendu par le systme, sans imposer le mode de ralisation de ce service. Un cas dutilisation se reprsente par une ellipse (figure 2.3) contenant le nom du cas (un verbe linfinitif), et optionnellement, au-dessus du nom, un strotype (cf. section 2.4.4).

Figure 2.3: Exemple de reprsentation dun cas dutilisation

Dans le cas o lon dsire prsenter les attributs ou les oprations du cas dutilisation, il est prfrable de le reprsenter sous la forme dun classeur strotyp << use case >> (figure 2.4). Nous reviendrons sur les notions dattributs ou dopration lorsque nous aborderons les diagrammes de classes et dobjets (section 3).

Figure 2.4: Exemple de reprsentation dun cas dutilisation sous la forme dun classeur

Reprsentation dun diagramme de cas dutilisation

Figure 2.5: Exemple simplifi de diagramme de cas dutilisation modlisant une borne daccs une banque.

Comme le montre la figure 2.5, la frontire du systme est reprsente par un cadre. Le nom du systme figure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas dutilisation lintrieur.

Relations dans les diagrammes de cas dutilisation


2.3.1 Relations entre acteurs et cas dutilisation Relation dassociation

Figure 2.6: Diagramme de cas dutilisation reprsentant un logiciel de partage de fichiers

Une relation dassociation est chemin de communication entre un acteur et un cas dutilisation et est reprsent par un trait continu (cf. figure 2.5 ou 2.6).
Multiplicit

Lorsquun acteur peut interagir plusieur fois avec un cas dutilisation, il est possible dajouter une multiplicit sur lassociation du ct du cas dutilisation. Le symbole * signifie plusieurs (figure 2.6), exactement n scrit tout simplement n, n..m signifie entre n et m, etc. Prciser une multiplicit sur une relation nimplique pas ncessairement que les cas sont utiliss en mme temps. La notion de multiplicit nest pas propre au diagramme de cas dutilisation. Nous en reparlerons dans le chapitre consacr au diagramme de classes section 3.3.4.
Acteurs principaux et secondaires

Un acteur est qualifi de principal pour un cas dutilisation lorsque ce cas rend service cet acteur. Les autres acteurs sont alors qualifis de secondaires. Un cas dutilisation a au plus un acteur principal. Un acteur principal obtient un rsultat observable du systme tandis quun acteur secondaire est sollicit pour des informations complmentaires. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations. Le strotype << primary >> vient orner lassociation reliant un cas dutilisation son acteur principal, le strotype << secondary >> est utilis pour les acteurs secondaires (figure 2.6).
3

Cas dutilisation interne

Quand un cas nest pas directement reli un acteur, il est qualifi de cas dutilisation interne.
Relations entre cas dutilisation

Figure 2.7: Exemple de diagramme de cas dutilisation

Types et reprsentations

Il existe principalement deux types de relations :


les dpendances strotypes, qui sont explicites par un strotype (les plus utiliss sont linclusion et lextension), et la gnralisation/spcialisation.

Une dpendance se reprsente par une flche avec un trait pointill (figure 2.7). Si le cas A inclut ou tend le cas B, la flche est dirige de A vers B.
4

Le symbole utilis pour la gnralisation est un flche avec un trait pleins dont la pointe est un triangle ferm dsignant le cas le plus gnral (figure 2.7).
Relation dinclusion

Un cas A inclut un cas B si le comportement dcrit par le cas A inclut le comportement du cas B : le cas A dpend de B. Lorsque A est sollicit, B lest obligatoirement, comme une partie de A. Cette dpendance est symbolise par le strotype << include >> (figure 2.7). Par exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentification avec un identifiant et un mot de passe (figure 2.7). Les inclusions permettent essentiellement de factoriser une partie de la description dun cas dutilisation qui serait commune dautres cas dutilisation (cf. le cas Sauthentifier de la figure 2.7). Les inclusions permettent galement de dcomposer un cas complexe en sous-cas plus simples (figure 2.8). Cependant, il ne faut surtout pas abuser de ce type de dcomposition : il faut viter de raliser du dcoupage fonctionnel dun cas dutilisation en plusieurs sous-cas dutilisation pour ne pas retomber dans le travers de la dcomposition fonctionnelle. Attention galement au fait que, les cas dutilisation ne senchanent pas, puisquil ny a aucune reprsentation temporelle dans un diagramme de cas dutilisation.

Figure 2.8: Relations entre cas pour dcomposer un cas complexe

Relation dextension

La relation dextension est probablement la plus utile car elle a une smantique qui a un sens du point de vue mtier au contraire des deux autres qui sont plus des artifices dinformaticiens. On dit quun cas dutilisation A tend un cas dutilisation B lorsque le cas dutilisation A peut tre appel au cours de lexcution du cas dutilisation B. Excuter B peut ventuellement
5

entraner lexcution de A : contrairement linclusion, lextension est optionnelle. Cette dpendance est symbolise par le strotype << extend >> (figure 2.7). Lextension peut intervenir un point prcis du cas tendu. Ce point sappelle le point dextension. Il porte un nom, qui figure dans un compartiment du cas tendu sous la rubrique point dextension, et est ventuellement associ une contrainte indiquant le moment o lextension intervient. Une extension est souvent soumise condition. Graphiquement, la condition est exprime sous la forme dune note. La figure 2.7 prsente lexemple dune banque o la vrification du solde du compte nintervient que si la demande de retrait dpasse 20 euros.
Relation de gnralisation

Un cas A est une gnralisation dun cas B si B est un cas particulier de A. Dans la figure 2.7, la consultation dun compte via Internet est un cas particulier de la consultation. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept dhritage dans les langages orients objet.
2.3.3 Relations entre acteurs

La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B. Dans ce cas, tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai. Le symbole utilis pour la gnralisation entre acteurs est une flche avec un trait plein dont la pointe est un triangle ferm dsignant lacteur le plus gnral (comme nous lavons dj vu pour la relation de gnralisation entre cas dutilisation). Par exemple, la figure 2.9 montre que le directeur des ventes est un prpos aux commandes avec un pouvoir supplmentaire : en plus de pouvoir passer et suivre une commande, il peut grer le stock. Par contre, le prpos aux commandes ne peut pas grer le stock.

Figure 2.9: Relations entre acteurs

Notions gnrales du langage UML


Les lments du langage UML que nous abordons ici ne sont pas spcifiques au diagramme de cas dutilisation mais sont gnraux. Nous avons dj utilis certains de ces lments dans ce chapitre et nous utiliserons les autres dans les chapitres qui suivent, notamment dans le chapitre sur les diagrammes de classes (section 3).
Paquetage

Figure 2.10: Reprsentations dun paquetage

Un paquetage est un regroupement dlments de modle et de diagrammes. Il permet ainsi dorganiser des lments de modlisation en groupes. Il peut contenir tout type dlment de modle : des classes, des cas dutilisation, des interfaces, des diagrammes, et mme des paquetages imbriqus (dcomposition hirarchique). Un paquetage se reprsente comme un dossier avec son nom inscrit dedans (figure 2.10, diagramme de gauche). Il est possible de reprsenter explicitement le contenu dun paquetage. Dans ce cas, le nom du paquetage est plac dans longlet (figure 2.10, diagramme de droite). Les lments contenus dans un paquetage doivent reprsenter un ensemble fortement cohrent et sont gnralement de mme nature et de mme niveau smantique. Tout lment nappartient qu un seul paquetage. Les paquetage constituent un mcanisme de gestion important des problmes de grande taille. Ils permettent dviter les grands modles plats et de cloisonner des lments constitutifs dun systme voluant des rythmes diffrents ou dvelopps par des quipes diffrentes. Il existe un paquetage racine unique, ventuellement anonyme, qui contient la totalit des modles dun systme.

Espace de noms

Les espaces de noms sont des paquetages, des classeurs, etc. On peut dterminer un lment nomm de faon unique par son nom qualifi, qui est constitu de la srie des noms des paquetages ou des autres espaces de noms depuis la racine jusqu llment en question. Dans un nom qualifi, chaque espace de nom est spar par deux doubles points (::). Par exemple, si un paquetage B est inclus dans un paquetage A et contient une classe X, il faut crire A::B::X pour pouvoir utiliser la classe X en dehors du contexte du paquetage B.
Classeur

Les paquetages et les relations de gnralisation ne peuvent avoir dinstance. Dune manire gnrale, les lments de modlisation pouvant en avoir sont reprsents dans des classeurs1. Plus important encore, un classeur est un lment de modle qui dcrit une unit structurelle ou comportementale. Un classeur modlise un concept discret qui dcrit un lment (i.e. objet) dot dune identit (i.e. un nom), dune structure ou dun tat (i.e. des attributs), dun comportement (i.e. des oprations), de relations et dune structure interne facultative. Il peut participer des relations dassociation, de gnralisation, de dpendance et de contrainte. On le dclare dans un espace de noms, comme un paquetage ou une autre classe. Un classeur se reprsente par un rectangle, en traits pleins, contenant ventuellement des compartiments. Les acteurs et les cas dutilisation sont des classeurs. Tout au long de ce cours, nous retrouverons le terme de classeur car cette notion englobe aussi les classes, les interfaces, les signaux, les nuds, les composants, les sous-systmes, etc. Le type de classeur le plus important tant, bien videmment, la classe (cf. section 3).
Strotype

Un strotype est une annotation sappliquant sur un lment de modle. Il na pas de dfinition formelle, mais permet de mieux caractriser des varits dun mme concept. Il permet donc dadapter le langage des situations particulires. Il est reprsent par une chanes de caractres entre guillemets (<< >>) dans, ou proximit du symbole de llment de modle de base. Par exemple, la figure 2.4 reprsente un cas dutilisation par un rectangle. UML utilise aussi les rectangles pour reprsenter les classes (cf. section 3). La notation nest cependant pas ambigu grce la prsence du strotype << use case >>.
Note

Figure 2.11: Exemple dutilisation dune note pour prciser que le solde dun compte doit toujours tre positif.

Une note contient une information textuelle comme un commentaire, un corps de mthode ou une contrainte. Graphiquement, elle est reprsente par un rectangle dont langle suprieur droit est pli. Le texte contenu dans le rectangle nest pas contraint par UML. Une note nindique pas explicitement le type dlment quelle contient, toute lintelligibilit dune note doit tre contenu dans le texte mme. On peut relier une note llment quelle dcrit grce une ligne en pointills. Si elle dcrit plusieurs lments, on dessine une ligne vers chacun dentre eux. Lexemple de la figure 2.11 montre une note exprimant une contrainte (cf. section 4.1) sur un attribut.

Certains lments, comme les associations, peuvent avoir des instances bien quils ne soient pas reprsents dans des classeurs.

Modlisation des besoins avec UML


Comment identifier les acteurs ?

UML nemploie pas le terme dutilisateur mais dacteur. Les acteurs dun systme sont les entits externes ce systme qui interagissent (saisie de donnes, rception dinformation, ) avec lui. Les acteurs sont donc lextrieur du systme et dialoguent avec lui. Ces acteurs permettent de cerner linterface que le systme va devoir offrir son environnement. Oublier des acteurs ou en identifier de faux conduit donc ncessairement se tromper sur linterface et donc la dfinition du systme produire. Il faut faire attention ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) dun systme. Dune part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systmes informatiques ou hardware qui vont communiquer avec le systme. Dautre part parce que un acteur englobe tout une classe dutilisateur. Ainsi, plusieurs utilisateurs peuvent avoir le mme rle, et donc correspondre un mme acteur, et une mme personne physique peut jouer des rles diffrents vis--vis du systme, et donc correspondre plusieurs acteurs. Chaque acteur doit tre nomm. Ce nom doit reflter sont rle car un acteur reprsente un ensemble cohrent de rles jous vis--vis du systme. Pour trouver les acteurs dun systme, il faut identifier quels sont les diffrents rles que vont devoir jouer ses utilisateurs (ex : responsable clientle, responsable dagence, administrateur, approbateur, ). Il faut galement sintresser aux autres systmes avec lesquels le systme va devoir communiquer comme :

les priphriques manipuls par le systme (imprimantes, hardware dun distributeur de billet, ) ;
9

des logiciels dj disponibles intgrer dans le projet ; des systmes informatiques externes au systme mais qui interagissent avec lui, etc.

Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce qui est lextrieur et qui interagit avec le systme est un acteur, tout ce qui est lintrieur est une fonctionnalit raliser. Vrifiez que les acteurs communiquent bien directement avec le systme par mission ou rception de messages. Une erreur frquente consiste rpertorier en tant quacteur des entits externes qui ninteragissent pas directement avec le systme, mais uniquement par le biais dun des vritables acteurs. Par exemple, lhtesse de caisse dun magasin de grande distribution est un acteur pour la caisse enregistreuse, par contre, les clients du magasins ne correspondent pas un acteur car ils ninteragissent pas directement avec la caisse.
Comment recenser les cas dutilisation ?

Lensemble des cas dutilisation doit dcrire exhaustivement les exigences fonctionnelles du systme. Chaque cas dutilisation correspond donc une fonction mtier du systme, selon le point de vue dun de ses acteurs. Aussi, pour identifier les cas dutilisation, il faut se placer du point de vue de chaque acteur et dterminer comment et surtout pourquoi il se sert du systme. Il faut viter les redondances et limiter le nombre de cas en se situant un bon niveau dabstraction. Trouver le bon niveau de dtail pour les cas dutilisation est un problme difficile qui ncessite de lexprience. Nommez les cas dutilisation avec un verbe linfinitif suivi dun complment en vous plaant du point de vue de lacteur et non pas de celui du systme. Par exemple, un distributeur de billets aura probablement un cas dutilisation Retirer de largent et non pas Distribuer de largent. De par la nature fonctionnelle, et non objet, des cas dutilisation, et en raison de la difficult de trouver le bon niveau de dtail, il faut tre trs vigilant pour ne pas retomber dans une dcomposition fonctionnelle descendante hirarchique. Un nombre trop important de cas dutilisation est en gnral le symptme de ce type derreur. Dans tous les cas, il faut bien garder lesprit quil ny a pas de notion temporelle dans un diagramme de cas dutilisation.
Description textuelle des cas dutilisation

Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation. Bien que de nombreux diagrammes dUML permettent de dcrire un cas, il est recommand de rdiger une description textuelle car cest une forme souple qui convient dans bien des situations. Une description textuelle couramment utilise se compose de trois parties.
1. La premire partie permet didentifier le cas, elle doit contenir les informations qui suivent. Nom : Utiliser une tournure linfinitif (ex : Rceptionner un colis).
10

Objectif : Une description rsume permettant de comprendre lintention principale du cas dutilisation. Cette partie est souvent renseigne au dbut du projet dans la phase de dcouverte des cas dutilisation. Acteurs principaux : Ceux qui vont raliser le cas dutilisation (la relation avec le cas dutilisation est illustre par le trait liant le cas dutilisation et lacteur dans un diagramme de cas dutilisation) Acteurs secondaires : Ceux qui ne font que recevoir des informations lissue de la ralisation du cas dutilisation Dates : Les dates de crations et de mise jour de la description courante. Responsable : Le nom des responsables. Version : Le numro de version. 2. La deuxime partie contient la description du fonctionnement du cas sous la forme dune squence de messages changs entre les acteurs et le systme. Elle contient toujours une squence nominale qui dcrit de droulement normal du cas. la squence nominale sajoutent frquemment des squences alternatives (des embranchement dans la squence nominale) et des squences dexceptions (qui interviennent quand une erreur se produit). Les prconditions : elles dcrivent dans quel tat doit tre le systme (lapplication) avant que ce cas dutilisation puisse tre dclench. Des scnarii : Ces scnarii sont dcrits sous la forme dchanges dvnements entre lacteur et le systme. On distingue le scnario nominal, qui se droule quand il ny a pas derreur, des scnarii alternatifs qui sont les variantes du scnario nominal et enfin les scnarii dexception qui dcrivent les cas derreurs. Des postconditions : Elle dcrivent ltat du systme lissue des diffrents scnarii. 3. La troisime partie de la description dun cas dutilisation est une rubrique optionnelle. Elle contient gnralement des spcifications non fonctionnelles (spcifications techniques, ). Elle peut ventuellement contenir une description des besoins en termes dinterface graphique.

11

2.5.4 Remarques Concernant les relations dans les cas dutilisation

Il est important de noter que lutilisation des relations nest pas primordiale dans la rdaction des cas dutilisation et donc dans lexpression du besoin. Ces relations peuvent tre utiles dans certains cas mais une trop forte focalisation sur leur usage conduit souvent une perte de temps ou un usage fauss, pour une valeur ajoute, au final, relativement faible.
Concernant les cas dutilisation

Unanimement reconnus comme cantonns lingnierie des besoins, les diagrammes de cas dutilisation ne peuvent tre qualifis de modlisation proprement parler. Dailleur, de nombreux lments descriptifs sont en langage naturel. De plus, ils ne correspondent pas stricto sensu une approche objet. En effet, capturer les besoins, les dcouvrir, les rfuter, les consolider, etc., correspond plus une analyse fonctionnelle classique.
Les Use case Realization

UML ne mentionne que le fait que la ralisation dun cas dutilisation est dcrit par une suite de collaborations entre lments de modlisation mais ne parle par de llment de modlisation use case realization. Les use case realization ne sont pas un formalisme dUML mais du RUP (Rational Unified Process). Aprs avoir rdig les cas dutilisation, il faut identifier des objets, des classes, des donnes et des traitements qui vont permettre au systme de supporter ces cas dutilisation. Pour documenter la manire dont sont mis en uvre les cas dutilisation du systme, on peut utiliser le mcanisme des use case realization. Ils permettent de regrouper un diagramme de classes et des diagrammes dinteraction. On retrouvera dans le diagramme de classes les classes qui mettent en uvre le cas dutilisation associ au use case realization. On retrouvera dans les diffrents diagrammes dinteraction une documentation des diffrents vnements changs entre les objets afin de raliser les diffrents scnarii dcrit dans le cas dutilisation. Au final on aura un use case realization par cas dutilisation et dans chaque use case realization on aura autant de diagrammes dinteraction que ncessaire pour illustrer les scnarii dcrits dans le cas dutilisation (scnario nominal, scnarii alternatifs et scnarii dexception). Les use case realization permettent donc, dans la pratique, dapporter un lment de rponse la question : Comment structurer mon modle UML ?

12

Diagramme de classes (Class Diagram)

Introduction
Le diagramme de classes est considr comme le plus important de la modlisation oriente objet, il est le seul obligatoire lors dune telle modlisation. Alors que le diagramme de cas dutilisation montre un systme du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une reprsentation abstraite des objets du systme qui vont interagir ensemble pour raliser les cas dutilisation. Il est important de noter quun mme objet peut trs bien intervenir dans la ralisation de plusieurs cas dutilisation. Les cas dutilisation ne ralisent donc pas une partition 1 des classes du diagramme de classes. Un diagramme de classes nest donc pas adapt (sauf cas particulier) pour dtailler, dcomposer, ou illustrer la ralisation dun cas dutilisation particulier. Il sagit dune vue statique car on ne tient pas compte du facteur temporel dans le comportement du systme. Le diagramme de classes modlise les conceps du domaine dapplication ainsi que les concepts internes crs de toutes pices dans le cadre de limplmentation dune application. Chaque langage de Programmation Orient Objets donne un moyen spcifique dimplmenter le paradigme objet (pointeurs ou pas, hritage multiple ou pas, etc.), mais le diagramme de classes permet de modliser les classes du systme et leurs relations indpendamment dun langage de programmation particulier. Les principaux lments de cette vue statique sont les classes et leurs relations : association, gnralisation et plusieurs types de dpendances, telles que la ralisation et lutilisation. Une partition dun ensemble est un ensemble de parties non vides de cet ensemble, deux deux disjointes et dont la runion est gale lensemble.

13

Les classes
Notions de classe et dinstance de classe

Une instance est une concrtisation dun concept abstrait. Par exemple :

la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait Automobile ; lamiti qui lie Jean et Marie est une instance du concept abstrait Amiti ;

Une classe est un concept abstrait reprsentant des lments varis comme :

des lments concrets (ex : des avions), des lments abstraits (ex : des commandes de marchandises ou services), des composants dune application (ex : les boutons des botes de dialogue), des structures informatiques (ex : des tables de hachage), des lments comportementaux (ex : des tches), etc.

Tout systme orient objet est organis autour des classes. Une classe est la description formelle dun ensemble dobjets ayant une smantique et des caractristiques communes. Un objet est une instance dune classe. Cest une entit discrte dote dune identit, dun tat et dun comportement que lon peut invoquer. Les objets sont des lments individuels dun systme en cours dexcution. Par exemple, si lon considre que Homme (au sens tre humain) est un concept abstrait, on peut dire que la personne Marie-Ccile est une instance de Homme. Si Homme tait une classe, Marie-Ccile en serait une instance : un objet.
Caractristiques dune classe

Une classe dfinit un jeu dobjets dots de caractristiques communes. Les caractristiques dun objet permettent de spcifier son tat et son comportement. Nous avons dit que les caractristiques dun objet taient soit des attributs, soit des oprations. Ce nest pas exact dans un diagramme de classe car les terminaisons dassociations sont des proprits qui peuvent faire partie des caractristiques dun objet au mme titre que les attributs et les oprations.
tat dun objet : Ce sont les attributs et gnralement les terminaisons dassociations, tous deux runis sous le terme de proprits structurelles, ou tout simplement proprits, qui dcrivent ltat dun objet. Les attributs sont utiliss pour des valeurs de donnes pures, dpourvues didentit, telles que les nombres et les chanes de caractres. Les associations sont utilises pour connecter les classes du diagramme de classe ; dans ce cas, la terminaison de lassociation (du ct de la classe cible) est gnralement une proprit de la classe de base.

Les proprits dcrites par les attributs prennent des valeurs lorsque la classe est instancie. Linstance dune association est appele un lien.
14

Comportement dun objet : Les oprations dcrivent les lments individuels dun comportement que lon peut invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entre et modifier les attributs ou produire des rsultats.

Une opration est la spcification (i.e. dclaration) dune mthode. Limplmentation (i.e. dfinition) dune mthode est galement appele mthode. Il y a donc une ambigut sur le terme mthode. Les attributs, les terminaisons dassociation et les mthodes constituent donc les caractristiques dune classe (et de ses instances).
Reprsentation graphique

Figure 3.1: Reprsentation UML dune classe

Une classe est un classeur. Elle est reprsente par un rectangle divis en trois cinq compartiments Le premier indique le nom de la classe, le deuxime ses attributs et le troisime ses oprations. Un compartiment des responsabilits peut tre ajout pour numrer lensemble de tches devant tre assures par la classe mais pour lesquelles on ne dispose pas encore assez dinformations. Un compartiment des exceptions peut galement tre ajout pour numrer les situations exceptionnelles devant tre gres par la classe.
Encapsulation, visibilit, interface

Figure 3.2: Bonnes pratiques concernant la manipulation des attributs.

15

Nous avons dj abord cette problmatique section 1.3.4. Lencapsulation est un mcanisme consistant rassembler les donnes et les mthodes au sein dune structure en cachant limplmentation de lobjet, cest--dire en empchant laccs aux donnes par un autre moyen que les services proposs. Ces services accessibles (offerts) aux utilisateurs de lobjet dfinissent ce que lon appel linterface de lobjet (sa vue externe). Lencapsulation permet donc de garantir lintgrit des donnes contenues dans lobjet. Lencapsulation permet de dfinir des niveaux de visibilit des lments dun conteneur. La visibilit dclare la possibilit pour un lment de modlisation de rfrencer un lment qui se trouve dans un espace de noms diffrents de celui de llment qui tablit la rfrence. Elle fait partie de la relation entre un lment et le conteneur qui lhberge, ce dernier pouvant tre un paquetage, une classe ou un autre espace de noms. Il existe quatre visibilits prdfinies.
Public ou + : tout lment qui peut voir le conteneur peut galement voir llment indiqu. Protected ou # : Seul un lment situ dans le conteneur ou un de ses descendants peut voir llment indiqu. Private ou - : Seul un lment situ dans le conteneur peut voir llment. Package ou ou rien :

Seul un lment dclar dans le mme paquetage peut voir llment.

Par ailleurs, UML 2.0 donne la possibilit dutiliser nimporte quel langage de programmation pour la spcification de la visibilit. Dans une classe, le marqueur de visibilit se situe au niveau de chacune de ses caractristiques (attributs, terminaisons dassociation et opration). Il permet dindiquer si une autre classe peut y accder. Dans un paquetage, le marqueur de visibilit se situe sur des lments contenus directement dans le paquetage, comme les classes, les paquetages imbriqus, etc. Il indique si un autre paquetage susceptible daccder au premier paquetage peut voir les lments. Dans la pratique, lorsque des attributs doivent tre accessibles de lextrieur, il est prfrable que cet accs ne soit pas direct mais se fasse par lintermdiaire doprations
Nom dune classe

Le nom de la classe doit voquer le concept dcrit par la classe. Il commence par une majuscule. On peut ajouter des informations subsidiaires comme le nom de lauteur de la modlisation, la date, etc. Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef abstract. La syntaxe de base de la dclaration dun nom dune classe est la suivante :
16

[ <Nom_du_paquetage_1>::...::<Nom_du_paquetage_N> ] <Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ... } ]

Mta-langage des syntaxes

Nous aurons rgulirement recours ce mta-langage pour dcrire des syntaxes de dclaration. Ce mta-langage contient certains mta-caractre :
[ ]:

les crochets indiquent que ce qui est lintrieur est optionnel ;


< >:

les signes infrieur et suprieur indiquent que ce qui est lintrieur est plus ou moins libre ; par exemple, la syntaxe de dclaration dune variable comme compteur : int est <nom_variable> : <type> ;
:

les cotes sont utiles quand on veut utiliser un mta-caractre comme un caractre ; par exemple, pour dsigner un crochet ([) il faut crire [ car [ est un mta-caractre ayant une signification spciale ;
... :

permet de dsigner une suite de squence de longueur non dfinie, le contexte permettant de comprendre de quelle suite il sagit. Les attributs Attributs de la classe

Les attributs dfinissent des informations quune classe ou un objet doivent connatre. Ils reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations est dfinie par un nom, un type de donnes, une visibilit et peut tre initialis. Le nom de lattribut doit tre unique dans la classe. La syntaxe de la dclaration dun attribut est la suivante :
<visibilit> [/] <nom_attribut> : <type> [ '['<multiplicit>']' [{<contrainte>}] ] [ = <valeur_par_dfaut> ]

Le type de lattribut (<type>) peut tre un nom de classe, un nom dinterface ou un type de donn prdfini. La multiplicit (<multiplicit>) dun attribut prcise le nombre de valeurs que lattribut peut contenir. Lorsquune multiplicit suprieure 1 est prcise, il est possible dajouter une contrainte ({<contrainte>}) pour prciser si les valeurs sont ordonnes ({ordered}) ou pas ({list}).
Attributs de classe

Par dfaut, chaque instance dune classe possde sa propre copie des attributs de la classe. Les valeurs des attributs peuvent donc diffrer dun objet un autre. Cependant, il est parfois ncessaire de dfinir un attribut de classe (static en Java ou en C++) qui garde une valeur
17

unique et partage par toutes les instances de la classe. Les instances ont accs cet attribut mais nen possdent pas une copie. Un attribut de classe nest donc pas une proprit dune instance mais une proprit de la classe et laccs cet attribut ne ncessite pas lexistence dune instance. Graphiquement, un attribut de classe est soulign.
Attributs drivs

Les attributs drivs peuvent tre calculs partir dautres attributs et de formules de calcul. Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu ce que vous puissiez dterminer les rgles lui appliquer. Les attributs drivs sont symboliss par lajout dun / devant leur nom.
Les mthodes Mthode de la classe

Dans une classe, une opration (mme nom et mme types de paramtres) doit tre unique. Quand le nom dune opration apparat plusieurs fois avec des paramtres diffrents, on dit que lopration est surcharge. En revanche, il est impossible que deux oprations ne se distinguent que par leur valeur retourne. La dclaration dune opration contient les types des paramtres et le type de la valeur de retour, sa syntaxe est la suivante :
<visibilit> <nom_mthode> ([<paramtre_1>, ... , <paramtre_N>]) : [<type_renvoy>] [{<proprits>}]

La syntaxe de dfinition dun paramtre (<paramtre>) est la suivante :


[<direction>] <nom_paramtre>:<type> ['['<multiplicit>']'] [=<valeur_par_dfaut>]

La direction peut prendre lune des valeurs suivante :


in : Paramtre dentre pass par valeur. Les modifications du paramtre ne sont pas disponibles pour lappelant. Cest le comportement par dfaut. out : Paramtre de sortie uniquement. Il ny a pas de valeur dentre et la valeur finale est disponible pour lappelant. inout : Paramtre dentre/sortie. La valeur finale est disponible pour lappelant.

Le type du paramtre (<type>) peut tre un nom de classe, un nom dinterface ou un type de donn prdfini.
18

Les proprits (<proprits>) correspondent des contraintes ou des informations complmentaires comme les exceptions, les prconditions, les postconditions ou encore lindication quune mthode est abstraite (mot-clef abstract), etc.
Mthode de classe

Comme pour les attributs de classe, il est possible de dclarer des mthodes de classe. Une mthode de classe ne peut manipuler que des attributs de classe et ses propres paramtres. Cette mthode na pas accs aux attributs de la classe (i.e. des instances de la classe). Laccs une mthode de classe ne ncessite pas lexistence dune instance de cette classe. Graphiquement, une mthode de classe est souligne.
Mthodes et classes abstraites

Une mthode est dite abstraite lorsquon connat son entte mais pas la manire dont elle peut tre ralise (i.e. on connat sa dclaration mais pas sa dfinition). Une classe est dite abstraite lorsquelle dfinit au moins une mthode abstraite ou lorsquune classe parent (cf. section 3.3.9) contient une mthode abstraite non encore ralise. On ne peut instancier une classe abstraite : elle est voue se spcialiser (cf. section 3.3.9). Une classe abstraite peut trs bien contenir des mthodes concrtes. Une classe abstraite pure ne comporte que des mthodes abstraites. En programmation oriente objet, une telle classe est appele une interface. Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef abstract derrire son nom.
Classe active

Une classe est passive par dfaut, elle sauvegarde les donnes et offre des services aux autres. Une classe active initie et contrle le flux dactivits. Graphiquement, une classe active est reprsente comme une classe standard dont les lignes verticales du cadre, sur les cts droit et gauche, sont doubles.
Il faut ici aborder un petit problme de terminologie autour du mot proprit. En effet, dans la littrature, le mot proprit est parfois utilis pour dsigner toutes les caractristiques dune classe (i.e. les attributs comme les mthodes). Dans ce cas, les attributs et les terminaisons dassociation sont rassembls sous le terme de proprits structurelles, le qualificatif structurelle prenant ici toute son importance. Dun autre ct, le mot proprit est souvent utilis dans lacception du terme anglais property (dans la norme UML Superstructure version 2.1.1), qui, lui, ne dsigne que les attributs et les terminaisons dassociation, cest--dire les proprits structurelles. Pour englober les mthodes, il faut alors utiliser le terme plus gnrique de caractristiques, qui prend ainsi le rle de traduction du terme anglais feature dans la norme. Dans le prsent cours, je mefforce de me conformer cette deuxime solution o proprit et proprit structurelle dsignent finalement la mme chose.

19

De manire gnrale, toute bote non strotype dans un diagramme de classes est implicitement une classe. Ainsi, le strotype class est le strotype par dfaut.

3.3 Relations entre classes


3.3.1 Notion dassociation

Une association est une relation entre deux classes (association binaire) ou plus (association n-aire), qui dcrit les connexions structurelles entre leurs instances. Une association indique donc quil peut y avoir des liens entre des instances des classes associes. Comment une association doit-elle tre modlise ? Plus prcisment, quelle diffrence existe-t-il entre les deux diagrammes de la figure 3.3 ?

20

Figure 3.3: Deux faons de modliser une association.

Dans la premire version, lassociation apparat clairement et constitue une entit distincte. Dans la seconde, lassociation se manifeste par la prsence de deux attributs dans chacune des classes en relation. Cest en fait la manire dont une association est gnralement implmente dans un langage objet quelconque (cf. section 3.6.2), mais pas dans tout langage de reprsentation (cf. section 3.6.3). La question de savoir sil faut modliser les associations en tant que tel a longtemps fait dbat. UML a tranch pour la premire version car elle se situe plus un niveau conceptuel (par opposition au niveau dimplmentation) et simplifie grandement la modlisation dassociations complexes (comme les associations plusieurs plusieurs par exemple). Un attribut peut alors tre considr comme une association dgnre dans laquelle une terminaison dassociation4 est dtenue par un classeur (gnralement une classe). Le classeur dtenant cette terminaison dassociation devrait thoriquement se trouver lautre extrmit, non modlise, de lassociation. Un attribut nest donc rien dautre quune terminaison dun cas particulier dassociation (cf. figure 3.9 section 3.3.5). Ainsi, les terminaisons dassociations et les attributs sont deux lments conceptuellement trs proches que lon regroupe sous le terme de proprit.
3.3.2 Terminaison dassociation Propritaire dune terminaison dassociation

La possession dune terminaison dassociation par le classeur situ lautre extrmit de lassociation peut tre spcifi graphiquement par ladjonction dun petit cercle plein (point) entre la terminaison dassociation et la classe (cf. figure 3.4). Il nest pas indispensable de prciser la possession des terminaisons dassociations. Dans ce cas, la possession est ambigu. Par contre, si lon indique des possessions de terminaisons dassociations, toutes les terminaisons dassociations sont non ambigu : la prsence dun point implique que la terminaison dassociation appartient la classe situe lautre extrmit, labsence du point implique que la terminaison dassociation appartient lassociation.

Figure 3.4: Utilisation dun petit cercle plein pour prciser le propritaire dune terminaison dassociation.

Par exemple, le diagramme de la figure 3.4 prcise que la terminaison dassociation sommet (i.e. la proprit sommet) appartient la classe Polygone tandis que la terminaison dassociation polygone (i.e. la proprit polygone) appartient lassociation Dfini par.
21

Une terminaison dassociation est une proprit

Une proprit est une caractristique structurelle. Dans le cas dune classe, les proprits sont constitues par les attributs et les ventuelles terminaisons dassociation que possde la classe. Dans le cas dune association, les proprits sont constitues par les terminaisons dassociation que possde lassociation. Attention, une association ne possde pas forcment toutes ses terminaisons dassociation ! Une proprit peut tre paramtre par les lments suivant (on sintresse ici essentiellement aux terminaisons dassociations puisque les attributs ont t largement traits section 3.2) :
nom : Comme un attribut, une terminaison dassociation peut tre nomme. Le nom est situ proximit de la terminaison, mais contrairement un attribut, ce nom est facultatif. Le nom dune terminaison dassociation est appele nom du rle. Une association peut donc possder autant de noms de rle que de terminaisons (deux pour une association binaire et n pour une association n-aire). visibilit : Comme un attribut, une terminaison dassociation possde une visibilit (cf. section 3.2.4). La visibilit est mentionne proximit de la terminaison, et plus prcisment, le cas chant, devant le nom de la terminaison. multiplicit : Comme un attribut, une terminaison dassociation peut possder une multiplicit. Elle est mentionne proximit de la terminaison. Il nest pas impratif de la prciser, mais, contrairement un attribut dont la multiplicit par dfaut est 1, la multiplicit par dfaut dune terminaison dassociation est non spcifie. Linterprtation de la multiplicit pour une terminaison dassociation est moins vidente que pour un attributs (cf. section 3.3.4). navigabilit : Pour un attribut, la navigabilit est implicite, navigable, et toujours depuis la classe vers lattribut. Pour une terminaison dassociation, la navigabilit peut tre prcise (cf. section 3.3.5). 3.3.3 Association binaire et n-aire Association binaire

Figure 3.5: Exemple dassociation binaire.

22

Une association binaire est matrialise par un trait plein entre les classes associes (cf. figure 3.5). Elle peut tre orne dun nom, avec ventuellement une prcision du sens de lecture ( ou ). Quand les deux extrmits de lassociation pointent vers la mme classe, lassociation est dite rflexive.
Association n-aire

Figure 3.6: Exemple dassociation n-aire.

Une association n-aire lie plus de deux classes. La section 3.3.4 dtaille comment interprter les multiplicits dune association n-aire. La ligne pointill dune classe-association (cf. section 3.3.7) peut tre relie au losange par une ligne discontinue pour reprsenter une association n-aire dote dattributs, doprations ou dassociations. On reprsente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante (cf. figure 3.6). Le nom de lassociation, le cas chant, apparat proximit du losange.
3.3.4 Multiplicit ou cardinalit

La multiplicit associe une terminaison dassociation, dagrgation ou de composition dclare le nombre dobjets susceptibles doccuper la position dfinie par la terminaison dassociation. Voici quelques exemples de multiplicit :

exactement un : 1 ou 1..1 plusieurs : * ou 0..* au moins un : 1..* de un six : 1..6

Dans une association binaire (cf. figure 3.5), la multiplicit sur la terminaison cible contraint le nombre dobjets de la classe cible pouvant tre associs un seul objet donn de la classe source (la classe de lautre terminaison de lassociation). Dans une association n-aire, la multiplicit apparaissant sur le lien de chaque classe sapplique sur une instance de chacune des classes, lexclusion de la classe-association et de la classe considre. Par exemple, si on prend une association ternaire entre les classes (A, B, C), la multiplicit de la terminaison C indique le nombre dobjets C qui peuvent apparatre dans lassociation (dfinie section 3.3.7) avec une paire particulire dobjets A et B.
23

Remarque 1 :

Pour une association n-aire, la multiplicit minimale doit en principe, mais pas ncessairement, tre 0. En effet, une multiplicit minimale de 1 (ou plus) sur une extrmit implique quil doit exister un lien (ou plus) pour TOUTES les combinaisons possibles des instances des classes situes aux autres extrmits de lassociation n-aire !
Remarque 2 :

Il faut noter que, pour les habitus du modle entit/relation, les multiplicits sont en UML lenvers (par rfrence Merise) pour les associations binaires et lendroit pour les n-aires avec n>2.
3.3.5 Navigabilit

Figure 3.7: Navigabilit.

La navigabilit indique sil est possible de traverser une association. On reprsente graphiquement la navigabilit par une flche du ct de la terminaison navigable et on empche la navigabilit par une croix du ct de la terminaison non navigable (cf. figure 3.7). Par dfaut, une association est navigable dans les deux sens. Par exemple, sur la figure 3.7, la terminaison du ct de la classe Commande nest pas navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste dobjets du type Commande. Inversement, la terminaison du ct de la classe Produit est navigable : chaque objet commande contient une liste de produits.

Figure 3.8: Implicitement, ces trois notations ont la mme smantique.

24

Lorsque lon reprsente la navigabilit uniquement sur lune des extrmits dune association, il faut remarquer que, implicitement, les trois associations reprsentes sur la figure 3.8 ont la mme signification : lassociation ne peut tre traverse que dans un sens.

Figure 3.9: Deux modlisations quivalentes.

Dans la section 3.3.1, nous avons dit que :


Un attribut est une association dgnre dans laquelle une terminaison dassociation est dtenue par un classeur (gnralement une classe). Le classeur dtenant cette terminaison dassociation devrait thoriquement se trouver lautre terminaison, non modlise, de lassociation. Un attribut nest donc rien dautre quune terminaison dun cas particulier dassociation.

La figure 3.9 illustre parfaitement cette situation. Attention toutefois, si vous avez une classe Point dans votre diagramme de classe, il est extrmement maladroit de reprsenter des classes (comme la classe Polygone) avec un ou plusieurs attributs de type Point. Il faut, dans ce cas, matrialiser cette proprit de la classe en question par une ou plusieurs associations avec la classe Point.
3.3.6 Qualification

Figure 3.10: En haut, un diagramme reprsentant lassociation entre une banque et ses clients (
25

gauche), et un diagramme reprsentant lassociation entre un chiquier et les cases qui le composent ( droite). En bas, les diagrammes quivalents utilisant des associations qualifies.

Gnralement, une classe peut tre dcompose en sous-classes ou possder plusieurs proprits. Une telle classe rassemble un ensemble dlments (dobjets). Quand une classe est lie une autre classe par une association, il est parfois prfrable de restreindre la porte de lassociation quelques lments cibls (comme un ou plusieurs attributs) de la classe. Ces lments cibls sont appels un qualificatif. Un qualificatif permet donc de slectionner un ou des objets dans le jeu des objets dun objet (appel objet qualifi) reli par une association un autre objet. Lobjet slectionn par la valeur du qualificatif est appel objet cible. Lassociation est appele association qualifie. Un qualificatif agit toujours sur une association dont la multiplicit est plusieurs (avant que lassociation ne soit qualifie) du ct cible. Un objet qualifi et une valeur de qualificatif gnrent un objet cible li unique. En considrant un objet qualifi, chaque valeur de qualificatif dsigne un objet cible unique. Par exemple, le diagramme de gauche de la figure 3.10 nous dit que :

Un compte dans une banque appartient au plus deux personnes. Autrement dit, une instance du couple {Banque , compte} est en association avec zro deux instances de la classe Personne. Mais une personne peut possder plusieurs comptes dans plusieurs banques. Cest--dire quune instance de la classe Personne peut tre associe plusieurs (zro compris) instances du couple {Banque , compte}. Bien entendu, et dans tous les cas, un instance du couple {Personne , compte} est en association avec une instance unique de la classe Banque.

Le diagramme de droite de cette mme figure nous dit que :


Une instance du triplet {Echiquier, range, colonne} est en association avec une instance unique de la classe Case. Inversement, une instance de la classe Case est en association avec une instance unique du triplet {Echiquier, range, colonne}.

3.3.7 Classe-association Dfinition et reprsentation

26

Figure 3.11: Exemple de classe-association.

Parfois, une association doit possder des proprits. Par exemple, lassociation Emploie entre une socit et une personne possde comme proprits le salaire et la date dembauche. En effet, ces deux proprits nappartiennent ni la socit, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il sagit donc bien de proprits de lassociation Emploie. Les associations ne pouvant possder de proprit, il faut introduire un nouveau concept pour modliser cette situation : celui de classe-association. Une classe-association possde les caractristiques des associations et des classes : elle se connecte deux ou plusieurs classes et possde galement des attributs et des oprations. Une classe-association est caractrise par un trait discontinu entre la classe et lassociation quelle reprsente (figure 3.11).
Classe-association pour plusieurs associations

Il nest pas possible de rattacher une classe-association plus dune association puisque la classe-association constitue elle-mme lassociation. Dans le cas o plusieurs classeassociations doivent disposer des mmes caractristiques, elles doivent hriter dune mme classe possdant ces caractristiques, ou lutiliser en tant quattribut. De mme, il nest pas possible de rattacher une instance de la classe dune classe-association plusieurs instances de lassociation de la classe-association. En effet, la reprsentation graphique (association relie par une ligne pointill une classe dporte) est trompeuse : une classe-associaiton est une entit smantique atomique et non composite qui sintancie donc en bloc. Ce problme et nouveau abord et illustr section 3.5.2.
Auto-association sur classe-association

Figure 3.12: Exemple dauto-association sur classe-association.

27

Imaginons que nous voulions ajouter une association Suprieur de dans le diagramme 3.11 pour prciser quune personne est le suprieur dune autre personne. On ne peut simplement ajouter une association rflexive sur la classe Personne. En effet, une personne nest pas le suprieur dune autre dans labsolu. Une personne est, en tant quemploy dune entreprise donn, le suprieur dune autre personne dans le cadre de son emploi pour une entreprise donn (gnralement, mais pas ncessairement, la mme). Il sagit donc dune association rflexive, non pas sur la classe Personne mais sur la classe-association Emploie (cf. figure 3.12).
Liens multiples

Figure 3.13: Exemple de classe-association avec liens multiples.

Plusieurs instances dune mme association ne peuvent lier les mmes objets. Cependant, si lon sintresse lexemple de la figure 3.13, on voit bien quil doit pouvoir y avoir plusieurs instances de la classe-association Actions liant une mme personne une mme socit : une mme personne peut acheter des moments diffrents des actions dune mme socit. Cest justement la raison de la contrainte {bag} qui, place sur les terminaisons dassociation de la classe-association Actions, indique quil peut y avoir des liens multiples impliquant les mmes paires dobjets.
quivalences

Parfois, linformation vhicule par une classe-association peut tre vhicule sans perte dune autre manire (cf. figure 3.14 et 3.15).

Figure 3.14: Deux modlisations modlisant la mme information.


28

Figure 3.15: Deux modlisations modlisant la mme information.

Classe-association, association n-aire ou association qualifie ?

Il nest souvent pas simple trancher entre lutilisation dune classe-association, dune association n-aire ou encore dune association qualifie. Lorsque lon utilise lun de ces trois types dassociation, il peut tre utile ou instructif de se demander si lun des deux autres types ne serait pas plus pertinent. Dans tous les cas, il faut garder lesprit quune classeassociation est dabord et avant tout une association et que, dans une classe-association, la classe est indissociable de lassociation.

Figure 3.16: Pour couvrir le cas des comptes joints, il faut utiliser le modle de droite.

Ainsi, le cas dun compte joint ne peut tre reprsent correctement par le diagramme de gauche dans figure 3.16 : mieux vaut utiliser une association qualifie (diagramme de droite dans la figure 3.16). Ce problme et nouveau abord et illustr section 3.5.2.

29

Figure 3.17: Si un cours doit pouvoir exister indpendamment dun lien entre un enseignant et un groupe, il faut utiliser le modle de droite.

Dans le diagramme de gauche de la figure 3.17, un cours ne peut exister que sil existe un lien entre un objet Enseignant et un objet Groupe. Quand le lien est rompu (effac), le cours lest galement. Si un cours doit pouvoir exister indpendamment de lexistence dun lien (on a pas encore trouv denseignant pour ce cours, le cours nest pas enseign cette anne mais le sera probablement lanne prochaine, ) il faut opter pour une association ternaire (modle de droite dans figure 3.17).

Figure 3.18: Si un mme cours doit concerner plusieurs couples Enseignant/Etudiant, il ne faut pas utiliser une classe-association, mais une association ternaire comme sur le modle de droite.

Le cas de figure est encore pire si lon remplace Groupe par Etudiant (cf. modle gauche sur la figure 3.18). En effet, le cas gnral dcrit par ce modle ne correspond pas du tout au
30

diagramme dobjet (cf. section 3.5) situ au centre. Nous reviendrons sur ce problme dans la section 3.5.2 avec lillustration 3.24. Dans cette situation, il faut opter pour une association ternaire comme sur le modle de droite.
3.3.8 Agrgation et composition Agrgation

Figure 3.19: Exemple de relation dagrgation et de composition.

Une association simple entre deux classes reprsente une relation structurelle entre pairs, cest dire entre deux classes de mme niveau conceptuel : aucune des deux nest plus importante que lautre. Lorsque lon souhaite modliser une relation tout/partie o une classe constitue un lment plus grand (tout) compos dlments plus petit (partie), il faut utiliser une agrgation. Une agrgation est une association qui reprsente une relation dinclusion structurelle ou comportementale dun lment dans un ensemble. Graphiquement, on ajoute un losange vide () du ct de lagrgat (cf. figur e 3.19). Contrairement une association simple, lagrgation est transitive. La signification de cette forme simple dagrgation est uniquement conceptuelle. Elle ne contraint pas la navigabilit ou les multiplicits de lassociation. Elle nentrane pas non plus de contrainte sur la dure de vie des parties par rapport au tout.
Composition

La composition, galement appele agrgation composite, dcrit une contenance structurelle entre instances. Ainsi, la destruction de lobjet composite implique la destruction de ses composants. Une instance de la partie appartient toujours au plus une instance de llment composite : la multiplicit du ct composite ne doit pas tre suprieure 1 (i.e. 1 ou 0..1). Graphiquement, on ajoute un losange plein () du ct de lagrgat.
Remarque

Les notions dagrgation et surtout de composition posent de nombreux problmes en modlisation et sont souvent le sujet de querelles dexperts et sources de confusions. Ce que dit la norme UML Superstructure version 2.1.1 reflte dailleur trs bien le flou qui entoure ces notions :
Precise semantics of shared aggregation varies by application area and modeler. The order and way in which part instances are created is not defined.

31

Gnralisation et Hritage

Figure 3.20: Partie du rgne animal dcrit avec lhritage multiple.

La gnralisation dcrit une relation entre une classe gnrale (classe de base ou classe parent) et une classe spcialise (sous-classe). La classe spcialise est intgralement cohrente avec la classe de base, mais comporte des informations supplmentaires (attributs, oprations, associations). Un objet de la classe spcialise peut tre utilis partout o un objet de la classe de base est autoris. Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de gnralisation se traduit par le concept dhritage. On parle galement de relation dhritage. Ainsi, lhritage permet la classification des objets. Le symbole utilis pour la relation dhritage ou de gnralisation est une flche avec un trait plein dont la pointe est un triangle ferm dsignant le cas le plus gnral. Les proprits principales de lhritage sont :

La classe enfant possde toutes les caractristiques des ses classes parents, mais elle ne peut accder aux caractristiques prives de cette dernire. Une classe enfant peut redfinir (mme signature) une ou plusieurs mthodes de la classe parent. Sauf indication contraire, un objet utilise les oprations les plus spcialises dans la hirarchie des classes. Toutes les associations de la classe parent sappliquent aux classes drives. Une instance dune classe peut tre utilise partout o une instance de sa classe parent est attendue. Par exemple, en se basant sur le diagramme de la figure 3.20, toute opration acceptant un objet dune classe Animal doit accepter un objet de la classe Chat. Une classe peut avoir plusieurs parents, on parle alors dhritage multiple (cf. la classe Ornithorynque de la figure 3.20). Le langage C++ est un des langages objet permettant son implmentation effective, le langage Java ne le permet pas.

En UML, la relation dhritage nest pas propre aux classes. Elle sapplique dautres lments du langage comme les paquetages, les acteurs ou les cas dutilisation.
32

Dpendance

Figure 3.21: Exemple de relation de dpendance.

Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique entre des lments du modle. Elle est reprsente par un trait discontinu orient. Elle indique que la modification de la cible peut impliquer une modification de la source. La dpendance est souvent strotype pour mieux expliciter le lien smantique entre les lments du modle. On utilise souvent une dpendance quand une classe en utilise une autre comme argument dans la signature dune opration. Par exemple, le diagramme de la figure 3.21 montre que la classe Confrontation utilise la classe Stratgie car la classe Confrontation possde une mthode confronter dont deux paramtre sont du type Stratgie. Si la classe Stratgie, notamment son interface, change, alors des modifications devront galement tre apportes la classe Confrontation.
Une terminaison dassociations est une extrmit de lassociation. Une association binaire en possde deux, une association n-aire en possde n.

33

Interfaces

Figure 3.22: Exemple de diagramme mettant en uvre une interface

Nous avons dj abord la notion dinterface. En effet, les classes permettent de dfinir en mme temps un objet et son interface. Le classeur, que nous dcrivons dans cette section, ne permet de dfinir que des lments dinterface. Il peut sagir de linterface complte dun objet, ou simplement dune partie dinterface qui sera commune plusieurs objets. Le rle de ce classeur, strotyp << interface >>, est de regrouper un ensemble de proprits et doprations assurant un service cohrent. Lobjectif est de diminuer le couplage entre deux classeurs. La notion dinterface en UML est trs proche de la notion dinterface en Java. Une interface est reprsente comme une classe except labsence du mot-clef abstract (car linterface et toutes ses mthodes sont, par dfinition, abstraites) et lajout du strotype << interface >>. Une interface doit tre ralise par au moins une classe et peut ltre par plusieurs. Graphiquement, cela est reprsent par un trait discontinu termin par une flche triangulaire et le strotype realize . Une classe peut trs bien raliser plusieurs interfaces. Une classe (classe cliente de linterface) peut dpendre dune interface (interface requise). On reprsente cela par une relation de dpendance et le strotype use . Attention aux problmes de conflits si une classe dpend dune interface ralise par plusieurs autres classes. La notion dinterface est assez proche de la notion de classe abstraite avec une capacit de dcouplage plus grand. En C++ (le C++ ne connat pas la notion dinterface), la notion dinterface est gnralement implmente par une classe abstraite.

34

Diagramme dobjets (object diagram)


Prsentation

Un diagramme dobjets reprsente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue fige de ltat dun systme un instant donn. Un diagramme dobjets peut tre utilis pour :

illustrer le modle de classes en montrant un exemple qui explique le modle ; prciser certains aspects du systme en mettant en vidence des dtails imperceptibles dans le diagramme de classes ; exprimer une exception en modlisant des cas particuliers ou des connaissances non gnralisables qui ne sont pas modliss dans un diagramme de classe ; prendre une image (snapshot) dun systme un moment donn.

Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits. Par exemple, le diagramme de classes de la figure 3.23 montre quune entreprise emploie au moins deux personnes et quune personne travaille dans au plus deux entreprises. Le diagramme dobjets modlise lui une entreprise particulire (PERTNE) qui emploie trois personnes. Un diagramme dobjets ne montre pas lvolution du systme dans le temps. Pour reprsenter une interaction, il faut utiliser un diagramme de communication
3.5.2 Reprsentation

Figure 3.23: Exemple de diagramme de classes et de diagramme dobjets associ.

35

Graphiquement, un objet se reprsente comme une classe. Cependant, le compartiment des oprations nest pas utile. De plus, le nom de la classe dont lobjet est une instance est prcd dun << : >> et est soulign. Pour diffrencier les objets dune mme classe, leur identifiant peut tre ajout devant le nom de la classe. Enfin les attributs reoivent des valeurs. Quand certaines valeurs dattribut dun objet ne sont pas renseignes, on dit que lobjet est partiellement dfini. Dans un diagramme dobjets, les relations du diagramme de classes deviennent des liens. La relation de gnralisation ne possde pas dinstance, elle nest donc jamais reprsente dans un diagramme dobjets. Graphiquement, un lien se reprsente comme une relation, mais, sil y a un nom, il est soulign. Naturellement, on ne reprsente pas les multiplicits.

Figure 3.24: Le diagramme dobjets de droite, illustrant le cas de figure dun compte joint, nest pas une instance normale du diagramme de classe de gauche mais peut prciser une situation exceptionnelle.

La norme UML 2.1.1 prcise quune instance de classe-association ne peut tre associe qu une instance de chacune des classes associes ce qui interdit dinstancier le diagramme de classe gauche dans la figure 3.24 par le diagramme dobjet droite dans cette mme figure. Cependant, un diagramme dobjet peut tre utilis pour exprimer une exception. Sur la figure 3.24, le diagramme dobjets droite peut tre lgitime sil vient prciser une situation exceptionnelle non prise en compte par le diagramme de classe reprsent gauche. Nanmoins, le cas des comptes joints ntant pas si exceptionnel, mieux vaut revoir la modlisation comme prconis par la figure 3.16.
Relation de dpendance dinstanciation

36

Figure 3.25: Dpendance dinstanciation entre les classeurs et leurs instances.

La relation de dpendance dinstanciation (strotype << instanceof >>) dcrit la relation entre un classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux classes.

laboration et implmentation dun diagramme de classes


laboration dun diagramme de classes

Une dmarche couramment utilise pour btir un diagramme de classes consiste :


Trouver les classes du domaine tudi. Cette tape empirique se fait gnralement en collaboration avec un expert du domaine. Les classes correspondent gnralement des concepts ou des substantifs du domaine. 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 >>. Attention, mfiez vous de certains attributs qui sont en ralit des relations entre classes. Trouver les attributs des classes. Les attributs correspondent souvent des substantifs, ou des groupes nominaux, tels que << la masse dune voiture >> ou << le montant dune transaction >>. Les adjectifs et les valeurs correspondent souvent des valeurs dattributs. Vous pouvez ajouter des attributs toutes les tapes du cycle de vie dun projet (implmentation comprise). Nesprez pas trouver tous les attributs ds la construction du diagramme de classes. Organiser et simplifier le modle en liminant les classes redondantes et en utilisant lhritage. Itrer et raffiner le modle. Un modle est rarement correct ds sa premire construction. La modlisation objet est un processus non pas linaire mais itratif.

37

Implmentation en Java Classe

Parfois, la gnration automatique de code produit, pour chaque classe, un constructeur et une mthode finalize comme ci-dessous. Rappelons que cette mthode est invoque par le ramasse miettes lorsque celui-ci constate que lobjet nest plus rfrenc. Pour des raisons de simplification, nous ne ferons plus figurer ces oprations dans les sections suivantes.

public class A { public A() { ... } protected void finalize() throws Throwable { super.finalize(); ... } }

Classe avec attributs et oprations

public class A { public String a1; package String a2; protected String a3; private String a4; public void op1() { ... } public void op2() { ... } }

Classe abstraite

public abstract class A { ... }

38

Interface

public interface A { ... }

Hritage simple

public class A { ... } public class B extends A { ... }

Ralisation dune interface par une classe

public interface Ia { ... } public class A implements Ia { ... }

Association bidirectionnelle 1 vers 1

public class A { private B rb; public void addB( B b ) { if( b != null ){ if ( b.getA() != null ) { // si b est dj connect un autre A b.getA().setB(null); // cet autre A doit se dconnecter }
39

} } public B getB() { return( rb ); } public void setB( B b ) { this.rb=b; }

this.setB( b ); b.setA( this );

public class B { private A ra; public void addA( A a ) { if( a != null ) { if (a.getB() != null) { // si a est dj connect un autre B a.getB().setA( null ); // cet autre B doit se dconnecter } this.setA( a ); a.setB( this ); } } public void setA(A a){ this.ra=a; } public A getA(){ return(ra); } }

Association unidirectionnelle 1 vers 1

public class A { private B rb; public void addB( B b ) { if( b != null ) { this.rb=b; } } } public class B { ... // La classe B ne connat pas l'existence de la classe A }

Association bidirectionnelle 1 vers N

public class A { private ArrayList <B> rb; public A() { rb = new ArrayList<B>(); } public ArrayList <B> getArray() {return(rb);} public void remove(B b){rb.remove(b);} public void addB(B b){ if( !rb.contains(b) ){ if (b.getA()!=null) b.getA().remove(b); b.setA(this); rb.add(b); } } } public class B { private A ra; public B() {}
40

public A getA() { return (ra); } public void setA(A a){ this.ra=a; } public void addA(A a){ if( a != null ) { if( !a.getArray().contains(this)) { if (ra != null) ra.remove(this); this.setA(a); ra.getArray().add(this); } } }

Association unidirectionnelle 1 vers plusieurs

public class A { private ArrayList <B> rb; public A() { rb = new ArrayList<B>(); } public void addB(B b){ if( !rb.contains( b ) ) { rb.add(b); } } } public class B { ... // B ne connat pas l'existence de A }

Association 1 vers N

Dans ce cas, il faut utiliser un tableau plutt quun vecteur. La dimension du tableau tant donnes par la cardinalit de la terminaison dassociation. Agrgations

Les agrgations simplmentent comme les associations. Composition

Une composition peut simplmenter comme une association unidirectionnelle.

41

3.6.3 Implmentation en SQL Introduction

Il est possible de traduire un diagramme de classe en modle relationnel. Bien entendu, les mthodes des classes ne sont pas traduites. Aujourdhui, lors de la conception de base de donnes, il devient de plus en plus courant dutiliser la modlisation UML plutt que le traditionnel modle entits-associations. Cependant, moins davoir respect une mthodologie adapte, la correspondance entre le modle objet et le modle relationnel nest pas une tche facile. En effet, elle ne peut que rarement tre complte puisque lexpressivit dun diagramme de classes est bien plus grande que celle dun schma relationnel. Par exemple, comment reprsenter dans un schma relationnel des notions comme la navigabilit ou la composition ? Toutefois, de nombreux AGL (Atelier de Gnie Logiciel) comportent maintenant des fonctionnalits de traduction en SQL qui peuvent aider le dveloppeur dans cette tche. Dans la section 9.3.1, nous prsentons un type de diagramme de classes, appel modle du domaine, tout fait adapt une implmentation sous forme de base de donnes.
Classe avec attributs

Chaque classe devient une relation. Les attributs de la classe deviennent des attributs de la relation. Si la classe possde un identifiant, il devient la cl primaire de la relation, sinon, il faut ajouter une cl primaire arbitraire.

create table relation_A ( num_relation_A integer primary key, att1 text, att2 integer);

Association 1 vers 1

Pour reprsenter une association 1 vers 1 entre deux relation, la cl primaire de lune des relations doit figurer comme cl trangre dans lautre relation.

create table relation_A ( id_A integer primary key, attA1 text, attA2 integer); create table relation_B (
42

id_B integer primary key, num_A integer references relation_A, attB1 text, attB2 integer);

Association 1 vers plusieurs

Pour reprsenter une association 1 vers plusieurs, on procde comme pour une association 1 vers 1, except que cest forcment la relation du ct plusieurs qui reoit comme cl trangre la cl primaire de la relation du ct 1.

create table relation_A ( id_A integer primary key, num_B integer references relation_B, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, attB1 text, attB2 integer);

Association plusieurs vers plusieurs

Pour reprsenter une association du type plusieurs vers plusieurs, il faut introduire une nouvelle relation dont les attributs sont les cls primaires des relations en association et dont la cl primaire est la concatnation de ces deux attributs.

create table relation_A ( id_A integer primary key, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, attB1 text, attB2 integer); create table relation_A_B ( num_A integer references relation_A, num_B integer references relation_B, primary key (num_A, num_B));

43

Classe-association plusieurs vers plusieurs

Le cas est proche de celui dune association plusieurs vers plusieurs, les attributs de la classeassociation tant ajouts la troisime relation qui reprsente, cette fois ci, la classeassociation elle-mme.

create table relation_A ( id_A integer primary key, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, attB1 text, attB2 integer); create table relation_C ( num_A integer references relation_A, num_B integer references relation_B, attC1 text, attC2 integer, primary key (num_A, num_B));

Hritage

Les relations correspondant aux sous-classes ont comme cl trangre et primaire la cl de la relation correspondant la classe parente. Un attribut type est ajout dans la relation correspondant la classe parente. Cet attribut permet de savoir si les informations dun tuple de la relation correspondant la classe parente peuvent tre compltes par un tuple de lune des relations correspondant une sous-classe, et, le cas chant, de quelle relation il sagit. Ainsi, dans cette solution, un objet peut avoir ses attributs rpartis dans plusieurs relations. Il faut donc oprer des jointures pour reconstituer un objet. Lattribut type de la relation correspondant la classe parente doit indiquer quelles jointures faire.

44

create table relation_C ( id_C integer primary key, attC1 text, attC2 integer, type text); create table relation_A ( id_A references relation_C, attA1 text, attA2 integer, primary key (id_A)); create table relation_B ( id_B references relation_C, attB1 text, attB2 integer, primary key (id_B));

Une alternative cette reprsentation est de ne crer quune seule table par arborescence dhritage. Cette table doit contenir tous les attributs de toutes les classes de larborescence plus lattribut type dont nous avons parl ci-dessus. Linconvnient de cette solution est quelle implique que les tuples contiennent de nombreuses valeurs nulles.
create table relation_ABC ( id_C integer primary key, attC1 text, attC2 integer, attA1 text, attA2 integer, attB1 text, attB2 integer, type text);

45