Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[DC] Gestion de projet : Héritage et association
Bonjour tous le monde j'ai une question concernant l'héritage et j'espère que vous m'aidez :
J'ai une classe de base nommée "Personne" et deux classes filles "Chef de projet" et "Equipier", normalement les associations appliquées à la classe de base de base sont appliquées aux classes filles, mais est ce ces dernières peuvent avoir des associations avec d'autres classes ou bien c'est toujours la classe mère qui est en relation avec les classes ?
Merci
Je ne suis pas expert en UML mais à quoi servirait de faire une classe fille si on ne peut pas s'en servir ?
Dans l'exemple que tu donnes, je vois même une association évidente entre tes deux classes filles :
'Chef de projet' -1..1---Encadrer---*-'Equipier'
Ensuite on peut imaginer qu'un chef de projet peut gérer un budget mais pas un équipier, que les chefs de projets et les équipiers n'auront pas les mêmes tâches, que les équipiers peuvent eux-mêmes être spécialisés (concepteur, dessinateur, conducteur de travaux...) qui auront certaines propriétés particulières...
Re
Merci pour votre j'ai essayé de faire le diagramme de classe qui répond à mon besoin mais j'ai rencontré un petit problème de modélisation :
Voila quelques informations sur l'application :
- Le commercial affecte les projets aux chefs de projets.
- Le chef de projet affecte les tâches aux équipiers.
- Le chef de projet lui même peut avoir des tâches. // ICI le problème
- Les tâches peuvent avoir des tâches antérieures (des prédécesseurs).
- Tous les membres du projet peuvent participer au projet en :
* Signalant des problèmes.
* Signalant des risques.
* Joindre des documents.
* Déposer des livrables.
Je joins ma conception si vous pouvez me donnez votre avis.
J'espère que vous m'aidez à résoudre le problème mentionné ci dessus .
Merci
Concernant ton problème, tu peux faire hériter ton chef de projet de l'équipier (appelle-le plutôt développeur dans ce cas).
Je n'ai rien à redire sur le diagramme qui est plutôt du niveau analyse et qui met en évidence les abstractions clefs.
_______________
Je te suggère un niveau d'héritage supplémentaire, qui regrouperait les chefs et les équipiers (qui regroupe en fait tous les membres pouvant avoir des taches)
RE
Merci pour votre aide et je voudrais savoir votre avis sur le diagramme de classe, est ce qu'il est bon ?
Je suis en stage de fin d'étude et je dois développer une application de gestion de projet, j'ai consulté plusieurs logiciels open source et propriétaire concernant la gestion des projets et j'ai essayé de dégager les fonctionnalités de base.
J'espère que vous me donner vos idées.
Merci
La relation "Chef ---> Tache" est inutile car elle est accessible grâce à l'héritage.
Compte-tenu de ce qui existe en la matière sur le marché, y compris dans le domaine open-source, c'est étonnant qu'ils te demandent de faire un nouveau produit mais bon, c'est pas le sujet du topic !Envoyé par mimosa803
Re
Je n'ai pas compris pourquoi vous m'avez dit que je dois enlevez la relation Chef Tache, Tache est une classe associative entre un chef de projet et un équipier :
Le commercial crée des projets et les affectes aux chefs.
Le chef de projet crée des tâches et les affectes aux équipiers.
oops pardon, lu trop vite
Ok pas de problème, par contre j'aimerai bien que vous me donnez des suggestions si vous avez des idées sur la gestion des projets.
Merci
Quel est le besoin exprimé par l'entreprise qui t'accueille ?
Il doit y avoir des besoins spécifiques par rapport à ce que savent faire les logiciels du marché sinon je ne comprends toujours pas pourquoi ils te demandent d'en développer un nouveau.
A la limite, s'il s'agit juste d'affecter des tâches à des gens et de les classer par projet, Lotus Notes ou Outlook reliés à un serveur sont suffisants !
Sinon cherche un logiciel de gestion de projet libre et regarde ce qu'il fait, ça te donnera une idée de ce qu'on peut faire mais ça m'étonnerait que tu arrives à développer une appli complète en un temps de stage.
Re
Bon avant de faire le diagramme de classe j'ai étudier les besoins de mon application en consultant plusieurs logiciels libres et propriétaires et j'ai pu dégager les fonctionnalités de bases et ajouter d'autres choses.
L'entreprise d'accueil souhaite vendre mettre mon application dans un package qu'on peut l'installer dans un portail d'une entreprise.
Donc ce n'est pas une application à part donc il sera intégré.
Concernant les besoins je suis entrain de poster un message dans le forum en ajoutant mes cas d'utilisation mais j'ai voulu juste un avis sur le diagramme de classe.
Merci
En fait, il y a déjà pas mal de posts sur le sujet dans ce forum (Hed confirmera, tu pourras y trouver bon nombre d'idées.
Pour ton diagramme, tes classes telles les risques ou les documents me paraissent trop esseulées. Par exemple, le document a un auteur, les risques doivent concerner des tâches et/ou des ressources ...
_______________
Re
Concernant les classe problème, risque, document et livrable sont liées à la classe projet et la classe projet est lié à la classe utilisateur, j'explique :
Tous les utilisateurs dans un projet donné peuvent :
signaler des risques
signaler des problèmes
joindre des documents
déposer des livrable
Si je vais mettre une relation entre problème et utilisateur ...
Je reçoit une boucle donc c'est faux
Ce n'est pas parce que tu as des références croisées dans un modèle qe celui-ci est faux.
Dans le cas présent tu es bien obligé de composer avec. Un projet utilise des ressources, un document est écrit par une (ou plusieurs ressources et il a de même plusieurs destinataires) et un document s'inclut bien dans un projet.
___________
Re
Bonjour, c'est vrai le document doit avoir des utilisateurs qui sont à la fois des emmetteurs et des recepteurs mais à ce moment qu'est ce que vous me proposez comme solution est ce que j'enlève la composition entre utilisateur est projet ?
Merci
Pour le document, je te propose de laisser ton modèle tel quel et d'y rajouter une association dirigée nommée "destinataires" vers plusieurs personnes et de rajouter une seconde association dirigée nommée cette fois auteur vers une (ou des) personne(s).
Pour les risques, ils peuvent concerner des ressources critiques ou des tâches critiques ...
Je te laisse affiner tout ça.
_____________
Ok merci, est ce que vous pouvez jeter un coup d'œil sur mon autre message dans le forum il contient les uses cases de mon application
Beaucoup, je ne sais pas, mais juste la recherche "gestion projet" donne trois sujetsEn fait, il y a déjà pas mal de posts sur le sujet dans ce forum (Hed confirmera
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager