Le seul acteur est le client.
L’acquisition d’une carte et sa recharge ne se font pas via le distributeur : il faut aller au magasin. Ces fonctions ne donnent pas lieu à des cas d’utilisation.
Il ne faut pas faire apparaître un séquencement temporel dans un diagramme de cas d’utilisation. On ne fait donc pas figurer les étapes successives telles que l’introduction de la carte puis le choix d’une cassette, etc. Ce niveau de détails apparaîtra quand on décrira les cas d’utilisation (sous forme textuelle par exemple). Dans un diagramme de cas d’utilisation, il faut rester au niveau des grandes fonctions et penser en termes de transactions (une transaction est une séquence d’opérations qui fait passer un système d’un état cohérent initial à un état cohérent final).
Il n’y a donc que deux cas : « Emprunter une vidéo » et « Restituer une vidéo » (figure 1.22)
Nom de l’acteur Rôle
Client Représente un client du magasin de location de cassettes vidéo
Pour décrire le cas « Emprunter une vidéo », imaginons un scénario possible. Le client introduit sa carte. Il doit ensuite pouvoir choisir une vidéo. Quels sont les critères de choix ? L’énoncé ne précise pas ces critères. Ce problème arrive fréquemment en situation réelle.
Le maître d’ouvrage dans un projet informatique de cette ampleur est bien souvent le propriétaire du magasin de location. Il sait rarement rédiger un cahier des charges. C’est le rôle du maître d’œuvre d’obliger le maître d’ouvrage à bien formuler ses besoins. Choisir une vidéo peut être complexe : la recherche se fait-elle par genres, par titres ou par dates de sortie des films en salles ? Si la recherche se fait par genres, quels sont-ils ? Rechercher un film semble plus complexe qu’on ne l’imaginait au premier abord. De plus, cette fonctionnalité peut être isolée de la location proprement dite, qui concerne plutôt la gestion de la carte. Ces remarques incitent à créer le cas supplémentaire « Rechercher une vidéo ». L’emprunt d’une vidéo inclut sa recherche. Une relation d’inclusion intervient donc entre les cas « Emprunter une vidéo » et « Rechercher une vidéo », comme le montre la figure 1.23.
À ce point de la modélisation, deux remarques s’imposent :
• Le succès d’UML en tant que langage de modélisation s’explique, entre autres, par le fait qu’il oblige le modélisateur à poser les bonnes questions au bon moment ; la modélisation vient à peine de commencer que déjà des questions se posent. Il faut cependant veiller à rester au niveau du recueil des besoins et des spécifications et ne faire aucun choix de conception du système. Il faut se contenter de décrire les fonctions du système sans chercher à savoir comment les réaliser.
• Le problème des critères de recherche a conduit à une révision du diagramme de cas d’utilisation. Cet « aller-retour » sur les modèles est nécessaire. Chacun d’eux apporte des informations complémentaires qui peuvent remettre en cause les modèles existants. Une fois tous les modèles établis, la modélisation sera alors aboutie.
