Discussion :

[wperle]

Salut,

j'essaye de modéliser une application de gestion des clubs, pour mon mon projet de fin de formation.

Pour améliorer le modele j'attends vos critiques.

Pour eclaircir le scénario d'affiliation et la réaffiliation des clubs, le processus est comme suit :
un club dépose son dossier au bureau d'ordre auprès de la fédération.
Le bureau d'ordre (BO) enregistre le dossier dans un repertoire et lui attribue un numéro d'enregistrement. et renvoi le dossier à la direction administrative (DA) pour lui informer sur dossier. la DA redirige le dossier vers la commission des statuts et reglements (CSR) pour le traiter. En cas du dossier complet le CSR attribue au club un code, le crée sur le système et envoi une lettre de bienvenue au club, dans le cas contraire le CSR rejette le dossier et envoi le dossier + une lettre pour lui expliquer la cause du rejet.

Pour le renouvellement c'est même processus sauf que le dossier est un peu différent.

Renouvellement : pour un club existant il doit se renouveller annuellement.
Affiliation : pour un nouveau club
Réaffiliation : pour un club qui a été en stand by pour une période donnée.


Merci d'avance

[wperle]

Merci de me donner vos remarques.

[ze_corsaire]

Pour la forme, préférer des verbes à l'inifinitf pour les UC.
Le club n'intéragit pas directement avec le système, ce n'est pas un acteur.
C'est le Biarritz Olympique qui saisit la demande auprès du Système.
La granularité est trop basse, exemple de description de l'UC traiter la demande :
1/ la DA envoie le dossier à la CSR
2/ - ou bien la CSR valide le dossier
- ou bien elle la rejette
3/ le BO est notifié de la modification du dossier

Rejeter ou valider le dossier ne sont donc pas des UC à part entière mais seulement des interactions, comme attribuer numéro ou code ...

__________

[wperle]

J'ai amélioré mon cas d'utilisation. merci de me parvenir tes remarques. Ce que j'ai compris que je ne dois pas trop détaillé.

[ze_corsaire]

Je note certaines incohérences dans la notation :
- la seule relation permise entre 2 acteurs est l'héritage (dans tons cas, il ne devrait pas y en avoir)
- une relation en "pointillés" entre un acteur et un UC n'existe pas non plus

Sur le fond, j'avais déjà fait la rq sur le club, qui pour moi n définit pas un acteur, c'est le BO qui fait le demande d'inscription.
Je ne vois que 3 UCs :
- traiter la demande
- transférer la demande
- demander une affiliation (renouvellement en flux alternatif)
(+1 optionnel : s'authentifier)

être informé ne peut définir un UC, ça traduit plutôt le fait qu'il faille rajouter l'acteur concerné à un autre UC ...
Je me poserais d'autres questions, est-ce que le BO ne doit pas être informé du traitement de la demande d'affiliation (car c'est le BO "l'interface" avec le club qui reviendra au BO pou voir comment sa demande évolue), ou à défaut pouvoir consulter le dossier à partir de sa référence pour en suivre l'évolution (UC qui pourrait être étendu au club finalement).
Est-ce que le BO est le seul à pouvoir saisir/modifier le dossier ?

_________

[wperle]

Bonjour ze_corsaire,

Merci beaucoup pour tes pertinentes remarques entre nous c'est pour la première fois que j'utilise UML et je souhaiterais bien m'entrainer (auto formation).

Pour mon étude de cas :

Normalement ce qui se passe pour un club pour être affilier :

- Le club dépose son dossier au BO.
- Le BO enregistre dans un registre juste la date du dépôt+le numéro d'ordre, et redirige le dossier vers la DA (Direction Administrative) juste pour l'informer.
- DA redirige le dossier vers le service Relations avec les ligues et clubs (SRLC) pour le traiter.
- SRLC traite le dossier et c'est lui qui informe sur l'état du dossier.

J'ai refais mon cas d'utilisation.

Thanks for help.

[ze_corsaire]

Mon avis est le suivant :
- Un seul UC "gérer les affiliations" (avec un include depuis "traiter la demande")
- Manque "transmettre la demande" avec la DA

Et une question pour la route, comment le club sait-il s'il a obtenu son affiliation ? A mon sens, le BO doit avoir un droit de regard sur les affiliations.

Je pense que pour définir de bon UCs, la démarche est de les décrire en parallèle par des diagrammes de séquence niveau système.


_______

[wperle]

Merci de voir le schéma en pièce jointe, j'ai changé suite à tes remarques.

Et une question pour la route, comment le club sait-il s'il a obtenu son affiliation ? A mon sens, le BO doit avoir un droit de regard sur les affiliations.

Très bonne question. Actuellement c'est le SRLC (Service Relations Clubs et ligues) envoi une lettre de bienvenue au club. Il sera une amélioration sur le système par le faite que le bureau d'ordre doit avoir un œil de consultation sur la situation d'un club donnée.

[ze_corsaire]

Personnellement je regrouperais tout ce qui est "affiliation" dans un même UC et je ferais disparaitre l'Aviser club.

Bon we.
_____

[wperle]

Bonjour ze_corsaire,

Je penses que j'ai commencé à comprendre les uses cases. Merci de me donnée ton avis, le document est en pièce jointe.

[ze_corsaire]

C'est conforme à mon idée (verbes à l'infinitif : "s'authentifier").

Continue ! (avec les diagrammes de séquence haut niveau, échanges système <-> utilisateurs).

_______