Analyse : cas d'utilisation et activités

Qu'est-ce que l'Analyse ?

Les différentes phases du développement

Dans le cadre d'un projet, on peut distinguer différentes étapes :

  1. Analyse : déterminer ce qu'on veut faire.
  2. Conception : déterminer comment faire.
  3. Implémentation : traduire les étapes précédentes en code, i.e. faire,
  4. Intégration et Déploiement : intégrer le code produit (livrables) au projet puis le pousser en production.
  5. Maintenance : évolution du code après sa mise en production (e.g. corrections de bugs, ajouts de fonctionnalités).

À ces différentes étapes, on ajoute des phases de tests (vus en cours d'Automatisations et Tests en Programmation), afin de garantir la qualité et conformité du code produit.

La planification de ces différentes étapes dépend du cycle de développement (modèle en cascade, cycle en V, cycle itératif, etc) choisi. Les différents cycles de développement seront étudiés en Gestion de Projets (deuxième partie de ce cours).

Objectifs de l'Analyse

L'étape d'analyse, i.e. déterminer de ce qu'on veut faire permet de cadrer le projet afin d'éviter de partir dans tous les sens, voire dans la mauvaise direction. Elle sert notamment d'échanger avec le client autours de ses besoins et contraintes, afin de produire un cahier des charges qui spécifie ce qui devra être fait, et aura valeur contractuelle.

Lors de cette étape, il est important de distinguer les envies du client de ses besoins. Il est en effet important de ne pas trop anticiper d'hypothétiques besoins futurs, qui prendront du temps de développement, risquent de complexifier le code, et constitueront du code supplémentaire à maintenir. Cela impacte donc les phases de conception, implémentation, et maintenance. Il ainsi est souvent préférable d'implémenter de telles fonctionnalités par la suite, lorsque le besoin se manifeste réellement. C'est le principe YAGNI (You ain't gonna need it) : tu ne vas pas en avoir besoin.

Un projet informatique a des ressources limitées (temps, personnes), il est ainsi fréquent de ne pas pouvoir tout faire. Or, selon la loi de Pareto, ~20% des fonctionnalités répondent à ~80% des usages. Il est ainsi nécessaire de prioriser les besoins, afin de se concentrer sur les plus importants. Une stratégie est alors de déterminer l'ensemble minimal des fonctionnalités nécessaires au produit, le MVP (Minimum Viable Product), afin d'obtenir un produit exploitable le plus rapidement possible. Il est ensuite possible de faire évoluer le produit en fonction des retours, ou lui ajouter de nouvelles fonctionnalités par cycles itératifs.

Il est aussi possible de réaliser des maquettes, prototypes, ou preuves de concepts (PoC - Proof of Concept) pour faciliter les échanges avec le client sur la base d'éléments plus tangibles. On se concentre alors plus sur la structure visuelle de l'interface graphique, en simulant grossièrement les différentes actions. Par exemple, certaines maquettes pouvent se limiter à de simples slides de présentations.

UML

UML est un langage de modélisation graphique fournissant 14 types de diagrammes. Ces diagrammes sont utilisé à la fois pour réfléchir, communiquer, et documenter. Bien évidemment, ces diagrammes sont à utiliser en fonction des ressources et contraintes du projet. Un code de TP produit en 2 minutes dans le cadre d'un exercice, n'aura pas les mêmes contraintes qu'un code critique d'une centrale nucléaire.

Ainsi, même si UML est très utile en soit, tous les diagrammes ne le sont pas nécessairement pour tous les projets. Il convient donc de ne pas trop abuser de UML (death by UML fever).

Les cas d'utilisation

Le cahier des charges décrit, entres autres, les différentes fonctionnalités de système par le biais de cas d'utilisation. Un cas d'utilisation (use case) décrit, en langage non technique, un ensemble d'actions du système en vue d'une finalité. Il décrit notamment ses interactions avec les différents acteurs (≈ rôle assumé par une entité externe au système), e.g. :

"Passer commande : l'utilisateur rempli son panier, puis le valide avant de procéder au payement. Si l'utilisateur n'est pas connecté, une authentification lui sera demandée lors de la validation du panier."
Une action utilisateur, e.g. ajouter un produit au panier n'est pas une finalité en soit.

Dans ce cadre, UML fournit le diagramme de cas d'utilisation, pour représenter graphiquement et synthétiquement la liste des cas d'utilisation décrits dans le cahier des charges. Il permet ainsi d'échanger sur (et de réfléchir aux) différents usages et acteurs du système.

Bien évidemment, ce diagramme est peu utile si vous n'avez que peu de cas d'utilisation et/ou d'acteurs.

Formalisme

En UML, une flèche dont la pointe est un triangle creux indique une spécialisation (cf héritage en POO). Elle indique qu'un acteur (ou cas d'utilisation) étend un autre, i.e. qu'il en est une sous-catégorie.

Les acteurs supports sont des acteurs qui assistent ou administrent le système. Par convention, ils sont placés à droite du système.

Les pseudo cas d'utilisation ne sont pas des cas d'utilisation en soit, mais peuvent être ajoutés à la liste des cas d'utilisation du cahier des charges. Je les représente via un ovale pointillé afin de les distinguer.

Il existe aussi un lien équivalent à un avec condition. Cependant, je n'en recommande pas l'usage, car trop ambiguë (confusion avec l'héritage, et sens de la flèche trompeur).

Conseils

Le diagramme de cas d'utilisation sert à échanger avec le client, notamment afin d'en identifier les besoins non-exprimés. Dans ce cadre, il est important d'adopter le langage et le vocabulaire du client.
Attention de ne pas se perdre dans des détails ne relevant pas des fonctionnalités essentielles du projet.
Aussi, Les diagrammes de cas d'utilisation doivent rester lisibles et visuels. Pour cela on peut :
  1. Indexer les cas d'utilisation, e.g. "1.2 Visualiser un produit", afin de le retrouver plus facilement dans le CdC.
  2. Utiliser des codes couleur, e.g. pour indiquer le niveau de priorisation (e.g. pour le MVP).
  3. Découper en sous diagrammes, e.g. par acteurs ou groupes de fonctionnalités, pour rester lisible.

Activités

Chaque cas d'utilisation doit ensuite être décrit individuellement, notamment en en décrivant la procédure, i.e. les différentes étapes, vérifications, conditions, etc. L'objectif est encore d'échanger avec le client, afin d'expliciter le processus métier et son fonctionnement.

Pour décrire visuellement un cas d'utilisation, il est possible d'utiliser un diagramme d'activité où chaque noeud correspond à une action :

Une action est indépendante de l'interface graphique. Il ne faut ainsi pas mettre, i.e. "clic sur le bouton confirmer", mais "confirmation".

Formalisme

Il existe aussi d'autres symboles utiles, bien que moins fréquents :

Événements
Le sablier représente une attente (généralement en temps), quand la réception d'un signal peut soit être l'attente d'un signal (si flèche entrante), ou la réaction à un signal (sinon).
Interruptions

Une zone interruptible, représentée en pointillés, est une zone dont les actions peuvent être interrompus, e.g. erreur, annulation de l'activité, etc.

L'interruption, représentée par une flèche en éclair, pointe vers les actions à effectuer en cas d'interruption.

Partitions

Les partitions divisent le diagramme en zones, chacune correspondant e.g. à un acteur. Cela est permet d'insister sur qui effectue l'action.

Les données échangées lors des communications entre acteurs peuvent être représentés via un rectangle.

Sous-activité

Une sous-activité permet de regrouper une sous-partie du diagramme d'activité, au sein d'un ensemble cohérent, afin d'en améliorer la lecture.

Vous noterez qu'on utilise alors des symboles de début/fin de flux au lieu des symboles de début/fin d'activités.

Draw.io

Pour des diagrammes complexes et/ou instables, les schémas sur papiers montrent vite leurs limites. On utilise alors des logiciels de dessins numériques.
Fonctionnalités de draw.io :