Diagramme de cas d’utilisation cours et exemples

Diagramme de cas d’utilisation

UML permet de construire plusieurs modèles d’un système : certains montrent le système du point de vue des utilisateurs, d’autres montrent sa structure interne, d’autres encore en donnent une vision globale ou détaillée. Les modèles se complètent et peuvent être assemblés.

Ils sont élaborés tout au long du cycle de vie du développement d’un système (depuis le recueil des besoins jusqu’à la phase de conception). Dans ce chapitre, nous allons étudier un des modèles , en l’occurrence le premier à construire : le diagramme de cas d’utilisation.

Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui débute l’étape d’analyse d’un système.

L’importance de bien recueillir les besoins

Le développement d’un nouveau système, ou l’amélioration d’un système existant, doit répondre à un ou à plusieurs besoins. Par exemple, une banque a besoin d’un guichet automatique pour que ses clients puissent retirer de l’argent même en dehors des heures d’ouverture de la banque. Celui qui commande le logiciel est le maître d’ouvrage. Celui qui réalise le logiciel est le maître d’oeuvre.

Le maître d’ouvrage intervient constamment au cours du projet, notamment pour :

• définir et exprimer les besoins ;

• valider les solutions proposées par le maître d’oeuvre ;

• valider le produit livré.

Le maître d’oeuvre est, par exemple, une société de services en informatique (SSII). Il a été choisi, avant tout, pour ses compétences techniques. Mais son savoir-faire va bien au-delà. Au début du projet, il est capable de recueillir les besoins auprès du maître d’ouvrage. Le recueil des besoins implique une bonne compréhension des métiers concernés. Réaliser un logiciel pour une banque, par exemple, implique la connaissance du domaine bancaire et l’intégration de toutes les contraintes et exigences de ce métier.

Cette condition est nécessaire pour bien cerner les cas d’utilisation exprimés par le client afin d’apporter les solutions adéquates.

Chaque cas a ses particularités liées au métier du client. Le recueil des besoins peut s’opérer de différentes façons. Cela dit, il est recommandé de compléter le cahier des charges par des discussions approfondies avec le maître d’ouvrage et les futurs utilisateurs du système. Il convient également d’utiliser tous les documents produits à propos du sujet (rapports techniques, étude de marché…) et d’étudier les procédures administratives des fonctions de l’entreprise qui seront prises en charge par le système. La question que doit se poser le maître d’oeuvre durant le recueil des besoins est la suivante :

ai-je toutes les connaissances et les informations pour définir ce que doit faire le système ?

2. Le diagramme de cas d’utilisation

2.1. Les cas d’utilisation

Parlons à présent d’UML et voyons quelle aide il peut apporter lors du recueil des besoins. UML n’est qu’un langage et il ne sert ici qu’à formaliser les besoins, c’est-à-dire à les représenter sous une forme graphique suffisamment simple pour être compréhensible par toutes les personnes impliquées dans le projet. N’oublions pas que bien souvent, le maître 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. Ils permettent de recenser les grandes fonctionnalités d’un système.

Exemple

La figure 1.1 modélise une borne interactive qui permet d’accéder à une banque. Le système à modéliser apparaît dans un cadre (cela permet de séparer le système à modéliser du monde extérieur). Les utilisateurs sont représentés par des petits bonshommes, et les grandes fonctionnalités (les cas d’utilisation) par des ellipses.

Figure 1.1

Diagramme de cas d’utilisation modélisant une borne d’accès à une banque.

bonshommes sont appelés « acteurs ». Ils sont connectés par de simples traits (appelés « associations ») aux cas d’utilisation et mettent en évidence les interactions possibles entre le système et le monde extérieur. Chaque cas modélise une façon particulière et cohérente d’utiliser un système pour un acteur donné.

Définition

Un cas d’utilisation est une manière spécifique d’utiliser un système. Les acteurs sont à l’extérieur du système ; ils modélisent tout ce qui interagit avec lui. Un cas d’utilisation réalise un service de bout en bout, avec un déclenchement, un déroulement et une fi n, pour l’acteur qui l’initie.

Notation et spécification

Un cas d’utilisation se représente par une ellipse (figure 1.2). Le nom du cas est inclus dans l’ellipse ou bien il figure dessous. Un stéréotype (voir la définition ci-après), peut être ajouté optionnellement au-dessus du nom, et une liste de propriétés placée au-dessous.

Un cas d’utilisation se représente aussi sous la forme d’un rectangle à deux compartiments : celui du haut contient le nom du cas ainsi qu’une ellipse (symbole d’un cas d’utilisation) ; celui du bas est optionnel et peut contenir une liste de propriétés (figure 1.3).

Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous (figure 1.1) ou par un rectangle contenant le stéréotype acteur avec son nom juste en dessous (figure 1.4). Il est recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.

Figure 1.2 et 1.3

Représentations d’un cas d’utilisation.

Figure 1.4

Autre représentation d’un acteur.

La figure 1.4 représente un acteur par un rectangle. UML utilise aussi les rectangles pour représenter des classes, et plus généralement des classeurs. Pour autant, la notation n’est pas ambiguë puisque le stéréotype acteur indique que le rectangle désigne un acteur. Les stéréotypes permettent d’adapter le langage à des situations particulières.

Définition

Un stéréotype représente une variation d’un élément de modèle existant. À un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation d’un système par un simple rectangle. La figure 1.5 montre comment un tel rectangle peut remplacer tous les cas d’utilisation de la figure 1.1.

Figure 1.5

Représentation des cas d’utilisation à un niveau d’abstraction élevé.

Le rectangle de la figure 1.5 est appelé « classeur ».

Définition

Un classeur est un élément de modélisation qui décrit une unité comportementale ou structurelle. Les acteurs et les cas d’utilisation sont des classeurs. Tout au long de ce livre, on retrouvera le terme « classeur » car cette notion englobe aussi les classes, des parties d’un système, etc.

Notation

Un classeur se représente par un rectangle contenant éventuellement des compartiments (la figure 1.6 montre comment il est possible de faire figurer explicitement des cas d’utilisation dans un classeur).

Figure 1.6

Les compartiments d’un classeur.

Un acteur peut utiliser plusieurs fois le même cas d’utilisation.

Exemple

La figure 1.7 montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.

Figure 1.7

Association avec multiplicité.

Le symbole * qui signifie « plusieurs » est ajouté à l’extrémité du cas et s’appelle une multiplicité. Plusieurs valeurs sont possibles pour la multiplicité : exactement n s’écrit tout simplement n, m..n signifie entre m et n, etc. Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.

2.3. Relations entre cas d’utilisation

Pour clarifier un diagramme, UML permet d’établir des relations entre les cas d’utilisation. Il existe principalement deux types de relations : les dépendances stéréotypées et la généralisation/spécialisation. Les dépendances stéréotypées sont des dépendances dont la portée est explicitée par le nom du stéréotype. Les stéréotypes les plus utilisés sont l’inclusion et l’extension.

• La relation d’inclusion . Un cas A est inclus dans un cas B si le comportement décrit par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B dépend de A. Cette dépendance est symbolisée par le stéréotype inclut. Par exemple, l’accès aux informations d’un compte bancaire inclut nécessairement une phase d’authentification avec un mot de passe (figure 1.8).

• La relation d’extension . Si le comportement de B peut être étendu par le comportement de A, on dit alors que A étend B. Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note. La figure 1.8 présente l’exemple d’une banque où la vérification du solde du compte n’intervient que si la demande de retrait d’argent dépasse 20 euros.

• La 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. À la figure 1.8, la consultation d’un compte bancaire 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.

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

Exemple

À la figure 1.9, le modélisateur a jugé que la vente d’un article par correspondance est un problème complexe et qu’il est important de faire apparaître dans le modèle une décomposition en sous-cas.

Notation et spécification

Une dépendance se représente par une flèche pointillée. Un stéréotype est souvent ajouté au-dessus du trait. 

Le stéréotype inclut indique que la relation de dépendance est une inclusion (figures 1.8 et 1.9).

Le stéréotype étend indique une extension (figure 1.8). 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 à une condition (indiquée dans une note attachée à la flèche pointillée).

Le symbole utilisé pour la généralisation est une flèche en traits pleins dont la pointe est un triangle fermé. La flèche pointe vers le cas le plus général (figure 1.8).

Figure 1.8

Relations entre cas dans un diagramme de cas d’utilisation.

Figure 1.9

Relations entre cas pour décomposer un cas complexe.

Un cas relié à un autre cas peut ne pas être directement accessible à un acteur (figure 1.9).

Un tel cas est appelé « cas interne ».

Définition

Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur. Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et d’enrichir les cas d’utilisation. Par exemple, à la figure 1.8, rien n’empêche de regrouper les cas « Consulter comptes » et « Consulter sur Internet » en un seul cas. Cependant, indiquer dès la phase de recueil des besoins qu’il y a des cas particuliers apporte une information

supplémentaire pertinente. La question à se poser est : faut-il la faire figurer dans le diagramme de cas d’utilisation ou la prendre en compte plus tard ? La réponse à cette question ne sera pas toujours la même selon le contexte du projet.

Remarque

Attention à l’orientation des flèches : si le cas A inclut B on trace la flèche de A vers B, mais si B étend A, la flèche est dirigée de B vers A.

2.4. 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 (tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai).

Exemple

La figure 1.10 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). Le préposé aux commandes ne peut pas gérer le stock.

Figure 1.10

Relations entre acteurs.

Notation

Le symbole utilisé pour la généralisation entre acteurs est une flèche en traits pleins dont la pointe est un triangle fermé. La flèche pointe vers l’acteur le plus général. 

2.5. des cas d’utilisation en paquetages

UML permet de regrouper des cas d’utilisation dans une entité appelée « paquetage ». Le regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de cas d’utilisation peut contenir plusieurs paquetages et des paquetages peuvent être inclus dans d’autres paquetages.

Définition

Un paquetage permet d’organiser des éléments de modélisation en groupe. Un paquetage peut contenir des classes, des cas d’utilisations, des interfaces, etc.

Exemple

À la figure 1.11, trois paquetages ont été créés : Client, Stock et Support. Ces paquetages contiennent les cas d’utilisation du diagramme de la figure 1.10 (Client contient les cas « Passer une commande » et « Suivre une commande », Stock contient le cas « Gérer le stock », tandis que le cas « Rechercher article » est inclus dans le paquetage Support.

Figure 1.11

Regroupement des cas d’utilisation en paquetage.

En tant que langage, UML est soumis à des règles de nommage qu’il faut strictement respecter : pour accéder au contenu de paquetages imbriqués les uns dans les autres, il faut utiliser des deux-points comme séparateur des noms de paquetage. Par exemple, si un paquetage B inclus dans un paquetage A contient une classe X, il faut écrire A::B::X utiliser la classe X en dehors du contexte des paquetages.

3. Modélisa tion des besoins avec UML

3.1. Qui sont les acteurs ? Comment les identifier ?

Les principaux acteurs sont les utilisateurs du système. Ils sont en général faciles à repérer. C’est le maître d’ouvrage qui les désigne. Chaque acteur doit être nommé, mais attention, pour trouver son nom, il faut penser à son rôle : un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un système. Ainsi, pour un logiciel de gestion de paie, le nom correct d’un acteur est Comptable plutôt que Mme Dupont. Plusieurs personnes peuvent avoir le même rôle. C’est le cas des clients d’une banque par exemple. Il n’y aura alors qu’un seul acteur. Réciproquement, une même personne physique peut jouer des rôles différents vis-à-vis du système et donc correspondre à plusieurs acteurs.

En général, les utilisateurs ne sont pas difficiles à trouver, mais il faut veiller à ne pas oublier les personnes responsables de l’exploitation et de la maintenance du système. Par exemple, un logiciel de surveillance qui limite les accès à un bâtiment doit avoir un administrateur chargé de créer des groupes de personnes et leur donner des droits d’accès. 

Il ne s’agit pas ici des personnes qui installent et paramètrent le logiciel avant sa mise en production, mais des utilisateurs du logiciel dans son fonctionnement nominal. En plus des utilisateurs, les acteurs peuvent être : des périphériques manipulés par le système ( • imprimantes, robots…) ;

• des logiciels déjà disponibles à intégrer dans le projet ;

• des systèmes informatiques externes au système mais qui interagissent avec lui, etc.

Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout ce qui est à l’extérieur et qui interagit avec le système est un acteur ; tout ce qui est à l’intérieur est une fonctionnalité du système que le maître d’oeuvre doit réaliser.

Un cas d’utilisation a toujours au moins un acteur principal pour qui le système produit un résultat observable, et éventuellement d’autres acteurs ayant un rôle secondaire. Par exemple, l’acteur principal d’un cas de retrait d’argent dans un distributeur automatique de billets est la personne qui fait le retrait, tandis que la banque qui vérifie le solde du compte est un acteur secondaire. En général, l’acteur principal initie le cas d’utilisation par ses sollicitations.

Définition

L’acteur est dit « principal » pour un cas d’utilisation lorsque le cas d’utilisation rend service à cet acteur. Les autres acteurs sont dits « secondaires ». Un cas d’utilisation a au plus un acteur principal, et un ensemble – éventuellement vide – d’acteurs secondaires.

Un acteur principal obtient un résultat observable du système tandis qu’un acteur secondaire est sollicité pour des informations complémentaires.

3.2. Comment recenser les cas d’utilisation ?

Il n’y a pas une façon unique de repérer les cas d’utilisation. Il faut se placer du point de vue de chaque acteur et déterminez comment il se sert du système, dans quels cas il l’utilise, et à quelles fonctionnalités il doit avoir accès. Il faut éviter les redondances et limiter le nombre de cas en se situant au bon niveau d’abstraction (par exemple, ne pas réduire un cas à une action).

Exemple

Considérons un système de réservation et d’impression de billets de train via des bornes interactives situées dans des gares. En prenant pour acteur une personne qui souhaite obtenir un billet, on peut obtenir la liste suivante des cas d’utilisation :

• rechercher un voyage ;

• réserver une place dans un train ;

• acheter son billet.

L’ensemble des cas d’utilisation doit couvrir exhaustivement tous les besoins fonctionnels du système. L’étape de recueil des besoins est souvent longue et fastidieuse car les utilisateurs connaissent l’existant et n’ont qu’une vague idée de ce que leur apportera un futur système ; en outre, le cahier des charges contient des imprécisions, des oublis, voire des informations contradictoires difficiles à extraire. L’élaboration du diagramme de cas d’utilisation permet de pallier ces problèmes en recentrant le système sur les besoins fonctionnels et ce, dès le début du projet.

On peut se demander pourquoi adopter un point de vue fonctionnel, et non technique ? Trop souvent, par le passé, les logiciels étaient techniquement très élaborés sans pour autant satisfaire les utilisateurs. Avec les diagrammes de cas d’utilisation, on se place clairement du côté des utilisateurs. Le côté technique n’est pas oublié mais abordé différemment : les besoins sont affinés lors de l’écriture des spécifications – on parle de spécifications techniques des besoins (voir la section « Description textuelle des cas d’utilisation »).

Remarque

Il ne faut pas faire apparaître les détails des cas d’utilisation, mais il faut rester au niveau des grandes fonctions du système. La question qui se pose alors est de savoir jusqu’à quel niveau de détails descendre ? Si le nombre de cas est trop important, il faut se demander si on a fait preuve de suffisamment d’abstraction. Le nombre de cas d’utilisation est un bon indicateur de la faisabilité d’un logiciel.

Il ne doit pas y avoir de notion temporelle dans un diagramme de cas d’utilisation. Il ne faut pas se dire que l’acteur fait ceci, puis le système lui répond cela, ce qui implique une réaction de l’acteur, et ainsi de suite. Le séquencement temporel sera pris en compte plus tard, notamment dans la description détaillée des cas (voir section 3.3).

L’intérêt des cas d’utilisation ne se limite pas au recueil des besoins. La description des cas d’utilisation peut servir de base de travail pour établir les tests de vérification du bon fonctionnement du système, et orienter les travaux de rédaction de la documentation à l’usage des utilisateurs.

3.3. Description des cas d’utilisation

Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation.

Exemple

L’exemple de la fi gure 1.12 ne permet pas de savoir ce qui entre et ce qui sort du logiciel bancaire : le retrait d’argent se fait-il en euros ou en dollars ? Dans quel ordre les opérations sont-elles effectuées ? Faut-il choisir le montant du retrait avant de choisir le compte à débiter, ou bien l’inverse ? Tous ces détails sont des éléments de spécifi cation. Spécifi er un produit, c’est le décrire de la façon la plus précise possible.

Figure 1.12

Diagramme de cas d’utilisation pour une banque.

Les spécifications peuvent être divisées en deux catégories selon qu’elles sont fonctionnelles ou techniques. Les spécifications fonctionnelles concernent les fonctions du système, la fonction de retrait d’argent par exemple, tandis que les spécifications techniques permettent de préciser le contexte d’exécution du système. Par exemple, le logiciel qui gère la distribution des billets doit être compatible avec tel ou tel système d’exploitation, ou encore, un retrait d’argent doit se faire en moins de 5 secondes.

Les spécifications fonctionnelles découlent directement du diagramme de cas d’utilisation. Il s’agit de reprendre chaque cas et de le décrire très précisément. En d’autres termes, vous devez décrire comment les acteurs interagissent avec le système. 

Exemple

À partir du diagramme de cas d’utilisation de l’exemple précédent, la fi gure 1.13 montre une façon de décrire les interactions entre le guichetier et le système. On y voit clairement apparaître une séquence de messages.

Le graphisme utilisé fait partie du formalisme des diagrammes de séquence .

Figure 1.13

Description d’un cas d’utilisation par une séquence de messages.

Les différentes façons de décrire les cas d’utilisation

UML n’impose rien quant à la façon de décrire un cas d’utilisation. Au lieu d’utiliser une séquence de messages, il est possible d’utiliser les diagrammes d’activités d’UML. Cette liberté de choix peut être déroutante, mais comme UML est censé pouvoir modéliser tout type de système, une manière unique de décrire un cas ne suffirait pas.

Remarque

Une des forces de la notation UML est de proposer de nombreux types de diagrammes qui mettent en avant des aspects diff érents d’une description. Ainsi, le modélisateur peut utiliser le type de diagramme qui lui paraît le plus adapté pour représenter son problème (et sa solution), tout en restant dans la norme.

Description textuelle des cas d’utilisation

Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est recommandé de rédiger une description textuelle car c’est une forme souple qui convient dans bien des situations. Une description textuelle couramment utilisée se compose de trois parties, comme le montre l’exemple suivant. La première partie permet d’identifier le cas. Elle doit contenir :

• le nom du cas ;

• un résumé de son objectif ;

• les acteurs impliqués (principaux et secondaires) ;

• les dates de création et de mise à jour de la description courante ;

• le nom des responsables ;

• un numéro de version.

La deuxième partie contient la description du fonctionnement du cas sous la forme d’une séquence de messages échangés entre les acteurs et le système. Elle contient toujours une séquence nominale qui correspond au fonctionnement nominal du cas (par exemple, un retrait d’argent qui se termine par l’obtention des billets demandés par l’utilisateur). Cette séquence nominale commence par préciser l’événement qui déclenche le cas (l’utilisateur introduit sa carte bancaire par exemple) et se développe en trois points :

• Les pré-conditions . Elles indiquent dans quel état est le système avant que se déroule la séquence (le distributeur est alimenté en billets par exemple).

• L’enchaînement des messages.

• Les post-conditions . Elles indiquent dans quel état se trouve le système après le dérouement de la séquence nominale (une transaction a été enregistrée par la banque par exemple).

Parfois la séquence correspondant à un cas a besoin d’être appelée dans une autre séquence (par exemple quand une relation d’inclusion existe entre deux cas d’utilisation).

Signifier l’appel d’une autre séquence se fait de la façon suivante : « appel du cas X », où X est le nom du cas.

Les acteurs n’étant pas sous le contrôle du système, ils peuvent avoir des comportements imprévisibles. La séquence nominale ne suffit donc pas pour décrire tous les comportements possibles. À la séquence nominale s’ajoutent fréquemment des séquences alternatives et des séquences d’exceptions . Ces deux types de séquences se décrivent de la même façon que la séquence nominale mais il ne faut pas les confondre. Une séquence alternative diverge de la séquence nominale (c’est un embranchement dans une séquence nominale)

mais y revient toujours, alors qu’une séquence d’exception intervient quand une erreur se produit (le séquencement nominal s’interrompt, sans retour à la séquence nominale).

Exemple

Dans le cas d’un retrait d’argent, des séquences alternatives se produisent par exemple dans les situations suivantes :

• Le client choisit d’effectuer un retrait en euros ou en dollars.

• Le client a la possibilité d’obtenir un reçu.

Une exception se produit si la connexion avec le système central de la banque qui doit vérifier la validité du compte est interrompue.

La survenue des erreurs dans les séquences doit être signalée de la façon suivante : « appel de l’exception Y » où Y est le nom de l’exception.

La dernière partie de la description d’un cas d’utilisation est une rubrique optionnelle. Elle contient généralement des spécifications non fonctionnelles (ce sont le plus souvent des spécifications techniques, par exemple pour préciser que l’accès aux informations bancaires doit être sécurisé). Cette rubrique contient aussi d’éventuelles contraintes liées aux interfaces homme-machine (par exemple, pour donner la possibilité d’accéder à tous les comptes d’un utilisateur à partir de l’écran principal).

Description d’un retrait d’argent Identification

Nom du cas : retrait d’espèces en euros.

But : détaille les étapes permettant à un guichetier d’eff ectuer l’opération de retrait d’euros demandé par un client.

Acteur principal : Guichetier.

Acteur secondaire : Système central.

Date : le 18/02/2005.

Responsable : M. Dupont.

Version : 1.0.

Séquencement

Le cas d’utilisation commence lorsqu’un client demande le retrait d’espèces en euros.

Pré-conditions

Le client possède un compte (donne son numéro de compte).

Enchaînement nominal

1. Le guichetier saisit le numéro de compte client.

2. L’application valide le compte auprès du système central.

3. L’application demande le type d’opération au guichetier.

4. Le guichetier sélectionne un retrait d’espèces de 200 euros.

5. L’application demande au système central de débiter le compte.

6. Le système notifie au guichetier qu’il peut délivrer le montant demandé.

Post-conditions

Le guichetier ferme le compte.

Le client récupère l’argent.

Rubriques optionnelles

Contraintes non fonctionnelles

Fiabilité : les accès doivent être extrêmement sûrs et sécurisés.

Confidentialité : les informations concernant le client ne doivent pas être divulguées.

Contraintes liées à l’interface homme-machine

Donner la possibilité d’accéder aux autres comptes du client.

Toujours demander la validation des opérations de retrait.

La séquence nominale, les séquences alternatives, les exceptions, etc., font qu’il existe une multitude de chemins depuis le début du cas jusqu’à la fin. Chaque chemin est appelé « scénario ». Un système donné génère peu de cas d’utilisation, mais, en général, beaucoup de scénarios.

Remarque

Parfois, les utilisateurs ont du mal à décrire un cas sous une forme textuelle. Il est alors judicieux de se servir d’une autre forme de description, en utilisant un organigramme ou encore en construisant des maquettes des interfaces homme-machine. Le dessin, même sommaire, de l’aspect des écrans des interfaces permet de fixer les idées ; il offre une excellente base pour la discussion avec le maître d’ouvrage, qui le considère comme plus « parlant ».

Conclusion

Les phases de recueil des besoins et d’écriture des spécifications sont longues et fastidieuses. Mais quand elles sont bien menées, elles permettent de lever toutes les ambiguïtés du cahier des charges et de recueillir les besoins dans leurs moindres détails. Les spécifications permettant d’approfondir les besoins (on parle d’ailleurs à juste titre de spécifications techniques des besoins), la frontière entre ces deux notions est floue.

Il n’est pas question à ce moment de la modélisation de limiter les besoins. Du côté du maître d’oeuvre, la tendance est à les limiter à des fonctionnalités essentielles, tandis que le maître d’ouvrage, et surtout les utilisateurs, ont tendance à en exprimer bien plus qu’il n’est possible d’en réaliser. Le maître d’oeuvre doit faire preuve ici de patience et mener la phase de spécifications de tous les besoins jusqu’à son terme. C’est à ce moment seulement, que des priorités sont mises sur les spécifications. Le maître d’oeuvre tente alors d’agencer les besoins de façon cohérente et fait plusieurs propositions de solutions au maître d’ouvrage, qui couvrent plus ou moins de besoins. UML ne propose rien pour mettre des priorités sur les spécifications.

Le diagramme de cas d’utilisation est un premier modèle d’un système. Que savons nous sur le système après avoir créé ce diagramme ? Sur le système lui-même, en interne, pas grand-chose à vrai dire. C’est encore une boîte noire à l’architecture et au mode de fonctionnement interne inconnus. Donc, a fortiori, à ce stade, nous ne savons toujours pas comment le réaliser. En revanche, son interface avec le monde qui l’entoure est partiellement connue : nous nous sommes placés du point de vue des acteurs pour définir les spécifications fonctionnelles. Il faut s’attarder un instant sur l’expression « partiellement connue » pour mesurer les limites du modèle des cas d’utilisation. Les spécifications fonctionnelles disent ce que le système doit faire pour les acteurs. En d’autres termes, nous connaissons précisément ce qui entre et ce qui sort du système, mais, en revanche, nous ne savons toujours pas comment réaliser cette interface avec l’extérieur.

L’objectif de cette phase de la modélisation est donc de clairement identifier les frontières du système et les interfaces qu’il doit offrir à l’utilisateur. Si cette étape commence avant la conception de l’architecture interne du système, il est en général utile, quand la réflexion est suffisamment poussée, de poser les bases de la structure interne du système, et donc d’alterner analyse des besoins et ébauche des solutions envisagées. 

Aux spécifications fonctionnelles s’ajoutent des spécifications techniques qui peuvent être vues comme des exigences pour la future réalisation.