L'ensemble des éléments de ce TP a été rédigé par Lang Alexandre


Dans les précédents TDs nous avons pu construire notre diagramme de cas d’utilisation (TD1) en rappelant ce que chaque élément signifiait puis nous avons vu comment décrire un cas d’utilisation de la manière la plus précise possible pour qu’il puisse être compréhensible par tous (TD2).

Dans le TD1 nous avions vu que nous pouvions associer un (des) acteur(s) à un (des) cas d’utilisation. Par conséquent les seules relations qui existaient jusqu’à lors dans notre diagramme étaient entre acteurs et cas d’utilisation.
Mais dans ce TD nous allons voir qu’il peut exister des relations entre les cas d’utilisation et même entre les acteurs !
Bien évidemment il ne s’agira pas forcément des mêmes relations…

Pour ce premier TP les objectifs sont les suivants :
  • Objectif 1 : Rappeler les différentes relations possibles
  • Objectif 2 : Faire la différence entre l'inclusion et l'extension
  • Objectif 3 : Faire la différence entre l'héritage entre cas d'utilisation et l'héritage entre acteurs
  • Objectif 4 : Maitriser la notion de package

Il existe principalement deux familles, deux types de relations :
    - Les dépendances stéréotypées, qui sont explicitées par un stéréotype,
    - L’héritage.

3.1. Les dépendances stéréotypées

Cette famille est composée de deux types de relations
    - L’inclusion
    - L’extension
Attention, ces deux types de relations ne peuvent être affectées qu’à des cas d’utilisation !

3.1.1. L'inclusion

Pour donner une définition formelle on peut dire qu’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 >>.

Pour le représenter il faut, dans le cas où A inclus B, relier le cas A et le cas avec une flèche en pointillée qui part de A et va vers B et qui porte au-dessus la mention << include >>. Ce qui donne :

Pour nous aider à savoir dans quel sens il faut orienter la flèche il faut se dire, « A inclus B » autrement dit « si je fais A alors je dois faire B ».

Les inclusions permettent essentiellement de factoriser une partie de la description d'un cas d'utilisation qui serait commune à d'autres cas d'utilisation.
Par exemple si on a le diagramme de cas d’utilisation suivant :

et que pour réaliser ces deux cas d’utilisation l’Internaute ait besoin de s’identifier. Au lieu de devoir, dans la description des deux cas d’utilisation précédent, marquer que l’internaute doit s’identifier pour les réaliser, on va factoriser l’élément pour en faire un cas d’utilisation qui sera relié avec un << include >> aux deux autres cas d’utilisation. On obtient alors :

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

3.1.2. L'extension

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

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

Comme pour l’inclusion (include), l’extension se représente à l’aide d’une flèche en pointillée sur laquelle figure la mention << extend >>. En revanche ce qui change c’est le sens de la flèche. En effet si B est une extension de A c’est qu’on peut éventuellement réaliser en réalisant A il faudra orienter la flèche de B vers A. On obtient donc :

L'extension peut intervenir à un point précis du cas étendu (le cas A ci-dessus) c’est-à-dire qu’on ne peut faire appel à B que si on remplit une certaine condition à un certain point. Ce point s'appelle le point d'extension.
Graphiquement, la condition pour réaliser l’extension est exprimée sous la forme d'une note placée sur la relation. Pour le cas précédent on obtient donc :

3.2. L'héritage

Cette relation, contrairement aux deux présentées précédemment s’applique soit entre acteurs soit entre cas d’utilisation et ne signifie pas la même chose.

3.2.1. L’héritage entre acteurs

Lorsque l’on créé une relation d’héritage entre deux acteurs A et B cela signifie simplement que tout ce que fait l’acteur B, l’acteur A peut le faire.

Cette relation se représente à l’aide d’une flèche pleine dont le bout est un triangle blanc à l’intérieur.

Comme toujours le sens de la flèche est important. Si nous avons deux acteurs A et B et que tout ce que fait B, A peut le faire alors la flèche partira de A et ira vers B ce qui donnera :

Pour nous aider à savoir dans quel sens il faut orienter la flèche il faut se dire que c’est comme si la flèche portait la mention « hérite de tout ce que fait ».
Ainsi si on l’on place la flèche de A vers B on aura « A hérite de tout ce que fait B » et si on la place de B vers A on aura « B hérite de tout ce que fait A ».

3.2.2. L’héritage entre cas d'utilisation

Une relation d’héritage entre deux cas d’utilisation permet d’expliciter différentes de « réaliser » un même cas d’utilisation.

Sa représentation graphique ne change pas.
Pour l’orientation de la flèche, si on a A un cas d’utilisation et B un autre cas d’utilisation qui est un moyen de « réaliser » A il faut partir de B et allé vers A.
A noter qu’on peut avoir autant de cas d’utilisation qui permettent de « réaliser » A connectés à A.
Ainsi on aura :

Dans l’exemple précédent on a que pour « réaliser » A on peut le faire soit avec le cas d’utilisation B, C ou D.

Afin de mettre en application les nouvelles notions vues précédemment on va une fois reprendre notre Smart Garage.

Nous avions obtenu, au TD1, le diagramme de cas d’utilisation suivant :

On ensuite le complément d’énoncé suivant :
    1- Les mécaniciens peuvent, en consultant les fiches suiveuses, les modifier pour les compléter.
    2- Afin de prendre en compte le contexte du garage, les mécaniciens doivent pouvoir s'identifier pour effectuer leurs actions en saisissant son login et mot de passe, en présentant son badge ou par reconnaissance faciale
    3- Il a été établi que le chef d’atelier, en sa qualité de responsable des mécaniciens, pouvait sans problème réaliser le travail des mécaniciens dans le cas où l’un d’entre eux serait absent.

S’agissant d’un énoncé complémentaire il nous faut compléter notre diagramme de cas d’utilisation pour le respecter. Prenons donc notre énoncé ligne par ligne

    1- Les mécaniciens peuvent, en consultant les fiches suiveuses, les modifier pour les compléter.

Dans cette première phrase on apprend que les mécaniciens peuvent, ce n’est donc pas une obligation mais une possibilité, compléter une fiche suiveuse en la consultant.
Or nous avons deux cas d’utilisation qui laissent entrevoir ces possibilités.
Vous l’aurez surement compris nous devons relier ces deux cas d’utilisation avec une relation d’extension.

Dans quel sens mettre la flèche ?

Comme le mécanicien peut « Compléter la fiche suiveuse » en « Consultant la fiche suiveuse » il faut que la flèche parte de « Compléter la fiche suiveuse » et aille vers « Consulter la fiche suiveuse et les travaux précédents » car le sens est inversé !

On a alors :

Ainsi on a bien qu’en « consultant la fiche suiveuse » il peut « compléter la fiche suiveuse ».

    2- Afin de prendre en compte le contexte du garage, les mécaniciens doivent pouvoir s'identifier pour effectuer leurs actions en saisissant son login et mot de passe, en présentant son badge ou par reconnaissance faciale

Pour cette phrase on nous dit plusieurs choses.

D’une part on apprend que pour réaliser toutes leurs actions les mécaniciens doivent d’abord s’identifier, c’est obligatoire.
On pourrait certes penser qu’il faille le mettre dans les préconditions de nos descriptions de nos cas d’utilisation affiliés au mécanicien mais s’agissant d’un élément commun on va en faire un nouveau cas d’utilisation : « S’identifier ».
Comme tous les cas d’utilisation liés au mécanicien doivent forcement passés par ce nouveau cas d’utilisation il va falloir créer des relations d’inclusion entre ces cas d’utilisation de tel manière à ce qu’à chaque fois que le mécanicien réalisera une action il devra en même temps s’identifier.

On obtient alors :

D’autre part, toujours dans la même ligne, on apprend, que le mécanicien possède différentes façons pour s’identifier :
    - En saisissant son login et son mot de passe
    - En présentant son badge
    - Avec la reconnaissance faciale
Ces différentes façons pour s’identifier représentent donc différents moyen pour « réaliser » ce cas d’utilisation.
Il nous faut donc faire de chacune de ces possibilités un cas d’utilisation et tous les relier au cas d’utilisation « S’identifier » avec une relation d’héritage.
Il faut bien évidemment faire attention, une fois de plus, au sens de la flèche.

On obtient donc :

    3- Il a été établi que le chef d’atelier, en sa qualité de responsable des mécaniciens, pouvait sans problème réaliser le travail des mécaniciens dans le cas où l’un d’entre eux serait absent.

Dans cette dernière phrase on comprend facilement que tout ce que fais un mécanicien, le chef d’atelier peut le faire aussi.
Par conséquent il s’agit d’une relation d’héritage entre acteurs. Pour nous aider à bien placer la flèche il ne faut pas oublier qu’on peut s’imaginer qu’elle porte la mention « hérite de tout ce que fais ».
Ici on sait que le chef d’atelier hérite de tout ce que font les mécaniciens. Par conséquent la flèche partira du chef d’atelier et ira vers le mécanicien.

On obtient donc :

Nous avons donc obtenu un diagramme de cas d’utilisation conforme à l’énoncé.

Un paquetage est un regroupement d'éléments de modèle et de diagrammes. Il permet ainsi d'organiser des éléments de modélisation en groupes. Il peut contenir tout type d'élément de modèle : des classes, des cas d'utilisation, des interfaces, des diagrammes… et même des paquetages imbriqués (décomposition hiérarchique).

Les éléments contenus dans un paquetage doivent représenter un ensemble fortement cohérent et sont généralement de même nature et de même niveau sémantique. Tout élément n'appartient qu'à un seul paquetage. Les paquetages constituent un mécanisme de gestion important des problèmes de grande taille. Ils permettent d'éviter les grands modèles plats et de cloisonner des éléments constitutifs d'un système évoluant à des rythmes différents ou développés par des équipes différentes.

Pour le diagramme de cas d’utilisation la notion de paquetage est importante puisque cela permet de regrouper des cas d’utilisation entre eux. Ces cas d’utilisation ont bien évidemment des notions, des éléments en commun.
Le fait de regrouper ces cas d’utilisation entre eux nous permet de décrire un comportement sur le paquet qui va pouvoir s’appliquer sur tous les cas d’utilisation qu’il contient sans que l’on ait besoin de spécifier ce comportement pour tous les cas d’utilisation un par un.

Un paquetage se représente comme un dossier avec son nom inscrit dedans. Il est possible de représenter explicitement le contenu d'un paquetage, ce qu’il contient. Dans ce cas, le nom du paquetage est placé en haut du dossier.

A titre d’exemple et d’application essayons de créer des paquets pour notre Smart Garage !

On peut déjà commencer par regrouper tous les cas d’utilisation de chaque acteur dans un paquet.
Les actions partagées par le mécanicien et le boitier spécialiser seront regroupées dans un paquet à part.
A noter que le paquet du chef d’atelier comprendra toutes ses actions ainsi que celles des mécaniciens.
Bien évidemment les acteurs qui ne possèdent qu’un cas d’utilisation ne possèderont pas de paquet dédié.

On peut également regrouper les différents moyens de s’identifier en un paquet.

On obtient donc :

Les éléments importants à retenir de ce TP sont les suivants :

Il existe différentes relations :
    - Entre cas d’utilisation :
        o L’inclusion : qui représente une obligation : si A inclus B alors quand on réalise A on doit forcément réaliser B et ainsi la flèche part de A et va vers B.
        o L’extension : qui représente une possibilité : si B est une extension de A alors en réalisant A on peut réaliser B et ainsi la flèche part de B et va vers A.
        o L’héritage : qui représente toutes les façons possibles de réaliser un cas d’utilisation.
    - Entre acteurs :
        o L’héritage : qui traduit le fait qu’un acteur peut faire tout ce que fait un autre. Pour nous aider à savoir dans quel sens on peut placer la flèche il faut imaginer que la flèche porte la mention « hérite de tout ce que fait ».

Pour regrouper des cas d’utilisation qui ont un thème en commun on peut les rassembler dans un paquet
A l’issu de ce TP de nouvelles notions ont été abordées. Lors de l’application de ces notions il est important de ne pas commettre les erreurs suivantes.

Lorsque l’on écrit une inclusion ou une extension il ne faut surtout pas oublier de mettre << include >> ou << extend >> sur la relation.

Les relations d’inclusion et d’extension se représentent par des flèches en pointillées tandis que l’héritage se représente avec un triangle vide en guise de flèche.

Il ne faut surtout pas confondre le sens des flèches entre l’inclusion, l’extension et l’héritage !
Dans ce troisième TD nous avons pu voir, revoir, les différentes relations qu’il peut exister au sein d’un diagramme de cas d’utilisation que ce soit entre deux cas d’utilisation (inclusion, extension, héritage) ou bien encore entre deux acteurs (héritage). Nous avons également pu voir la notion de paquetage.
Ainsi vous saurez maintenant décrire au mieux un cas d’utilisation et exploiter toutes les possibilités qui y sont liées grâce à ce TD et aux deux précédent.

Maintenant que nous avons vu, à travers ces 3 premiers TDs, le premier diagramme de l’UML qui est le diagramme de cas d’utilisation et toutes les grandes notions associées il nous faut maintenant poursuivre notre exploration des grandes notions de l’UML avec d’autres diagrammes (séquence, classe) d’un type nouveau qui vont nous aider à encore mieux spécifier nos sujets et à de plus en plus se rapprocher du code.

Ces nouvelles notions nous occuperons au cours des prochains TDs.