• 20 heures
  • Facile

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Mis à jour le 07/06/2019

Les relations stéréotypées

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Les cas d’utilisation internes sont toujours reliés, par une flèche, au cas d’utilisation initial qui en  besoin. Le cas d’utilisation initial peut être un cas d’utilisation principal (donc directement relié à un acteur) ou à un autre cas d’utilisation interne. Ces relations sont appelées des relations stéréotypées car ils définissent le type de lien entre les cas d’utilisation, qui peuvent être de deux sortes :

  • les relations « include » ;

  • les relations « extend ».

La relation de type « include »

Une relation « include » est utilisée pour indiquer que le cas d’utilisation source (départ de la flèche) contient TOUJOURS le cas d’utilisation inclus. Dans la figure précédente, le cas d’utilisation source « Enregistrer un achat » contiendra TOUJOURS le cas d’utilisation « Constituer un panier ». Pour représenter cette relation, on dessine donc une flèche en pointillé partant du cas d’utilisation principal vers le cas d’utilisation interne. Puis, on indique le stéréotype « include » sur la flèche (voir la figure précédente). Dans une relation « include », le cas d’utilisation source est donc celui qui a besoin d’un autre cas d’utilisation dit interne, indiqué par une flèche.

La figure suivante illustre tous les cas d’utilisation internes que nous avons identifiés pour le cas d’utilisation « Enregistrer un achat ». Observez bien le diagramme. Que remarquez-vous ?

Diagramme de cas d’utilisation, package «Gestion des achats» v7
Diagramme de cas d’utilisation, package « Gestion des achats »

Je vois une nouvelle relation, dite « Extend » entre le cas d’utilisation « Enregistrer un achat » et « Sélectionner un client ». Pourquoi ce changement ? C’est quoi une relation « Extend » ?

Voilà, ce sera l’objet de notre section suivante.

La relation « extend »

Une relation « extend » est la deuxième forme de relation stéréotypée. Cette relation est utilisée pour indiquer que le cas d’utilisation source (à l’origine de la flèche) n’est pas toujours nécessaire au cas d’utilisation principal, mais qu’il peut l’être dans certaines situations. On doit alors préciser la condition qui fera que le cas d’utilisation en « extend » est nécessaire.

Dans notre cas, le cas d’utilisation interne « Sélectionner le client » n’étant pas une action obligatoire au cas d’utilisation principal « Enregistrer un achat », on peut dès lors parler de relation « extend ». En effet, un client qui réalise un achat sera déjà identifié ; le commercial, par contre, devra sélectionner le client pour lequel il réalise l’achat.

L’ajout de cette relation se fait en dessinant une flèche en pointillé partant du cas d’utilisation interne vers le cas d’utilisation principal. Puis, on indique le stéréotype « extend » sur la flèche. Dès lors qu’il y a une relation « extend », il faudra toujours définir la condition, c’est-à-dire : à quelle condition cette relation peut avoir lieu ? Pour indiquer cela, il faut ajouter une ligne « extension points » et définir la condition « EXT ».

Regardez la figure suivante : ici, le cas d’utilisation « Sélectionner un client » est une relation « extend » du cas d’utilisation principal « Enregistrer un achat ». Cette action n’est possible qu’à condition que l’acteur soit le « Commercial », et non pas le « Client ».

Diagramme de cas d’utilisation, package « Gestion des achats » v8

Voilà, vous savez ce qu’est un cas d’utilisation interne et, ses relations stéréotypées « include » et « extend ».

Notre diagramme de packages pourra mettre en évidence que les deux packages « Gestion des achats » et « Gestion administrative » utiliseront le package « Authentification » :

Diagramme de packages modifié

Du coup, le diagramme de cas d’utilisation du package « Gestion des achats » s’en trouve allégé (voir la figure suivante).

Diagramme de cas d’utilisation, package «Gestion des achats» v9
Diagramme de cas d’utilisation, package « Gestion des achats » 

 

Et cette fameuse spécialisation des cas d’utilisation ?

Et oui, je vous avais promis une autre spécialisation, mais cette fois-ci non pas au niveau des acteurs, mais des cas d’utilisation.

Souvenez-vous de notre description des lots d’action du cas d’utilisation « Enregistrer un achat ».

Actions ou lots d’actions pour le cas d’utilisation « Enregistrer un achat »:

Le client doit…

Le commercial doit…

 

1. S’authentifier

1. S’authentifier

    - soit en se connectant

    - en se connectant

  - soit en s’inscrivant comme nouveau client

 2. Sélectionner le client pour lequel on réalise l’achat

2. Constituer un panier

3. Constituer un panier

    - sélectionner le produit

    - sélectionner le produit

    - valider le panier

    - valider le panier

3. Saisir les informations de livraison

4. Saisir les informations de livraison

 

 

 

4. Enregistrer le règlement de l’achat

5. Enregistrer le règlement de l’achat

    - par carte bancaire

    - soit par carte bancaire

  

    - soit par chèque

Jusque-là, nous nous sommes intéressés aux lots d’action principaux numérotés. Il nous faut maintenant réfléchir aux éléments qui sont indiqués en italique. Regardons plus particulièrement le cas d’utilisation « Enregistrer un règlement ».

Prêt ? C’est parti !

Voici donc de détail du cas d’utilisation « Enregistrement règlement ».

Le complément pour le cas d’utilisation enregistrement règlement

Je vous explique. Comme il s’agit ici de deux variantes du cas d’utilisation « Enregistrement règlement », je crée donc deux nouveaux cas d’utilisation, qui sont des spécialisations de « Enregistrement règlement ».

Ah, je vous avais bien dit qu’on aurait besoin de la notion de spécialisation entre cas d’utilisation !

Pourquoi s’agit-il d’une spécialisation et non d’une relation stéréotypée ?

Dans une relation stéréotypée, un cas d’utilisation a besoin d’un autre cas d’utilisation, soit toujours (« include ») ou sous certaines conditions (« extend »).

Dans une spécialisation, on indique que les cas d’utilisation spécialisés sont des versions différentes du cas d’utilisation générique. Dans notre exemple, les deux nouveaux cas d’utilisation « Enregistrement règlement CB » et « Enregistrement règlement chèque » sont bien 2 versions du cas d’utilisation « Enregistrement règlement ». Ils ont chacun un déroulement spécifique.

En effet, l’enregistrement d’un règlement par chèque n’est possible que lorsqu’un commercial enregistre l’achat. Notre site web commercial ne serait pas très sûr si on acceptait qu’un client enregistre un règlement par chèque lui-même. Il pourrait ne pas nous faire parvenir le chèque ! Nous acceptons donc que seul un commercial puisse enregistrer ce type de règlement, après avoir reçu le chèque.

Par contre, l’enregistrement d’un règlement par carte bancaire est possible autant pour un client que pour un commercial. Le client pourra faire cela en ligne, mais le commercial peut également le faire pour le client lors d’une vente sur site.

Enfin, autre remarque : l’acteur « Système bancaire » n’est utile que dans un des deux cas. Cet acteur n’interviendra que pour l’action « Enregistrement règlement CB » car seul pour les CB, cet acteur secondaire vérifiera l’exactitude des informations fournies.

Est-ce que vous voyez pourquoi il s’agit bien de cas d’utilisation et non d’actions uniques ?

Chacun des cas d’utilisation spécialisés nécessite plusieurs actions. Le cas d’utilisation « Enregistrement règlement CB » comprendra très probablement :

  • le choix du type de carte (visa, Mastercard, Maestro…) ;

  • la saisie du numéro de la carte ;

  • la saisie de la date de validité ;

  • la saisie du cryptogramme ;

  • l’envoi des informations au système bancaire ;

  • la réception de la réponse du système bancaire et le traitement du règlement.

Le cas d’utilisation « Enregistrement règlement chèque» pourrait contenir aussi les actions suivantes :

  • la saisie de la banque et du guichet ;

  • la saisie du numéro de chèque ;

  • la saisie de la date de réception du chèque.

Il y a donc une grande différence entre une action unique (tel qu’un clic sur un bouton « Valider » ou un bouton « Annuler ») et un lot d’actions qui composent un cas d’utilisation.

Voici, sur la figure suivante, le diagramme de cas d’utilisation complété.

Diagramme de cas d’utilisation, package «Gestion des achats» v10
Diagramme de cas d’utilisation, package « Gestion des achats »

Vous avez vu comment notre diagramme a évolué ? En réfléchissant de façon méthodique à ce qui doit être possible de faire, nous avons découvert une multitude de cas d’utilisation. Encore heureux que nous avions décomposé notre système en packages. Sinon le diagramme serait devenu illisible.

Pour information, nous pourrions encore aller plus loin dans le détail de ce diagramme, en explicitant par exemple les cas d’utilisation « S’authentifier », « Constituer un panier » ou encore « Saisir les informations pour livraison ». Mais pour ce premier cours, je vais vous épargner cela ! ;)

Voilà, nous venons de voir comment réaliser des diagrammes pour illustrer le besoin de nos utilisateurs. L’un de nos diagrammes contient des cas d’utilisation internes.

Petit rappel des étapes vues :

1. Nous avons commencé par identifier et illustrer notre projet logiciel de façon globale. Nous avons identifié le contexte (c'est-à-dire le système) et ses utilisateurs. Pour rappel, notre projet de site de boutique en ligne a pour objectif de vendre des produits en ligne. Il s’agit donc ici du système. Ses acteurs ou ses utilisateurs sont :

  • le client, qui consultera le catalogue et achètera des produits en ligne ; 

  • le commercial, qui pourra également consulter le catalogue et qui devra récupérer les informations client pour enregistre une commande pour celui-ci ; 

  • la livraison, qui se chargera de livrer la commande au client ; 

  • le technicien, qui devra consulter les remarques et problèmes signalés ;

  • le service administratif, qui devra gérer le catalogue ;

  • le directeur, qui pourra consulter des états concernant les ventes ;

  • le système bancaire, qui récupère et valide les informations bancaires afin de confirmer la commande. 

Cela nous a permis de réaliser notre premier diagramme de contexte.

2. En étudiant les différents besoins de nos acteurs sur le logiciel, nous avons pu repérer 3 grandes familles de fonction : Gestion des achats, Gestion administrative et Authentification. Elles sont illustrées à l’aide d’un diagramme de package

3. Puis, en étudiant dans le détail l’un des packages « Gestion des achats », nous avons défini les grandes fonctionnalités et les acteurs principaux. Nous avons ainsi réalisé le diagramme de cas d’utilisation (contenant uniquement des cas d’utilisation principaux). 

4. Enfin, à travers l’un des cas d’utilisation principaux, nous avons tenté de définir les différents lots d’actions nécessaires au déroulement de ce cas. Il s’agit des cas d’utilisation internes. Nous avons d’ailleurs vu les différentes formes de relation qui existent entre les cas d’utilisation principales et les cas d’utilisation internes, comme les relations « include », « extend » ou de spécialisation. Nous avons donc réalisé un diagramme de cas d’utilisation détaillé (avec include/ extend/ spécialisation)

En voici la synthèse visuelle.

Synthèse des diagrammes
Synthèse des diagrammes

Légende :

(1) Le diagramme de contexte

(2) Diagramme de package

(3) Diagramme de cas d’utilisation initial

(4) Diagramme de cas d’utilisation détaillé (avec include/ extend/ spécialisation)

Comme vous pouvez le constater, nos diagrammes s’imbriquent les une aux autres, telles des poupées russes. Au fil de l’analyse de besoins, nous avons décrit et détaillé les différents acteurs, leur rôle, leurs grandes fonctionnalités, les lots d’actions ainsi que les relations entre elles.

En résumé

  • Les cas d’utilisation principaux sont complétés par des cas d’utilisation internes. Les cas d’utilisation internes sont des précisions d’autres cas d’utilisation. 

  • Les cas d’utilisation internes sont reliés au cas initial par des relations stéréotypées de type « include » ou « extend », ou par une relation de spécialisation.

  • Les spécialisations peuvent se faire au niveau des acteurs et/ou au niveau des cas d’utilisation. 

  • Une relation « include » permet d’indiquer qu’un cas d’utilisation a toujours besoin du cas d’utilisation lié.

  • Une relation « extend » c’est une relation qui est soumise à une condition. Le cas d’utilisation initial n’utilisera les actions du cas d’utilisation lié que dans certaines circonstances. On doit toujours expliciter la condition qui doit être rencontrée pour que le cas d’utilisation lié soit utile.

Cette partie est maintenant terminée. N'oubliez pas de faire vos exercices avant de passer à la partie suivante. Vous trouverez les liens des exercices (quiz et/ou activité) dans le plan principal du cours ICI. À vous de jouer!

Exemple de certificat de réussite
Exemple de certificat de réussite