Cours UML le cas d’utilisation d’une vente de produits, tutoriel & guide de travaux pratiques UML en pdf.

Anecdote pour montrer les buts des cas d’utilisation

Au début des années 90, Ivar Jacobson (inventeur de OOSE, une des méthodes fonda-trices d’UML) a été nommé chef d’un énorme projet informatique chez Ericsson. Sans métho-dologie de travail particulière, ce projet devint rapidement ingérable. Personne ne savait vraiment quelles étaient les fonctionnalités du produit, ni comment elles étaient assurées, ni comment les faire évoluer. Le produit avait été défini à coups de promesses de vente, sans aucun souci de systématique quelconque.
Pour éviter de foncer droit dans un mur et mener à bien ce projet critique pour Erics-son, Jacobson a eu l’idée de redéfinir le projet en termes de besoins des utilisateurs, et d’essayer d’identifier, parmi ces besoins, ceux qui étaient réellement critiques, nécessaires à la viabilité du projet. Ces besoins critiques, une fois identifiés et structurés, devaient permet-tre enfin de cerner « ce qui est important pour la réussite du projet ».
Le bénéfice de cette démarche simplificatrice est double. D’une part, tous les acteurs du projet ont une meilleure compréhension du système à développer, d’autre part, les besoins des utilisateurs, une fois clarifiés, serviront de fil rouge, tout au long du cycle de développe-ment. A chaque itération de la phase d’analyse, on clarifie, affine et valide les besoins des uti-lisateurs ; à chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs et à chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
La détermination et la compréhension des besoins sont souvent difficiles car les inter-venants sont noyés sous de trop grandes quantités d’informations. Or, comment mener à bien un projet si l’on ne sait pas où l’on va ? La démarche d’Ivar Jacobsson est un exemple de démarche centrée sur les cas d’utilisation.
Pour la petite histoire, signalons que le projet fut une réussite.
Conclusion :
Il faut clarifier et organiser les besoins des clients (les modéliser).
Jacobson identifie les caractéristiques suivantes pour les modèles :
• Un modèle est une simplification de la réalité.
• Il permet de mieux comprendre le système qu’on doit développer.
• Les meilleurs modèles sont proches de la réalité.
Les use cases permettent de modéliser les besoins des clients d’un système et doivent aussi posséder ces caractéristiques. Ils ne doivent pas chercher l’exhaustivité, mais clarifier, filtrer et organiser les besoins ! Une fois identifiés et structurés, ces besoins :
• définissent le contour du système à modéliser (ils précisent le but à atteindre),
• permettent d’identifier les fonctionnalités principales (critiques) du système.
Les use cases ne doivent donc en aucun cas décrire des solutions d’implémentation. Leur but est justement d’éviter de tomber dans la dérive d’une approche fonctionnelle, où l’on liste une litanie de fonctions que le système doit réaliser.
Bien entendu, rien n’interdit de gérer à l’aide d’outils (Doors, Requisite Pro, etc…) les exigences systèmes à un niveau plus fin et d’en assurer la traçabilité, bien au contraire. Mais un modèle conceptuel qui identifie les besoins avec un plus grand niveau d’abstraction reste indispensable. Avec des systèmes complexes, filtrer l’information, la simplifier et mieux l’organiser, c’est rendre l’information exploitable.

Eléments des cas d’utilisation

Les cas d’utilisation énumèrent toutes les interactions possibles entre de système et son environnement extérieur. A cet effet, on définit des acteurs, censés être initiateurs d’actions, et le cas Acteur d’utilisation lui-même. L’acteur est en principe extérieur au système, délimité par ses bornes. L’acteur a un nom, qui le définit, ou qui précise son rôle dans la transaction décrite.
Le cas d’utilisation est représenté par une ellipse, dont le contenu est un texte décrivant le cas d’utilisation. Au besoin, on pourra préciser le cas d’utilisation par une boîte de commentaires.
Une boîte de commentaires est reliée au cas d’utilisation par une ligne traitillée. Nous allons retrouver cette syntaxe tout au long des divers diagrammes de UML.
Les acteurs et les cas d’utilisation, ainsi que les cas d’utilisation entre eux, sont reliés par des liaisons indiquant leurs dépendances mutuelles. Une liaison sera généralement commentée. Le commentaire est indiqué entre << et >>, et indique le type de dépendance de manière informelle (inclut, déclenche, entraîne, etc…).

………