Discussion :

[Hari Seldon]

Bonjour,

Un collègue m’a soumis un petit cas de développement juste pour le fun ce n’est pas professionnel. Je suis plutôt autodidacte en programmation, je travaille essentiellement sur Access et je travaille sans trop de méthode et je sens bien qu’en fonction des projets je ne suis pas rentable.
Je me suis dis que ce petit projet sera l’occasion d’acquérir un peu plus de méthode, le projet étant assez simple. J’ai trouvé un livre « Modélisation objet avec UML » de Pierre-Alain Muller. Je vous avouerais que je n’ai pas tout lu. Je suis un peu perdu, je pense qu’il me faudrait un peu de recul.

Commençons pas le début le sujet est le suivant « a partir d’un planning de repas à la semaine midi et soir, l’outil doit générer la liste de course associée », j’ai don construit un diagramme de cas d’utilisation comme suit :



J’ai suivit les consignes, il faut rester sur les fonctions globales dans « Gestion des plannings » on trouve les fonctions CRUD de même que pour les recettes et les produits.

Ma première interrogation se situe sur les liens entre les cas d’utilisation. Pour créer un planning il faut pouvoir créer des recettes, pour créer des recettes il faut pouvoir créer des produits. Je ne vois pas trop comment les intégrer dans ce diagramme. Peut-on faire un lien entre « Gestion des plannings » et « Gestion des recettes » ?
Dois-je faire un diagramme plus détaillé ou plusieurs diagrammes séparées ?

Ma deuxième interrogation se situe sur l’étape suivante. La littérature conseille d’écrire les scénarii des cas d’utilisations. Là je suis un peu perplexe on passe à un niveau de détail beaucoup plus profond. Peut-être que j’ai mal compris ou qu’il me manque une étape ?



Je suis un peu long je le sais, mais tous vos conseils sont les bienvenue. Merci d’avance.

[rad_hass]

Tu rentre déjà dans le détail ...

Les cas d'utilisation doivent exprimer le point de vue du client (la maîtrise d’ouvrage par exemple) ... Et il défini les fonctionnalités du logiciel sans rentrer dans le détail (juste fonctionnel).

Tu peux définir des liens d'inclusions mais seulement si ton premier cas englobe le second et qu'il le déclenche ... Or, ici ce sont des actions distinctes bien que l'une est un pré-requis du second, dans ton système l'utilisateur peux se connecter et effectuer une seul action ...
La description d'un cas d'utilisation n'est souvent pas détaillée ...

[Hari Seldon]

Merci pour ta réponse, il semble que je soit sur le bon chemin.
Concernant le scénario qu'en pense tu, faut-il à ce stade rentrer dans les détails et décrire les échanges entres l'acteur et le système ? J'ai l'impression de définir les fonctionnalité de l'IHM (je clique sur un planning dans une liste, l'interface m'affiche les infos puis je modifie, le système valide puis enregistre ....) ?

[Hari Seldon]

Si j'ai bien compris chaque cas d'utilisation doit être accompagner d'une description textuelle.
Dans la partie description des trois cas d'utilisations "gérer des plannings", "gérer des recettes" et "gérer des produits", j'imagine que je doit parler des fonctions CRUD que je détaille dans les scénarii ?
Quel est votre avis

[hegros]

C'est un scénario système dans ton cas cela sera probablement une IHM puisque tu développes un logiciel pour un utilisateur sous windows...


Ce n'est pas seulement les fonctins CRUD. Tu peux voir un use case comme une carte qui regroupe plusieurs sections.

I apparaît le déclencheur du cas, les pré/post conditions, les acteurs puis et surtout les scénarios d'usage et d'exception(modélisable avec un diagramme d'activité)

A ce stade tu pourrais compléter avec une maquette écran et un diagramme de classe haut niveau et ensuite entrer dans le détail mais bon chacun fait comme il veut