[UML] Modélisation appli de gestion du temps

Bonjour,

Je suis en charge de la conception et du développement d'une appli de gestion du temps et des demandes d'absence pour les collectivités locales. Par manque de pratique, je me heurte à des petits pb de conception qui paraitront, je l'espère, triviaux pour certains d'entre vous.

En résumé, les besoins exprimés sont les suivants :
L'appli doit permettre à chaque agent de saisir ses heures de présence, ainsi que faire des demandes d'absence (congés, formation, événements familiaux).
Le chef de service accepte ou refuse (avec motif) la demande.
Le responsable du personnel paramètre l'appli, gère la base de données Agents et produit des stats.

Ceci me conduit donc à définir 3 acteurs :
- l'agent de la collectivité
- son chef de service
- le responsable du personnel

Premier problème :

Pour ce qui est de la gestion des demandes d'absence, dois-je traiter 2 cas d'utilisation ?
- cas 1 : l'agent utilise l'appli pour saisir une demande d'absence
- cas 2 : le chef de service utilise l'appli pour gérer les demandes d'absence qui lui sont faites.
Ou bien ne faut-il tenir compte que d'un seul cas, dans lequel l'agent est l'acteur principal qui initie la demande et le chef de service fait partie de ce cas en tant qu'acteur secondaire qui reçoit la demande et qui la traite ?

Second problème :

Il s'agit du second cas d'utilisation de l'acteur "agent" : saisir ses heures de travail. J'ai du mal à trouver quelle est ou quelles sont les classes conceptuelles (les objets métier) que l'on peut proposer pour ce cas d'utilisation. Peut-être essayé-je de modéliser quelque chose qui ne peut pas l'être. Peut-être au contraire est-ce quelque chose de bien connu et même qu'un p'tit design pattern bien rodé existe exprès pour ça.

Y a-t-il des gourous UML dans la salle ?

Merci pour vos lumières.
Christophe

Bonjour,
Je vous rassure, tout de suite, je ne suis pas un Gourou de l'UML... ;)

Citation:

---

Envoyé par Cespiau

Premier problème :

Pour ce qui est de la gestion des demandes d'absence, dois-je traiter 2 cas d'utilisation ?
- cas 1 : l'agent utilise l'appli pour saisir une demande d'absence
- cas 2 : le chef de service utilise l'appli pour gérer les demandes d'absence qui lui sont faites.
Ou bien ne faut-il tenir compte que d'un seul cas, dans lequel l'agent est l'acteur principal qui initie la demande et le chef de service fait partie de ce cas en tant qu'acteur secondaire qui reçoit la demande et qui la traite ?

---

Pour ma part, je retiendrai la démarche des acteurs liés mais de même niveau.
L'acteur "agent" "commande" des absences, les articles de la commande sont "mis en attente" de validation par l'acteur "chef de service". L'évenement "validation" déclenche la possibilité de "visibilité" de la "commande" pour l'acteur "responsable du personnel"
Pour votre second problème, j'avoue ne pas identifier clairement la nature même de votre dilemne. Pourriez-vous être plus explicite?
Personnellement, je considére que le temps est un objet comme un autre il est muni de caractéristiques (... heures, minutes, secondes, ...) comme mon auto est munie de portières, siéges, volant...Chaque accteur "conducteur" a ses méthodes de conduite, chaque univers a ses méthodes d'emploi du temps

• Travail
  Congés
  RTT
  Absences
  Vacances
  Machine à café
  Conversation triviale avec une collègue de bureau ;)
  Colportage de potins et autres médisances ;)
  ...

Pour l'heure, les seules difficultées que j'entrevoie ne concernent que l'implémentation de l'historisation des emplois du temps -Notez qu'on ne se rouve plus en MCD mais en MPD à ce moment là -. Mais comme je vous le disez, je ne suis pas sûr d'avoir bien compris le sens de votre interrogation.
Cordialement,
Hauwke

Merci pour votre vision des choses en ce qui concerne le cas d'utilisation "commander des absences". Ca me conforte dans l'idée que la seconde solution est la bonne.
Un cas d'utilisation est donc bien une intention métier (obtenir une autorisation d'absence). Autrement dit, ce n'est pas juste une fonctionnalité (l'agent se connecte et saisit un formulaire de demande d'absence .... fin de l'UC), mais une série de fonctionnalités (l'agent crée sa demande, le chef de service la reçoit et la traite, l'agent obtient une réponse positive ou négative).

Quand au second problème, il s'agit pour l'agent de saisir son temps de présence sur le lieu de travail. L'appli doit être en plus paramétrable de façon à offrir soit la saisie de 1 ou plusieurs plages horaires, soit la saisie d'une durée de travail dans la journée. La question que je me pose est : quel classe va pouvoir représenter ce temps de présence au travail ?
Mais c'est peut-être à moi de réfléchir un moment au problème.

En tout cas, je suis encore une fois preneur de toute suggestion.

Christophe

Bonsoir,

Citation:

---

Envoyé par Christophe

Quand au second problème, il s'agit pour l'agent de saisir son temps de présence sur le lieu de travail. L'appli doit être en plus paramétrable de façon à offrir soit la saisie de 1 ou plusieurs plages horaires, soit la saisie d'une durée de travail dans la journée. La question que je me pose est : quel classe va pouvoir représenter ce temps de présence au travail ?

---

Dans ce cas précis, l'univers modéle c'est le temps lui même. c'est lui qui a le rôle principal. Je crois que je créerai une Méta-Classe "emploi du temps" et que je la doterai d'une tribu d'enfants "vacances", "Rtt", "Congé Maladie", "Congé maternité"... chacun de ces rejetons n'ayant qu'un message à deux états (actif, inactif). Chaque état étant doté d'une condition de gestion "vraie du temps N au temps N+1"
Il ne me reste plus qu'a écrire le message:
La classe vacances [instance Jean Dupont, ID 860542], statut:
vrai= Date_début 12/07/2006;
faux=Date_sortie 12/08/2006;(pour une reprise le 11/08/06)
Il ne reste plus à la Méta-classe "Emploi du temps" qu'a doté le message d'un Id afin de permettre un réemploi de la classe sans doublon et d'assurer la persistence du message à des fins de traitement ultérieur par un autre processus métier.
Mais je le répéte, je ne suis pas un gourou de l'Uml, loin s'en faut! Par contre le développeur qui sommeille en moi se frotte les mains en se disant: "toutes les classes qui ne surchargent qu'une seule et même méthode: Fastoche!" :)
Cordialement,
Bruno

Citation:

---

Envoyé par Hauwke

Je crois que je créerai une Méta-Classe "emploi du temps" et que je la doterai d'une tribu d'enfants "vacances", "Rtt", "Congé Maladie", "Congé maternité"... chacun de ces rejetons n'ayant qu'un message à deux états (actif, inactif). Chaque état étant doté d'une condition de gestion "vraie du temps N au temps N+1"

---

Etant donné que les "enfants" présentes strictement les même caractéristique et puis surtout représente la même chose, c'est superflu de faire de l'héritage. "Vacances", "RTT", etc ce ne sont pas des types propres mais plutôt le contenu d'une activité dans le temps.
Je propose plutôt une classe "Activité" (ou tout autre nom plus adéquat) avec un attribut "type d'activité" qui lui contient vacances, rtt ou autre. "date de début, "date de fin" et tout ce qui peut être utile pour caractériser une activité.


P.S. : une métaclasse est une classe qui modélise une classe, pas un parent dans une relation de généralisation (héritage).

Merci à tous les deux pour cet échange.

Je vais voir si j'arrive à mes fins avec cette classe Activite (pour l'instant ce nom-là convient parfaitement). C'est une suggestion forte intéressante qui va me permettre d'avancer.
A moi de voir si je vais pouvoir l'utiliser pour répondre au besoin de saisie du temps de travail sous forme du durée (7 heures) au lieu de plages horaires (8h30 - 12h, 14h00 - 17h30). Peut-être faut-il que je demande au "client" s'il souhaite vraiment cette 2de possibilité de saisie.

A+
Christophe

Bonjour!

Je viens apporter mon petit grain à la réponse :

1. Activite est une bonne idée, c'est même ce qu'il faut.
2. Pour la gestion des périodes, c'est pas très compliqué (enfin il sembleait en tout cas) :
2.1 Au niveau de l'IHM, il faut rendre paramétrable la durée de temps de travail (on sait jamais, si l'administration passe un jour à 8h... :wink: dsl, petite boutade...), et tu la stocke qq part (par ex, un fichier .ini).

2.2 Dans ta classe Activite, tu crée un attribut 'durée' que tu initialise via le constructeur avec le valeur du paramètre.

2.3 La classe Activite n'a pas besoin de contenir d'heure de début et de fin (s'il était besoin de le préciser) vu qu'on ne fonctionne pas par plage, et ça n'est pas grave, car j'imagine que dans ce cas, ce que l'on veut au final n'est pas un planning détaillé, mais un bilan de rendement en qq sorte (estimer le temps qu'il nous reste à passer sur une tâche, savoir si on a débordé et de combien, etc.).
CONSEIL : Penser à se reconcentrer régulièrement sur le besoin réel du client et se demander pourquoi exactement il souhaiterait quelque chose qui va à l'encontre de la "Best Solution" imaginée par le développeur. Sinon, on finit par pondre une appli qui ne fait pas exactement ce que le client veut, ce qui, à mon sens, est + grave que de ne pas pouvoir implémenter le meilleure des solutions.
Ceci dit, si vous en êtes au cahier des charges ou à la conception, l'informaticien a bien entendu un devoir de conseil.

2.4 Les méthodes de la classes devront ensuite se baser sur cette unité pour les éventuelles conversion (si l'utilisateur saisit ses activités sous forme de % ou de décimale [ex: 'modification planning' le 22/11/05 = 21%, ou 0,2jour]). Ceci est une idée d'utilisation, mais je pense que c'est le problème que cela te pose.

Pourquoi j'ai insisté sur le besoin client?
Parce que si vous cherchez à imposer au client de saisir son planning par plages précise alors qu'il s'en fout, il passera + de temps que nécessaire à saisir ses activités, il rouspètera à la moindre occassion, et finira probablement par ne plus le remplir exhaustivement voire irrégulièrement, ce qui ne produira pas les délivrables attendus.

Si vous voulez + d'infos sur les plannings, ou sur nos méthodes de travail, de liaison client/analyste, n'hésitez pas à m'envoyer un message!


Pour info, j'utilise à mon boulot MADERE, une adpatation Web permettant d'accéder aux plannings de MSProject. On fonctionne comme le client décrit par durée et non par plages. Cela ne pose aucun souci particulier.


Sur ce, bon courage et bonne réussite!

Nicolas Tarbouriech.[/list]