Définition des cas d’utilisation

Nous voilà dans notre première phase de listing de cas d’utilisation et je dis première parce qu’il va y en avoir pas mal à mon avis.

En commençant la préparation du projet et de ma démarche telle que je vous la présente, j’avais déjà tenté de créer quelques petits visuels possibles de l’application. Voilà un exemple avec une potentielle vue de gestion de téléchargement de données historiques :

Alors, soyez rassurés je ne vais pas du tout afficher les choses comme ça, j’ai déjà d’autres idées et je compte vous montrer d’autres visuels un peu plus user friendly, mais prenons ce visuel pour avoir quelques premiers cas d’utilisation possibles.

On peut déjà lister ceux-ci :

  • Voir la liste des Plateformes d’échange
  • Sélectionner une plateforme d’échange
  • Voir la liste des marchés d’une plateforme d’échange
  • Sélectionner un marché d’une plateforme
  • Voir la liste des timeframes disponible d’un marché d’une plateforme
  • Sélectionner une timeframe
  • Lancer le Téléchargement 

Voici ce que ça donne sur un schéma UML. Notre acteur primaire est le Trader et notre application c’est le Système avec lequel l’acteur primaire interagit.

Maintenant il est important de pouvoir définir ce que ces actions et interactions impliquent, soit de manière optionnelle, soit de manière inclusive.

Vous allez voir que beaucoup de choses vont être interconnectées.

Détailler les cas d’utilisation

Nous sommes en phase d’Inception, donc notre travail c’est de détailler ce que chaque action implique pour savoir ce qu’il faudra créer et développer.

Prenons comme exemple le use case “Voir la liste des plateformes” :

Si on veut pouvoir “Voir” la liste des plateformes cela implique qu’on ait accès à cette liste. Cette action inclut donc qu’on télécharge/charge la liste des plateformes et dans le diagramme cela s’afficherait comme ceci :

On crée un autre use case et on établi une relation inclusive entre les deux. La position et le sens de la flèche détermine quel use case inclus l’autre.
Du coup, on avance d’un pas en avant, on sait que charger la liste des plateformes sera une action à détailler, ce sera un futur Use Case à définir. Mais comment est-ce que je sais si je dois le définir maintenant ou plus tard ?

Dans notre cas, notre Acteur interagit avec l’interface graphique de l’application et non pas avec le coeur de l’application lui même. Cette interface fait partie intégrante de notre application, mais pour garder les choses simple, je ne vais pas détailler cela maintenant.

De relation en relation, on remarque que chaque action est dépendante des autres pour cette situation ci.

Si on veut “Sélectionner” une plateforme, on devrait pouvoir “Voir” cette liste et donc “Charger” cette liste. Même chose pour la liste des marchés d’une plateforme. Ainsi de relation en relation, on va pouvoir déterminer chaque cas d’utilisation suffisamment en détail pour générer d’autre besoins et d’autre cas d’utilisation qu’on détaillera et qu’on développera dans d’autre itération du projet.

Et voilà ce que ça donnerait en bout de course (en ajoutant le use case du lancement du téléchargement) :

Chaque fonctionnalité décrite par les use case qu’on vient de créer appartient à notre Système. Elles interagissent entre elles dans un même cadre, la gestion des Données Historiques. On peut dès lors se demander si le Système dans lequel on évolue pourrait être intégré dans un package qui englobe toutes ces fonctionnalités.

Je ne vais pas lister toutes les fonctionnalités ici, cet article sert à introduire notamment la schématisation des Cas d’Utilisation. Ceci dit lors de l’Élaboration nous aurons la possibilité d’organiser toutes les fonctionnalités en différents packages capables d’interagir entre eux.
Un package rassemble un ensemble de fonctionnalités ayant une base commune, c’est une sorte de Système dans le Système.

D’ailleurs, dans les itérations suivantes on pourra décrire plus en détail chaque package, l’Élaboration nous permettra de savoir quel package on doit créer pour répondre à nos besoins.

Pour donner un exemple simple, lorsque le téléchargement des données historiques est lancé, une des étape de l’algorithme est de sauvegarder les données en base de données. Il faudra donc un package capable d’exécuter des requêtes, créer des bases de données, les configurer, créer des tables, etc… 

Dans les prochains articles je ferai la liste des fonctionnalités en repartant comme aujourd’hui d’une base visuelle de l’interface graphique afin d’avoir un support intéressant sur lequel on peut s’appuyer pour visualiser le fonctionnement de l’application.

Merci d’avoir lu cet article jusqu’au bout, j’espère que cela vous aura plu. 

Si vous avez des questions ou des suggestions, n’hésitez pas à vous inscrire et poster des commentaires !

A la prochaine !