Discussion :

[mossane]

Bonjour,

Je dois modéliser un module de gestion de la classification des corps dans une administration. Les corps sont subdivisés en plusieurs classes qui peuvent contenir elles-même un certain nombre d'échelons. L'application doit permettre d'ajouter de nouveaux corps, de modifier des corps existants ou d'en supprimer. On doit aussi pouvoir créer une classe et la rattacher à un corps (ou créer un échelon et l'ajouter à une classe), la modifier par la suite ou la supprimer (Idem pour l'échelon).

Par ailleurs, les corps sont regroupés dans des cadres, appartiennent à des catégories et à des hiérarchies. Par exemple le corps des instituteurs est placé dans le cadre "Enseignement général", appartient à la catégorie des "Fonctionnaires" et à la hiérarchie "B3".

J'ai réalisé le diagramme de cas d'utilisation suivant:



Pour ne pas surcharger le diagramme, je n'ai pas ajouté la généralisation des cas "Ajouter", "Modifier" et "Supprimer" pour les autres cas. Les relations "extend" que j'ai définies sont-elles bien justifiées ?

Merci !

[goldray]

Bonjour,
Voici une proposition plus adéquate :
Pour les CU : Ajouter, Modifier et consulter => il faudra créer un CU :consulter corps (par exemple)

gérer cadres --->(include) gérer corps----->(include) consulter corps----->(extend)ajouter corps ...
Gérer cadres---->(include)consulter cadres (à mon avis, on peut consulter la liste des cadres)

Juste pour information, en cas où il y en a une CU complexe tel que gérer cadres, on peut la décomposer en sous CU tels gérer corps et consulter liste des cadres.
Pour la relation (extend), elle est utilisée sous condition par exemple si l'utilisateur clique sur le bouton "ajouter".
Pour la relation de généralisation (héritage), elle est peu utilisé au niveau de diagramme des CU. exemple : paiement par carte bancaire, paiement par chèques (ces deux cas ont des traitements et des information communs).

Bonne chance.

[mossane]

Bonjour goldray,

Votre réponse m'a permis de mieux m'y retrouver. Aussi, j'ai repris le diagramme en prenant en compte vos suggestions.



Je n'ai pas représenté tous les CU Ajouter, Modifier ... J'espère que j'ai été fidèle aux suggestions et que le diagramme est assez correct dans l'ensemble.

Merci !

[goldray]

Bonsoir,

Voici quelques remarques et questions :
1- pour le CU afficher ... c'est le même que le CU consulter .. Donc vous devez éliminer le CU afficher ..(une sorte de redondance).
2- j'ai remarqué l'absence de la phase d'authentification et d'inscription pour les utilisateurs du SI !!
Pa exemple, un tel utilisateur peut effectuer une telle tâche que s'il est authentifié.
3-pour les CU consulter liste des classes, si le CU consulter liste échelons peut se produire suivant une condition (vous devez imaginer la conception des interfaces de votre application, par exemple nous sommes au niveau de l'interface consulter liste des classes et si on clique sur un tel bouton tel que "détails" ou "liste des échelons" dans ce cas vous devrez utiliser une relation conditionnelle "extend" entre les 2 CU.

Récap, essayez d'éliminer les CU afficher ...
Les CU gérer catégories et hiérarchies, ne sont pas détaillés ..

Voici une proposition pour améliorer la lisibilité du diagramme :
Essayez de faire un diagramme des CU global (contenant les tâches globales ou principales).
Et pour chaque CU global, vous pouvez faire un diagramme de CU détaillé.

Bonne chance.

[mossane]

Bonsoir goldray,

Je vous remercie pour votre disponibilité.

Voici quelques remarques et questions :
1- pour le CU afficher ... c'est le même que le CU consulter .. Donc vous devez éliminer le CU afficher ..(une sorte de redondance).

Dans mon raisonnement, je me disais que le CU "Consulter liste cadres" va nous permettre d'obtenir la liste de tous les cadres (mais sans les détails). Ainsi, à coté de chaque cadre, on aura les boutons "Afficher", "Modifier" et "Supprimer". L'exécution du CU "Afficher cadre" ne survient qu'après clic sur un bouton "Afficher" et nous donne les détails du cadre concerné tels que son nom, sa description... ainsi que la liste de tous les corps appartenant à ce cadre (et seulement à ce cadre). Il en est de même entre les corps et les classes et, entre les classes et les échelons.

2- j'ai remarqué l'absence de la phase d'authentification et d'inscription pour les utilisateurs du SI !!
Pa exemple, un tel utilisateur peut effectuer une telle tâche que s'il est authentifié.

Peut-être faudrait-il prévoir un module de gestion de l'administration et un module d'authentification ?

3-pour les CU consulter liste des classes, si le CU consulter liste échelons peut se produire suivant une condition (vous devez imaginer la conception des interfaces de votre application, par exemple nous sommes au niveau de l'interface consulter liste des classes et si on clique sur un tel bouton tel que "détails" ou "liste des échelons" dans ce cas vous devrez utiliser une relation conditionnelle "extend" entre les 2 CU.

Si on suit la logique établie entre les cadres et les corps, le CU Consulter liste échelons se produit quand on clique sur le bouton "Afficher" d'une classe dans l'interface Consulter liste classes. On obtient l'interface Consulter liste classe quand on clique sur le bouton "Afficher" d'un corps dans l'interface Consulter liste corps.

Récap, essayez d'éliminer les CU afficher ...
Les CU gérer catégories et hiérarchies, ne sont pas détaillés ..

Voici une proposition pour améliorer la lisibilité du diagramme :
Essayez de faire un diagramme des CU global (contenant les tâches globales ou principales).
Et pour chaque CU global, vous pouvez faire un diagramme de CU détaillé.

D'accord, reprenons le contexte.
Les agents de l'administration sont constitués en corps qui peuvent être groupés dans un cadre unique lorsqu'ils participent au fonctionnement d'un même service administratif. Par exemple le cadre "Enseignement général" regroupe le corps des instituteurs, le corps des professeurs de l'enseignement moyen, le corps des inspecteurs de l'enseignement élémentaire, etc. Indépendamment de leurs cadre d'appartenance, chaque corps se réfère à une catégorie d'agents bien déterminée et à une hiérarchie donnée. Par exemple le corps des secrétaires se réfère à la catégorie des non-fonctionnaires et à la hiérarchie B2.
En outre, chaque corps est subdivisé en classes qui sont elles-même subdivisées en échelons.

Les éléments manipulés dans la classification sont donc les cadres, les catégories, les hiérarchies, les corps, les classes et les échelons. Ces deux derniers éléments n'ont pas d'identité propre. Une classe n'existe que si elle est rattachée à un corps déjà existant. De même un échelon n'existe que si il est rattaché à une classe. Par contre les cadres, les catégories et les hiérarchies ont une identité propre. Un corps aussi doit avoir une identité propre même s'il est rattaché à un cadre et se réfère à une catégorie et une hiérarchie.

Je vais me limiter pour le moment au CU global et au CU Gestion des cadres.

Diagramme de CU global



Deux types d'acteurs vont intervenir dans la gestion de la classification : un chef de division et un agent de bureau. Le chef de division a tous les droits dans le module de classification. L'agent de bureau a tous les droits dans la gestion des corps, classes et échelons, mais il a des droits limités dans les autres cas.

Gestion des cadres



Mes préoccupations sont les suivantes.

1- Le CU "Afficher détails cadre" affiche les détails d'un cadre donné. Parmi les détails, il y a la liste des corps appartenant au cadre affiché. Alors, dans le diagramme de CU global, la relation entre les CU Gestion des cadres et Gestion des corps doit-elle être de type "include" ou "extend" ?

2- Le chef de division a tous les droits dans la gestion des cadres. Par contre, l'agent de bureau peut consulter la liste des cadres, rechercher et afficher les détails d'un cadre, mais il ne peut ni ajouter, ni modifier, ni supprimer un cadre. Par quel CU doit-on le relier ?

3- Si on devait décrire le fonctionnement du CU Gestion des cadres quel serait l'enchaînement nominal et les enchaînements alternatifs ?

Tout est encore confus dans ma tête, mais je vais améliorer au fur et à mesure.

Merci !

[goldray]

Bonsoir,

Vous avez raison de garder les CU afficher ... permettant de détailler une liste.

pour vos questions:
1- le CU afficher détail sera déclencher sous condition (clique sur bouton détails), donc nécessite une relation extend.
RQ: pour la relation include est utilisée dans 2 cas : décomposer une cas global. ou bien dans le cas pour dire que le CU1 est traitée que ssi le CU2 est exécution (exemple, CU1(gérer clients) CU2(authentification) : on peut gérer les clients que ssi on est authentifié).

2- coté application (développement vous devez faire ça). coté conception vous pouvez utiliser une étiquette pour mentionner que l'agent peut seulement consulter une telle liste si non il se peut qu'il y en a une autre solution fournit par UML2( par exemple une telle contrainte).

Pour "le CU rechercher" c'est inutile, c'est déjà inclut dans le CU consulter ou afficher liste. Mais vous pouvez le garder.

pour le diagramme détaillé, gestion des cadres : c'est bien fait à mon avis.
pour le diagramme global, il y en a un lien entre agent de division et gestion des corps c'est inutile puisque ce cas est déjà lié aux cas gestion des cadres ...
D’après ce diagramme (relation de généralisation), le chef et l'agent peuvent faire tous les CUs.

3- j'ai pas bien compris qu'est ce que vous voulez, mais si vous parleriez de description textuelle de chaque tâche global, suivez ce plan d'exécution :
Titre du CU :
Acteur(s) :
Pré-condition : (par exemple : le responsable est authentifié)
Événement déclencheur : (exemple : le responsable sélectionne la rubrique cadres)
Résumé : (par exemple, ce cas par au responsable de consulter, modifier ... un cadre)
Post-condition : (par exemple, s'il y a validation d'une telle opération, le cadre sera mis à jour).

Vous avez mis le CU dans le diagramme détaillé, de préférence il sera mis au niveau diagramme global et négligé coté diagramme détaillé. Si non tant que vous avez utiliser les packages, c'est inutile de faire des CU d'authentification.

à noter, que juste je vous offre mes avis, mes remarques et propositions et non pas des obligations ou un ordre, donc à vous d'interpréter la proposition la plus logique et adéquate.

Bonne chance.

[mossane]

Bonjour goldray,

Un grand merci à vous. Vos suggestions et propositions m'ont permis d'y voir un peu plus clair. Je pense que je vais pouvoir me débrouiller pour la suite.

Merci !