Admin CliCours
L’énoncé est suffisamment vague pour donner lieu à de nombreuses interprétations. Cela est typique d’une spécification textuelle des besoins, telle qu’on en trouve dans un cahier des charges. La solution proposée ici fixe donc un certain nombre de choix d’organisation de la procédure.
On se concentre sur la partie concernant l’authentification de l’utilisateur, et la création d’un compte le cas échéant.
L’organisation proposée correspond à une interface de type « wizard » : il faut valider tous les champs d’une page, cliquer sur Suivant, pour passer à la validation des prochains champs. Si les informations sont incorrectes, un message avertit l’utilisateur et l’écran suivant s’affiche. Cette vérification des champs n’est donc pas représentée ici : il revient à l’activité de saisie de se terminer quand la saisie est validée.
Chaque activité correspond donc assez bien à un écran d’interface, les transitions exprimant une navigation possible entre ces écrans. Vous pourrez réutiliser ces activités ailleurs. Par exemple, la modification de l’adresse de livraison est accessible depuis un menu quand l’utilisateur est connecté à son compte.
Ce niveau de description est bien adapté à la description d’interfaces homme-machine et permet de se concentrer sur la vision logique d’un traitement, sans se perdre dans le modèle structurel en classes.
