Bienvenue sur votre Ecole En Ligne

Espérant que vous serez satisfaits :) :)

Vous trouverez tous ce que vous avez besoins

Les cours existants ont l'objet de tous les domaines

Ecole En Ligne est le choix édial

Chez Ecole En Ligne aucun problème reste sans solution

Vous trouverez tous ce que vous avez besoins

Les cours existants ont l'objet de tous les domaines

Ecole En Ligne va repondre à vous questions

n'hésitez pas de nous contacter et vos propositions sont les bienvenues

dimanche 21 février 2016

Diagramme de classe

Diagramme de classe

 I- Introduction

Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d'une telle modélisation.

Alors que le diagramme de cas d'utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir pour réaliser les cas d'utilisation. Il est important de noter qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation. Les cas d'utilisation ne réalisent donc pas une partition(7) des classes du diagramme de classes. Un diagramme de classes n'est donc pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d'un cas d'utilisation particulier.

Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque langage de Programmation orienté objet donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier.

Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles que la réalisation et l'utilisation.

II- Les classes

1- Notion de classe et instance de classe

Une instance est une concrétisation d'un concept abstrait. Par exemple :
  • la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait Automobile ;
  • l'amitié qui lie Jean et Marie est une instance du concept abstrait Amitié ;
Une classe est un concept abstrait représentant des éléments variés comme :
  • des éléments concrets (ex. : des avions),
  • des éléments abstraits (ex. : des commandes de marchandises ou services),
  • des composants d'une application (ex. : les boutons des boîtes de dialogue),
  • des structures informatiques (ex. : des tables de hachage),
  • des éléments comportementaux (ex. : des tâches), etc.
Tout système orienté objet est organisé autour des classes.
Une classe est la description formelle d'un ensemble d'objets ayant une sémantique et des caractéristiques communes.
Un objet est une instance d'une classe. C'est une entité discrète dotée d'une identité, d'un état et d'un comportement que l'on peut invoquer. Les objets sont des éléments individuels d'un système en cours d'exécution.
Par exemple, si l'on considère que Homme (au sens être humain) est un concept abstrait, on peut dire que la personne Marie-Cécile est une instance de Homme. Si Homme était une classe, Marie-Cécile en serait une instance : un objet.

2- Caractéristiques d'une classe

Une classe définit un jeu d'objets dotés de caractéristiques communes. Les caractéristiques d'un objet permettent de spécifier son état et son comportement. Les caractéristiques d'un objet étaient soit des attributs, soit des opérations. Ce n'est pas exact dans un diagramme de classe, car les terminaisons d'associations sont des propriétés qui peuvent faire partie des caractéristiques d'un objet au même titre que les attributs et les opérations.

État d'un objet :

ce sont les attributs et généralement les terminaisons d'associations, tous deux réunis sous le terme de propriétés structurelles, ou tout simplement propriétés, qui décrivent l'état d'un objet. Les attributs sont utilisés pour des valeurs de données pures, dépourvues d'identité, telles que les nombres et les chaînes de caractères. Les associations sont utilisées pour connecter les classes du diagramme de classe ; dans ce cas, la terminaison de l'association (du côté de la classe cible) est généralement une propriété de la classe de base .

Les propriétés décrites par les attributs prennent des valeurs lorsque la classe est instanciée. L'instance d'une association est appelée un lien.

Comportement d'un objet :

les opérations décrivent les éléments individuels d'un comportement que l'on peut invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entrée et modifier les attributs ou produire des résultats.

Une opération est la spécification (i.e. déclaration) d'une méthode. L'implémentation (i.e. définition) d'une méthode est également appelée méthode. Il y a donc une ambiguïté sur le terme méthode.

Les attributs, les terminaisons d'association et les méthodes constituent donc les caractéristiques d'une classe (et de ses instances).

3- Représentation graphique

Figure 1 : Représentation UML d'une classe.

Une classe est un classeur. Elle est représentée par un rectangle divisé en trois à cinq compartiments (figure1).

Le premier indique le nom de la classe, le deuxième ses attributs et le troisième ses opérations. Un compartiment des responsabilités peut être ajouté pour énumérer l'ensemble de tâches devant être assurées par la classe, mais pour lesquelles on ne dispose pas encore assez d'informations. Un compartiment des exceptions peut également être ajouté pour énumérer les situations exceptionnelles devant être gérées par la classe.

4- Encapsulation, visibilité, interface

Figure 2 : Bonnes pratiques concernant la manipulation des attributs.

L'encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d'une structure en cachant l'implémentation de l'objet, c'est-à-dire en empêchant l'accès aux données par un autre moyen que les services proposés. Ces services accessibles (offerts) aux utilisateurs de l'objet définissent ce que l'on appelle l'interface de l'objet (sa vue externe). L'encapsulation permet donc de garantir l'intégrité des données contenues dans l'objet.

L'encapsulation permet de définir des niveaux de visibilité des éléments d'un conteneur. La visibilité déclare la possibilité pour un élément de modélisation de référencer un élément qui se trouve dans un espace de noms différent de celui de l'élément qui établit la référence. Elle fait partie de la relation entre un élément et le conteneur qui l'héberge, ce dernier pouvant être un paquetage, une classe ou un autre espace de noms. Il existe quatre visibilités prédéfinies.

Public ou + :
  • tout élément qui peut voir le conteneur peut également voir l'élément indiqué.
Protected ou # :
  • seul un élément situé dans le conteneur ou un de ses descendants peut voir l'élément indiqué.
Private ou - :
  • seul un élément situé dans le conteneur peut voir l'élément.
Package ou ∼ ou rien :
  • seul un élément déclaré dans le même paquetage peut voir l'élément.
Par ailleurs, UML 2.0 donne la possibilité d'utiliser n'importe quel langage de programmation pour la spécification de la visibilité.

Dans une classe, le marqueur de visibilité se situe au niveau de chacune de ses caractéristiques (attributs, terminaisons d'association et opération). Il permet d'indiquer si une autre classe peut y accéder.
Dans un paquetage, le marqueur de visibilité se situe sur des éléments contenus directement dans le paquetage, comme les classes, les paquetages imbriqués, etc. Il indique si un autre paquetage susceptible d'accéder au premier paquetage peut voir les éléments.

Dans la pratique, lorsque des attributs doivent être accessibles de l'extérieur, il est préférable que cet accès ne soit pas direct, mais se fasse par l'intermédiaire d'opérations (figure 2).

5- La attributs

Par défaut, chaque instance d'une classe possède sa propre copie des attributs de la classe. Les valeurs des attributs peuvent donc différer d'un objet à un autre. Cependant, il est parfois nécessaire de définir un attribut de classe (static en Java ou en C++) qui garde une valeur unique et partagée par toutes les instances de la classe. Les instances ont accès à cet attribut, mais n'en possèdent pas une copie. Un attribut de classe n'est donc pas une propriété d'une instance, mais une propriété de la classe et l'accès à cet attribut ne nécessite pas l'existence d'une instance.
Graphiquement, un attribut de classe est souligné.

Les attributs dérivés peuvent être calculés à partir d'autres attributs et de formules de calcul. Lors de la conception, un attribut dérivé peut être utilisé comme marqueur jusqu'à ce que vous puissiez déterminer les règles à lui appliquer.
Les attributs dérivés sont symbolisés par l'ajout d'un « / » devant leur nom.

6- Les méthodes

Comme pour les attributs de classe, il est possible de déclarer des méthodes de classe. Une méthode de classe ne peut manipuler que des attributs de classe et ses propres paramètres. Cette méthode n'a pas accès aux attributs de la classe (i.e. des instances de la classe). L'accès à une méthode de classe ne nécessite pas l'existence d'une instance de cette classe.
Graphiquement, une méthode de classe est soulignée.

Une méthode est dite abstraite lorsqu'on connaît son entête, mais pas la manière dont elle peut être réalisée (i.e. on connaît sa déclaration, mais pas sa définition).
Une classe est dite abstraite lorsqu'elle définit au moins une méthode abstraite ou lorsqu'une classe parent contient une méthode abstraite non encore réalisée.
On ne peut instancier une classe abstraite : elle est vouée à se spécialiser. Une classe abstraite peut très bien contenir des méthodes concrètes.
Une classe abstraite pure ne comporte que des méthodes abstraites. En programmation orientée objet, une telle classe est appelée une interface.
Pour indiquer qu'une classe est abstraite, il faut ajouter le mot-clef abstract derrière son nom.

III- Relations entre classes

1- Notion d'association

Une association est une relation entre deux classes (association binaire) ou plus (association n‑aire), qui décrit les connexions structurelles entre leurs instances. Une association indique donc qu'il peut y avoir des liens entre des instances des classes associées.
Comment une association doit-elle être modélisée ? Plus précisément, quelle différence existe-t-il entre les deux diagrammes de la figure 3 ?


Figure 3 : Deux façons de modéliser une association.

Dans la première version, l'association apparaît clairement et constitue une entité distincte. Dans la seconde, l'association se manifeste par la présence de deux attributs dans chacune des classes en relation. C'est en fait la manière dont une association est généralement implémentée dans un langage objet quelconque, mais pas dans tout langage de représentation.

La question de savoir s'il faut modéliser les associations en tant que telles a longtemps fait débat. UML a tranché pour la première version, car elle se situe plus à un niveau conceptuel (par opposition au niveau d'implémentation) et simplifie grandement la modélisation d'associations complexes (comme les associations plusieurs à plusieurs par exemple).

Un attribut peut alors être considéré comme une association dégénérée dans laquelle une terminaison d'association est détenue par un classeur (généralement une classe). Le classeur détenant cette terminaison d'association devrait théoriquement se trouver à l'autre extrémité, non modélisée, de l'association. Un attribut n'est donc rien d'autre qu'une terminaison d'un cas particulier d'association.

Ainsi, les terminaisons d'associations et les attributs sont deux éléments conceptuellement très proches que l'on regroupe sous le terme de propriété.

2- terminaison d'association

La possession d'une terminaison d'association par le classeur situé à l'autre extrémité de l'association peut être spécifiée graphiquement par l'adjonction d'un petit cercle plein (point) entre la terminaison d'association et la classe (cf. figure 4). Il n'est pas indispensable de préciser la possession des terminaisons d'associations. Dans ce cas, la possession est ambiguë. Par contre, si l'on indique des possessions de terminaisons d'associations, toutes les terminaisons d'associations sont non ambiguës : la présence d'un point implique que la terminaison d'association appartient à la classe située à l'autre extrémité, l'absence du point implique que la terminaison d'association appartient à l'association.

Figure 4 : Utilisation d'un petit cercle plein pour préciser 
le propriétaire d'une terminaison d'association.

Par exemple, le diagramme de la figure 4 précise que la terminaison d'association sommet (i.e. la propriété sommet) appartient à la classe Polygone tandis que la terminaison d'association polygone (i.e. la propriété polygone) appartient à l'association Défini par.

3- Association binaire et n-aire

a- Association binaire


Figure 5 : Exemple d'association binaire.



Une association binaire est matérialisée par un trait plein entre les classes associées (cf. figure 5). Elle peut être ornée d'un nom, avec éventuellement une précision du sens de lecture (▸ ou ◂).

Quand les deux extrémités de l'association pointent vers la même classe, l'association est dite réflexive.

b- Association n-aire

Figure  6 : Exemple d'association n-aire.

Une association n-aire lie plus de deux classes. La ligne pointillée d'une classe-association peut être reliée au losange par une ligne discontinue pour représenter une association n-aire dotée d'attributs, d'opérations ou d'associations.

On représente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante (cf. figure 6). Le nom de l'association, le cas échéant, apparaît à proximité du losange.

4- Multiplicité ou Cardinalité

La multiplicité associée à une terminaison d'association, d'agrégation ou de composition déclare le nombre d'objets susceptibles d'occuper la position définie par la terminaison d'association. 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 5), la multiplicité sur la terminaison cible contraint le nombre d'objets de la classe cible pouvant être associés à un seul objet donné de la classe source (la classe de l'autre terminaison de l'association).

Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque classe s'applique sur une instance de chacune des classes, à l'exclusion de la classe-association et de la classe considérée. Par exemple, si on prend une association ternaire entre les classes (A, B, C), la multiplicité de la terminaison C indique le nombre d'objets C qui peuvent apparaître dans l'association avec une paire particulière d'objets A et B.

5- Navigabilité

Figure 7 : Navigabilité.


La navigabilité indique s'il est possible de traverser une association. On représente graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on empêche la navigabilité par une croix du côté de la terminaison non navigable (cf. figure 7). Par défaut, une association est navigable dans les deux sens.

Par exemple, sur la figure 7, la terminaison du côté de la classe Commande n'est pas navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste d'objets du type Commande. Inversement, la terminaison du côté de la classe Produit est navigable : chaque objet commande contient une liste de produits.
Figure 8 : Implicitement, ces trois notations ont la même sémantique.


Lorsque l'on représente la navigabilité uniquement sur l'une des extrémités d'une association, il faut remarquer que, implicitement, les trois associations représentées sur la figure 8 ont la même signification : l'association ne peut être traversée que dans un sens.

Figure 9 : Deux modélisations équivalentes.

 Un attribut est une association dégénérée dans laquelle une terminaison d'association est détenue par un classeur (généralement une classe). Le classeur détenant cette terminaison d'association devrait théoriquement se trouver à l'autre terminaison, non modélisée, de l'association. Un attribut n'est donc rien d'autre qu'une terminaison d'un cas particulier d'association. »

La figure 9 illustre parfaitement cette situation.

6- Qualification

Figure 10 : En haut, un diagramme représentant l'association entre une banque et ses clients (à gauche), et un diagramme représentant l'association entre un échiquier et les cases qui le composent (à droite). En bas, les diagrammes équivalents utilisant des associations qualifiées

Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés. Une telle classe rassemble un ensemble d'éléments (d'objets). Quand une classe est liée à une autre classe par une association, il est parfois préférable de restreindre la portée de l'association à quelques éléments ciblés (comme un ou plusieurs attributs) de la classe. Ces éléments ciblés sont appelés un qualificatif. Un qualificatif permet donc de sélectionner un ou des objets dans le jeu des objets d'un objet (appelé objet qualifié) relié par une association à un autre objet. L'objet sélectionné par la valeur du qualificatif est appelé objet cible. L'association est appelée association qualifiée. Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs (avant que l'association ne soit qualifiée) du côté cible.

Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique. En considérant un objet qualifié, chaque valeur de qualificatif désigne un objet cible unique.

Par exemple, le diagramme de gauche de la figure 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 zéro à deux instances de la classe Personne ;
  • mais une personne peut posséder plusieurs comptes dans plusieurs banques. C'est-à-dire qu'une instance de la classe Personne peut être associée à plusieurs (zéro compris) instances du couple {Banque , compte} ;
  • bien entendu, et dans tous les cas, une instance du couple {Personne , compte} est en association avec une instance unique de la classe Banque.
Le diagramme de droite de cette même figure nous dit que :
  • une instance du triplet {Échiquier, rangée, 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 {Échiquier, rangée, colonne}.

7- Classe-association

a- Définition et représentation

Figure 11 : Exemple de classe-association.

Parfois, une association doit posséder des propriétés. Par exemple, l'association Emploieentre une société et une personne possède comme propriétés le salaire et la date d'embauche. En effet, ces deux propriétés n'appartiennent ni à la société, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s'agit donc bien de propriétés de l'association Emploie. Les associations ne pouvant posséder de propriété, il faut introduire un nouveau concept pour modéliser cette situation : celui de classe-association.

Une classe-association possède les caractéristiques des associations et des classes : elle se connecte à deux ou plusieurs classes et possède également des attributs et des opérations.
Une classe-association est caractérisée par un trait discontinu entre la classe et l'association qu'elle représente (figure 11).

b- Classe-association pour plusieurs associations

Il n'est pas possible de rattacher une classe-association à plus d'une association puisque la classe-association constitue elle-même l'association. Dans le cas où plusieurs classe-associations doivent disposer des mêmes caractéristiques, elles doivent hériter d'une même classe possédant ces caractéristiques, ou l'utiliser en tant qu'attribut.

De même, il n'est pas possible de rattacher une instance de la classe d'une classe-association à plusieurs instances de l'association de la classe-association. En effet, la représentation graphique (association reliée par une ligne pointillée à une classe déportée) est trompeuse : une classe-association est une entité sémantique atomique et non composite qui s'instancie donc en bloc.

c- Auto-association sue classe-association

Figure 12 : Exemple d'autoassociation sur classe-association.

Imaginons que nous voulions ajouter une association Supérieur de dans le diagramme 11 pour préciser qu'une personne est le supérieur d'une autre personne. On ne peut simplement ajouter une association réflexive sur la classe Personne. En effet, une personne n'est pas le supérieur d'une autre dans l'absolu. Une personne est, en tant qu'employé d'une entreprise donnée, le supérieur d'une autre personne dans le cadre de son emploi pour une entreprise donnée (généralement, mais pas nécessairement, la même). Il s'agit donc d'une association réflexive, non pas sur la classe Personne, mais sur la classe-association Emploie (cf. figure 12).

d- Liens multiples

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

Plusieurs instances d'une même association ne peuvent lier les mêmes objets. Cependant, si l'on s'intéresse à l'exemple de la figure 13, on voit bien qu'il doit pouvoir y avoir plusieurs instances de la classe-association Actions liant une même personne à une même société : une même personne peut acheter à des moments différents des actions d'une même société.

C'est justement la raison de la contrainte {bag} qui, placée sur les terminaisons d'association de la classe-association Actions, indique qu'il peut y avoir des liens multiples impliquant les mêmes paires d'objets.

e- Équivalences

Parfois, l'information véhiculée par une classe-association peut être véhiculée sans perte d'une autre manière (cf. figure 14 et 15).

Figure 14 : Deux modélisations modélisant la même information.


Figure 15 : Deux modélisations modélisant la même information.













samedi 20 février 2016

Diagramme de cas d'utilisation

Diagramme de cas d'utilisation

I- Introduction

Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML d'analyse d'un système.

Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d'une vision informatique.

Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des utilisateurs. Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

II- Eléments des diagrammes de cas d'utilisation :

1- Acteur :

Un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système.

Il se représente par un petit bonhomme (figure 1) avec son nom (i.e. son rôle) inscrit dessous.

                                                          Figure 1 : Exemple de représentation d'un acteur.

Il est également possible de représenter un acteur sous la forme d'un classeur << actor >> (figure 2).

Figure 2 : Exemple de représentation d'un acteur
sous la forme d'un classeur.

2- Cas d'utilisation

Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.

Un cas d'utilisation se représente par une ellipse (figure3) contenant le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus du nom, un stéréotype

Figure3 : Exemple de représentation d'un cas d'utilisation.

Dans le cas où l'on désire présenter les attributs ou les opérations du cas d'utilisation, il est préférable de le représenter sous la forme d'un classeur stéréotypé << use case >> (figure 4). Nous reviendrons sur les notions d'attributs ou d'opération lorsque nous aborderons les diagrammes de classes et d'objets.

Figure 4 : Exemple de représentation d'un cas d'utilisation
sous la forme d'un classeur.

3- Représentation d'un diagramme de cas d'utilisation


Figure 5 : Exemple simplifié de diagramme de cas d'utilisation modélisant 

une borne d'accès à une banque.


Comme le montre la figure 5, la frontière du système est représentée par un cadre. Le nom du système figure à l'intérieur du cadre, en haut. Les acteurs sont à l'extérieur et les cas d'utilisation à l'intérieur.

III- Relations entre les diagrammes de cas d'utilisation

1- Relation entre acteurs et cas d'utilisation 

a- Relation d'association

Figure 6 : Diagramme de cas d'utilisation représentant un logiciel de partage de fichiers.

Une relation d'association est chemin de communication entre un acteur et un cas d'utilisation et est représenté un trait continu ( figure 5 ou 6).

b- Multiplicité

Lorsqu'un acteur peut interagir plusieurs fois avec un cas d'utilisation, il est possible d'ajouter une multiplicité sur l'association du côté du cas d'utilisation. Le symbole * signifie plusieurs (figure 6), exactement n s'écrit tout simplement nn..m signifie entre n et m, etc. Préciser une multiplicité sur une relation n'implique pas nécessairement que les cas sont utilisés en même temps.

La notion de multiplicité n'est pas propre au diagramme de cas d'utilisation. Nous en reparlerons dans le chapitre consacré au diagramme de classes section

c- Acteurs principales et secondaires

Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend service à cet acteur. Les autres acteurs sont alors qualifiés de secondaires. Un cas d'utilisation a au plus un acteur principal. Un acteur principal obtient un résultat observable du système tandis qu'un acteur secondaire est sollicité pour des informations complémentaires. En général, l'acteur principal initie le cas d'utilisation par ses sollicitations. Le stéréotype << primary >>vient orner l'association reliant un cas d'utilisation à son acteur principal, le stéréotype<< secondary >> est utilisé pour les acteurs secondaires (figure 6).

d- Cas d'utilisation interne

Quand un cas n'est pas directement relié à un acteur, il est qualifié de cas d'utilisation interne.

2- Relations entre cas d'utilisation



Figure 7 : Exemple de diagramme de cas d'utilisation.

a- Types et représentations

Il existe principalement deux types de relations :
  • les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus utilisés sont l'inclusion et l'extension) ;
  • et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé (figure 7). Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.

Le symbole utilisé pour la généralisation est un flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général (figure 7).

b- Relation d'inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est sollicité, B l'est obligatoirement, comme une partie de A. Cette dépendance est symbolisée par le stéréotype << include >> (figure 7). Par exemple, l'accès aux informations d'un compte bancaire inclut nécessairement une phase d'authentification avec un identifiant et un mot de passe (figure ).

Les inclusions permettent essentiellement de factoriser une partie de la description d'un cas d'utilisation qui serait commune à d'autres cas d'utilisation (cf. le cas S'authentifier de la figure 7).

Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples (figure 8).



Figure 8 : Relations entre cas pour décomposer un cas complexe.


c- Relation d'extension

La relation d'extension est probablement la plus utile, car elle a une sémantique qui a un sens du point de vue métier au contraire des deux autres qui sont plus des artifices d'informaticiens.

On dit qu'un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A peut être appelé au cours de l'exécution du cas d'utilisation B. Exécuter B peut éventuellement entraîner l'exécution de A : contrairement à l'inclusion, l'extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> (figure 7).

L'extension peut intervenir à un point précis du cas étendu. Ce point s'appelle le point d'extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique point d'extension, et est éventuellement associé à une contrainte indiquant le moment où l'extension intervient. Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d'une note. La figure 7 présente l'exemple d'une banque où la vérification du solde du compte n'intervient que si la demande de retrait dépasse 20 euros.

d- Relation de généralisation

Un cas A est une généralisation d'un cas B si B est un cas particulier de A. Dans la figure 7, la consultation d'un compte via Internet est un cas particulier de la consultation. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d'héritage dans les langages orientés objet.

3- Relations entre acteurs

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d'un acteur B si l'acteur A peut être substitué par l'acteur B. Dans ce cas, tous les cas d'utilisation accessibles à A le sont aussi à B, mais l'inverse n'est pas vrai.

Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont la pointe est un triangle fermé désignant l'acteur le plus général (comme nous l'avons déjà vu pour la relation de généralisation entre cas d'utilisation).

Par exemple, la figure 9 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le stock.



Figure 9 : Relations entre acteurs.