Les cas d'utilisation forment aujourd'hui la clé des développements "objet" et leur traçabilité. Même si, à strictement parler, ils traduisent les fonctions d'un système, leur mise en oeuvre n'est pas une approche fonctionnelle, au sens informatique du terme, du système. En effet, les cas d'utilisation sont reliés à des acteurs, ce qui n'est pas le cas d'une approche classique. De plus les cas d'utilisation sont constitués d'interactions entre acteurs et système, pas d'opérations réalisées par le système. Toutefois, les relations définies dans UML entre cas d'utilisation (à savoir <<include>>, <<extend>>  et la généralisation) peuvent préter à confusion. Cet essai tente de faire le point sur ce sujet.

Contenu

• Quelques définitions
• Typer les acteurs et les cas d'utilisation
• Besoins fonctionnels et non-fonctionnels
• Business modeling et cas d'utilisation
• Cas d'utilisation et traçabilité
• Conclusion

Quelques définitions

Cas d'Utilisation

Un cas d'utilisation est constitué  d'un ensemble d' interactions entre acteur(s) et système. Cette caractéristique est extrèmement importante : les cas représentent des interactions. Ainsi, l'un des pièges dans l'écriture de la description textuelle des cas est de rentrer dans le système plutôt que de rester à la frontière. Les cas sont  une modélisation du système d'un point de vue externe. Dans une vision "objet" du logiciel, le système peut être vu comme un objet d'un système englobant, les acteurs comme d'autres objets. Les cas d'utilisation modélisent  alors les relations ou collaborations entre ces objets sous forme de description d'interactions. Dans les diagrammes, les acteurs sont les classifieurs qui représentent les rôles  au travers d'une certaine utilisation (cas).  Parmi les questions relatives aux cas, la détection du déclencheur des interactions (acteur,  système) et  le/les acteur(s)  bénéficiaire(s)  du cas permettent de mieux cerner la valeur ajoutée du cas. Ainsi, les descriptions des interactions peuvent être modélisées sous forme de diagramme d'interaction. La différence avec la description textuelle réside dans la nature de la description : un texte est plus informel, plus lisible pour un non-informaticien.
Les cas d'utilisation sont exclusifs les uns les autres. Autrement dit, le système est dans l'une des situations d'utilisation, pour un acteur donné et à un instant donné. Un cas couvre ainsi une utilisation complète depuis la connexion jusqu'à la déconnexion.

Valeur ajoutée du cas d'utilisation

Communication entre acteurs et cas

Relations entre cas d'utilisation

La relation stéréotypée <<extend>> permet d'étendre les interactions et donc les fonctionnalités décrites par les interactions. Cette relation est typique d'une situation optionnelle dans les interactions :
Tel acteur a le choix parmi :
    x) -- ici renvoi vers la description consignée dans le cas "qui étend" --
La relation <<include>> suppose une obligation d'exécution des interactions, ces interactions sont probablement partagées entre plusieurs cas ; la relation <<extend>>  montre une possibilité d'exécution d'interactions qui améliorent les fonctionnalités du cas étendu, de façon optionnelle. Cela se traduit d'une part dans l'étiquette de la relation qui définit la condition d'extension, d'autre part par le point d'extension : indication de la plage dans laquelle l'extension est possible (par exemple: avant telle interaction).

La relation d'héritage ou de généralisation entre cas est plus subtile. La version 1.1 de UML ne distinguait d'ailleurs pas <<extend>> et généralisation. Cette relation est à prendre au sens classique de spécialisation, inhérent à 'héritage. Ici, la généralisation peut être vue aussi comme un "polymorphisme" de cas. Autrement dit, de même qu'une opération peut être polymorphe, de même les interactions qui définissent un cas peuvent prendre plusieurs formes et devenir de plus en plus complexes par exemple. De même qu'un objet de sous-classe peut être considéré aussi comme instance de la sur-classe, de même un scénario induit par le sous-cas d'utilisation peut être accompli dans le cadre de l'utilisation décrite par le sur-cas d'utilisation. Dans un système d'agence de voyage, un acteur touriste peut participer à un cas de base qui est "Réservation", ce qui suppose par exemple des interactions graphiques au comptoir de l'agence. Une réservation peut aussi être réalisée par téléphone ou internet. Il ne s'agit pas de relation <<extend>> car la réservation par internet n'étend pas les interactions ni les fonctionnalités du cas 'Réservation". Elle les traduit différemment. Les interactions Internet ne sont pas une option des interactions Comptoir. Par contre les deux cas "Réservation" et "Réservation par Internet" sont liés: internet est un cas particulier de réservation.

Pondération des cas d'utilisation

Les cas d'utilisation du système seront réalisées grâce à la collaboration d'une société d'objets qu'il reste à analyser, concevoir,  conformément à l'architecure. C'est le coeur de l'approche objet.

Typer les acteurs et les cas d'utilisation
Les acteurs peuvent être stéréotypés :

• Principal
• Secondaire

Dans le même temps :

• Humain
• Système (matériels, logiciels).

Les acteurs principaux sont  généralement humains. Il reste toutefois à préciser ces types d'acteurs car, après tout, pourquoi ne pas imaginer un système construit pour un acteur principal qui serait un autre système matériel ou logiciel ? Autrement dit, quel est le critère majeur : l'importance de l'acteur ou  son humanité ?
Les acteurs principaux sont les bénéficiaires du système. Ce sont eux qui recoivent la valeur ajoutée ; c'est pour eux que le système est construit, payé.
Secondaire signifie que le système n'est pas construit spécifiquement pour eux, mais plutôt que ces acteurs sont nécessaires au bon fonctionnement du système. C'est le cas général des exploitants. Dans cet ordre d'idée une solution pour les systèmes de type Temps Réel consiste par exemple à créer un acteur Temps qui peut être stéréotypé par une icône "horloge". Cet acteur agirait alors en tant que déclencheur de cas, dont les bénéficiaires seraient d'autres acteurs. Les cas d'utilisation permettent de créer le dialogue entre utilisateurs et informaticiens : tout le reste est à prendre avec circonspection. En effet, la phase suivante d'analyse est là pour affiner le "quoi" du système. De façon générale, elle met en jeu des outils bien plus complets : panoplie des diagrammes UML par exemple, qui sont très utiles aux informaticiens et aussi illisibles par les utilisateurs. C'est ce qui en limite l'utilisation dans le modèle des cas.
UML permet de distinguer les acteurs. D'une part il est toujours possible de stéréotyper, soit par label soit plus visuellement par icône. D'autre part, le placement des acteurs dans les diagrammes constitue en  lui-même une indication. Par exemple, les acteurs principaux sur la gauche, les acteurs secondaires sur la droite des ellipses dans le diagramme de contexte système.
Par ricochet, les cas d'utilisation dont un acteur principal est directement bénéficiaire devient aussi cas d'utilisation principal. Idem pour les acteurs secondaires en termes de déclenchement ou de bénéfice.
Restent les cas obtenus dans un second temps qui n'interviennent dans le système qu'au travers de relations <<include>> ou <<extend>>. Ces cas sont utiles en tant que regroupement d'interactions destinées à être mises en jeu via d'autres cas principaux ou secondaires. Ces cas pourraient être stéréotypés <<Interactions>>  (par exemple) pour indiquer le fait qu'ils ne sont ni principaux ni secondaires.

Besoins fonctionnels et non-fonctionnels
De façon générale, les besoins ou exigences exprimés par les utilisateurs peuvent se classer en:

• Fonctionnel
• Non-fonctionnel ou technique.

Les besoins fonctionnels sont modélisés sous forme de cas d'utilisation. Ici, fonction est à prendre au sens "fonctionnalité majeure" du système. Ce que doit faire le système est par nature fonctionnel.

Comment modéliser les besoins non-fonctionnels en UML ?
Premièrement, il faut se souvenir que tout ne peut pas être "raisonnablement" modélisé par UML ou du moins qu'un document textuel est quelquefois à préférer à un formalisme  comme UML. Ceci étant, injecter des spécifications non fonctionnelles dans des diagrammes  permet de synthétiser l'ensemble des besoins dans un seul type d'artefact ou document. Cela devrait faciliter en particulier la traçabilité car le nombre de sources est ainsi réduit.

Qu'offre UML ? Tout d'abord les diagrammes de cas d'utilisation. Ce type de diagramme peut être annoté via le mécanisme commun de notes ; c'est informel mais cela permet d'introduire des informations dans tous les diagrammes, pour tous les éléments, donc en particulier pour les cas d'utilisation. UML permet aussi de stéréotyper des notes <<Exigences>> . Dans ce cas, la note est plus formelle : elle devient une notation de modélisation au même titre que les autres. UML offre ensuite les mécanismes d'extension tels que étiquettes et contraintes. Ces mécanismes sont pertinents pour spécifier des caractéristiques associées aux besoins telles que degré de disponibilité, temps de réponse, solutions imposées ... Ici, une étiquette peut faire référence à un document applicable. Enfin, UML offre aussi d'autres diagrammes, en particulier les diagrammes de séquence qui permettent visuellement de mettre l'accent sur le temps et - via les contraintes également - de préciser des informations telles que des contraintes temporelles.  UML admet aussi  des diagrammes d'état associés à des cas d'utilisation. Ce type de formalisme permet par exemple de préciser des modes dégradés dans les systèmes.  Si les différents intervenants comprennent la langue UML, tous les diagrammes permettent de préciser tel ou tel point des spécifications et deviennent utiles dès la phase d'expression de besoins.

Ainsi, le modèle de cas d'utilisation tel qu'il est proposé dans le Unfied Process comprend les éléments suivants.

• Diagrammes de cas
• Diagrammes Etat/Transition du système d'un cas d'utilisation
• Diagrammes de séquence qui modélisent les interactions acteur(s)/système dans les scénarii spécifiques
• Description textuelle des cas
• Plus ce qu'il est utile de rajouter (autres diagrammes, formalismes annexes, textes ...).

Une remarque importante : le modèle de cas d'utilisation n'est pas le modèle d'analyse. Ce dernier se situe à l'intérieur du système et décrit les objets 'idéaux' ie sans contrainte technique.

Business modeling et cas d'utilisation
Une organisation (une entreprise, un service, une administration ...) est considérée comme un système dans lequel les objets collaborent ... comme dans tout système, d'un point de vue objet. Ici, les objets sont d'ailleurs nommés "Collaborateurs".
Il est donc possible de modéliser les procédures, les flots, les activités d'une organisation grâce à UML. On pourrait  imaginer des diagrammes d'interaction, des diagrammes de classes pour représenter les différents intervenants. UML fournit un ensemble d'éléments de modélisation spécifiques à ces situations. Le document "Process Specific Extensions", qui fait partie de la documentation UML(chapitre 4: Profiles), propose des noms et des notations propres à représenter d'une part des classes d'analyse (les stéréotypes Boundary, Controler, Entity en particulier) et d'autre part des activités d'organisation. Cette dernière caractéristique est appelée "Business Modeling". Le caractère humain des objets à l'intérieur du système entraine la création de types tels que Worker: les collaborateurs à l'intérieur de l'organisation ou bien "work unit" par exemple "livraison". Dans cet ordre d'idée, les acteurs étant toujours externes au système, il s'agit donc des contacts de l'organisation tels que clients, fournisseurs ... Ici, les concepts utilisés dans les cas d'utilisation sont repris et adaptés à la modélisation des activités d'une organisation. Une telle modélisation peut faire appel à l'ensemble des concepts et diagrammes d'UML. En dernière analyse, seuls le périmètre et la nature du système changent.
La méthode Unified Process® propose une étude du domaine  et une étude des activités de l'organisation en terme de préambule à l'expression des besoins du système à construire. Cela permet de découvrir le contexte dans lequel le logiciel prendra place et son impact sur l'organisation. Les objets métier sont également déduits de cette première activité de modélisation.

Cas d'utilisation et traçabilité
Les cas d'utilisation forment le liant des développements. Grâce à la relation <<trace>> entre éléments, il est possible de "suivre" les cas d'utilisation en analyse, conception, programmation, test. A contrario, un élément qui n'est pas relié par <<trace>>  à un cas peut être suspect : quelle est son utilité dans le développement ? Etant donné que les cas peuvent être associés à des documents aplicables via des étiquettes ou des notes, tracer les cas revient aussi à tracer les spécifications initiales.
De façon générale, la relation de collaboration est la clé de la traçabilité : quels sont les classes, composants, tâches ... qui collaborent à tel cas d'utilisation ?
Concrètement, un programmeur devrait avoir "sous les yeux" le cas d'utilisation concerné par son module afin de "penser" à prendre le point de vue de l'utilisateur.

Conclusion
La finalité des cas d'utilisation n'est pas l'analyse précise du système. Il s'agit plutôt de définir les besoins à partir des utilisateurs.
Deux cas de figures. Il existe un document plus ou moins formel et exhaustif de définition de besoins, dans ce cas, le travail consiste plutôt à traduire en cas d'utilisation, ce qui ne dispense pas de cycle de relecture avec les utilisateurs. La question de la valeur ajoutée liée à cette activité se pose alors: la modélisation permet-elle de mieux comprendre, est-ce simplement une traduction, au même titre qu'une traduction en anglais ou espagnol ?
Autre situation: l'étude des cas d'utilisation constitue réellement la découverte des besoins. Dans ce cadre, la technique des cas d'utilisation offre à l'analyste un canevas de questions telles que : quels sont les acteurs (principaux, secondaires) ? quels sont les besoins de synchronisation du système par rapport à son environnement ? ... L'essentiel est  que les utilisateurs, souvent non-informaticiens, aient l'assurance que, grâce aux cas d'utilisation, l'informaticien comprend leurs exigences, leur domaine. A partir de là, tout raffinement dans la présentation peut rapidement se traduire par une perte de temps, sachant que l'activité de découverte des besoins via les cas est suivie de l'activité d'analyse objet. Cette dernière a pour but de préciser ce qu'est le système à construire (le what par opposition au how de la conception). Cela dit, les acteurs, les cas d'utilisation, les relations entre acteurs et cas d'une part, entre cas d'autre part, ont aujourd'hui une définition précise dans UML. Il ne faut donc pas détourner ces éléments de modélisation de leur définition ni de leur finalité. Dans le cas contraire, tout le bénéfice d'une notation standard disparait. C'est pourquoi l'introduction parcimonieuse de stéréotypes "maison" permet de créer - par exemple - de nouveaux éléments de modélisation qui ne risquent pas d'interférer avec telle ou telle définition d'UML. De plus, un nouveau venu sur le projet devra,  même si il/elle maîtrise UML, prendre le temps de lire les définitions de ces éléments stéréotypes. Cela éviterait toute mauvaise interprétation.

L'assurance qualité du projet a un rôle majeur dans l'expression des besoins via les cas d'utilisation.

• Définition des stéréotypes (labels et/ou icônes) d'acteurs, de cas et de notes; par exemple une icône telle que montre pour representer un acteur Temps, un label <<Interface>> pour représenter un cas dont l'objectif est la production de données à interfacer avec d'autres systèmes, <<Exigences>> pour une note qui définit des spécifications de besoins. Ce type de note peut d'ailleurs contenir des références à des documents applicables au projet.
• Définition des contraintes et étiquettes types pour les besoins non-fonctionnels; par exemple {Protocole = x} pour une étiquette ou {Nouvelle image calculée  en moins de 25 ms} pour une contrainte. Ou bien encore {doc applicable=STBxx}
• Règles de dessin des diagrammes de cas pour faciliter la lecture; par exemple, les acteurs toujours à l'exterieur du dessin, les acteurs secondaires sur la droite. Comme pour tous les diagrammes, se demander: quels sont les éléments de dessin qui faciliteront la relecture ?
• Critères de création des diagrammes; par exemple le diagramme de contexte et un diagramme par cas principal qui montre les relations <<extend>> et <<include>> liés à ce cas
• Choix de la présentation-type des descriptions textuelles des cas, règles de partage des descriptions : à partir de 2, 3, 10 pages, la description est découpée et s'appuie sur des relations <<includes>>
• Définition du niveau de détail des interactions: privilégier la sémantique des échanges au style de l'interface (dans le cas général). Si besoin, produire une maquette qui - elle - montre le type d'IHM.

Les cas d'utilisation devraient  être considérés comme un outil de mise au point des besoins des utilisateurs. A ce titre, la simplicité dans les diagrammes, dans les descriptions textuelles devrait être une règle d'or ... Les cas d'utilisation sont aussi au coeur de la traçabilité des développements basés sur la notation UML.

Retour articles UML, objet
Retour page d'accueil
^ the top ^        © 2003 - Contact