Discussion :

[Braillane]

Bonjour,
Je suis en train de réalisé un dossier d'analyse conception pour mon appli.
C'est un logiciel de planning. Le principe est que, de base, j'ai un administrateur qui crée des employé et leur attribue des droits. Un utilisateurs peut attribuer tout les droits (si il en a le droit ^^) qu'il possède lui meme.
On a une multitude de droit différent (modifier un planning, ajouter un employé, ajouter des droits etc...). En bref, un administrateur est un employé qui a tout les droits. Un employé qui a tout les droits ne se distingue aucunement d'un administrateur.
Combien ai-je d'acteurs principaux dans mon use case du coup? Un seul?(si on considère que l'admin est en fait un employé...). Deux?

Comment je représente sa dans mon use case? Parce que en fait un employé sera relié à toutes les taches mais sa ne veut pas dire qu'il peut tout faire...

Ma solution à moi: Je n'ai qu'un seul acteur, employé, qui est relié à toutes les taches et toutes les taches sont relier (<<include>>) au cas d'utilisation "s'identifier". Comme sa en quelque sorte "s'identifier" conditionne la réalisation du cas d'utilisation en disant "à condition que l'identification lui en donne les droits"?
Je débute en UML, est-ce bien comme sa qu'il faut faire??
Le fait de relier tout les cas à "s'identifier", ne va t'on pas penser que à chaque fois que je veux faire un truc je dois m'identifier (alors qu'on s'identifie uniquement en début de session).

Merci d'avance!

[wiztricks]

Conceptuellement administrateurs et employés auront des fonctions différentes dans l'organisation. Ces fonctions leur donneront (ou pas) accès à certaines opérations.

Ce qui milite à la définition d'acteurs différents pour rendre compte de leurs rôles respectifs.

Ceci dit, l'administrateur a certainement accès à toutes les opérations que pourra effectuer un employé lambda. Dit comme çà, l'acteur "administrateur" dérive de l'acteur "employé".
=> Pas besoin dans ce cas de répéter les liaisons entre "l'acteur employé" et les différents UC auquel il a "droit".

Simple mais cela ne répond pas à votre question: si l'exécution des différentes opérations est "contrôlée" par un droit d'accès spécifique.

Comment s'en sortir?

Complexifions.
Ajoutons Mr le Chef d'Equipe. Il aura des employés sous sa responsabilité et pourra modifier leur planning. Il aura donc le "droit" d'effectuer les opérations correspondantes sans pour autant être administrateur...
Nouveau rôle définit par un acteur qui accède à certains UCs non accessibles par "employé". Il pourra aussi dériver d'"employé" - comme "Administrateur".

En définitive, nous avons des rôles (qui correspondent à des acteurs) et des responsabilités qui "impliquent" de pouvoir dérouler les opérations qui vont bien.
Si nous voulons que:

• employés
• chefs d'équipe
• administrateurs,
• ...

puissent faire leur boulot... ll faudra bien leur donner accès aux opérations correspondantes. Acteurs et opérations auxquelles ils accèdent recouvre un aspect "fonctionnel".

Le contrôle, s'assurer que l'utilisateur lambda a effectivement le droit d'effectuer l'opération qu'il souhaite est un aspect "non fonctionnel".

"Comment" implémenter cela:

• Une opération = un droit particulier qu'on assigne ou pas à chaque utilisateur.
• Un rôle = la possibilité d'effectuer un ensemble d'opération <=> des listes de droits particuliers correspondantes

Personnellement, je préfère 2.

Côté use case, cela ne mérite pas plus qu'une ligne dans les pré-requis du scénario correspondant. On vérifie que l'utilisateur est { employé, chef d'équipe, ou administrateur }.
Côté code, il sera préférable de vérifier le droit d'exécuter l'opération "créer employé" avant de la lancer.
=> Cela n'empêche pas de définir des droits suivant 1 ou d'associer à un utilisateur les droits correspondants à chef d'équipe +...

Un autre conséquence est que "login/logout" sera un "use case" important puisque c'est à ce moment qu'on donnera les droits d'accès.
Enfin ce ne sont que des idées.
Cordialement
- W