Discussion :

[benf35]

Bonjour,

J'ai à réaliser une série de cas d'utilisation à faire, et j'ai quelques problèmes pour les concevoir.

• Tout d'abord, j'hésite entre faire un seul "gros" cas d'utilisation, ou le découper en plusieurs selon les différents utilisateurs. Et en cas de découpage, je fais un cas d'utilisation par acteur?
  
• Ensuite, j'ai un soucis, notamment concernant le CRUD. Est-il préférable de faire, pour un acteur, gérer les employés par exemple, ou bien détailler chaque cas, ajouter employé, modifier, rechercher, supprimer, consulter... ou même valider un employé.
  
• Comment représenter le fait qu'il faille attendre la validation d'autres acteurs, pour que l'acteur principal puisse faire une autre action. (par exemple pour que l'acteur principal puisse affecter un employé à un projet, il faut que son responsable ait valider la création de cet employé?

Merci pour toute aide, conseil!

[tonton16]

Bonjour,

Personnellement, je travaille sur plusieurs niveaux. Tout d'abord, je vais rechercher les cas d'utilisation que je traduirais de "niveau utilisateur" dans lequel je vais rechercher les cas généraux dans la la plupart des cas commenceront par "gérer...". Ceci à l'intérêt de proposer une vision synthétique pour le futur utilisateur.
Ensuite, pour chacun de ces cas, je descend d'un niveau et je vais étudier les sous-fonctionnalités et donc décrire le CRUD : créer... , modifier... supprimer... et faire ressortis les actions communes type rechercher... à l'aide d'un <<include>>.

Pour le dernier point, il faut se rappeler qu'un cas d'utilisation est accompagné par une fiche de description qui va contenir les différents scénarios du cas. Parmi les informations de la fiche, sont nécessaires : l'acteur principal, les-préconditions et les post-conditions. Ce que tu décris est en fait une pré-condition du cas d'utilisation : donc pour le cas d'utilisation "affecter un employé à un projet" une de ses pré-conditions est que "le responsable a validé la création de cet employé"...

[benf35]

Merci pour la réponse, je vais essayer de le faire sur plusieurs niveaux alors, du cas général au particulier.

Une autre question; dois-je préciser si l'acteur ne peut modifier que les objets qu'il a créé et non tous les objets?

[tonton16]

C'est effectivement une contrainte qui peut être ajoutée à la description.

[ego]

c'est un petit détail mais qui permet de ne pas faire jouer trop de rôles à nos bons UC.
Je préfère créer des packages de UC pour les fameux "niveau supérieur" et donc réserver les UC pour les "niveaux inférieurs".

Ensuite, quand on a à faire du CRUD, le plus important est de faire un diagramme de classes pour savoir de quoi on parle exactement. Les UC deviennent "évident" ensuite, même si dans certains cas il y a de nombreuses règles de gestion que tu vas exprimer dans tes UC et qui donc, rendrons tes UC un peu plus complexe que : L'utilisateur renseigne les informations concernant XXX, le système vérifie les données obligatoires a,b,c,... et enregistre s'il n'y a pas d'erreur