Aide conception uml
mony
-
flouartistik -
flouartistik -
Bonjour,
je dois faire la conception pour la gestion des entretiens au sien d'une société ,mon problème se situe a ce niveau:
j'ai fait 2 classes candidat et entretien et une autre classe association nomé candidatSelectionee (aprés entretien)alors que les deux classe candidat et candidatSelectionne ont les memes attributs ,je sais pa est-ce correcte? sinon que pouvez vous me proposer comme solution.
Svp de me donner vos avis concernant cette conception.
merci de votre aide
je dois faire la conception pour la gestion des entretiens au sien d'une société ,mon problème se situe a ce niveau:
j'ai fait 2 classes candidat et entretien et une autre classe association nomé candidatSelectionee (aprés entretien)alors que les deux classe candidat et candidatSelectionne ont les memes attributs ,je sais pa est-ce correcte? sinon que pouvez vous me proposer comme solution.
Svp de me donner vos avis concernant cette conception.
merci de votre aide
A voir également:
- Aide conception uml
- Dia uml - Télécharger - Dessin & Illustration
- Logiciel conception maison - Guide
- Logiciel de conception gratuit - Guide
- Sweet Home 3D - Télécharger - Architecture & Déco
- Idée de conception powerpoint n'apparait pas - Forum Powerpoint
2 réponses
Par principe, un candidat peut avoir plusieurs entretiens avant d'être choisi.
Tu te retrouve avec une association de ce style :
Candidat (1) ---------- (*) Entretien
Les classes associations sont utilisés dans les cas de relation (*-*) du coup ce n'est pas nécessaire dans ton cas.
Tu peux directement ajouter un attribut "status" par exemple dans ta classe candidat ou tu mettra des valeurs comme ("en attente d'entretien", "retenu" ou "non retenu")
Après si tu dois gérer des entretiens avec plusieurs candidats dans le même entretien, ta relation deviens (*-*) et tu es obligé de créer ta classe association pour sauver toutes les données.
Tu te retrouve avec une association de ce style :
Candidat (1) ---------- (*) Entretien
Les classes associations sont utilisés dans les cas de relation (*-*) du coup ce n'est pas nécessaire dans ton cas.
Tu peux directement ajouter un attribut "status" par exemple dans ta classe candidat ou tu mettra des valeurs comme ("en attente d'entretien", "retenu" ou "non retenu")
Après si tu dois gérer des entretiens avec plusieurs candidats dans le même entretien, ta relation deviens (*-*) et tu es obligé de créer ta classe association pour sauver toutes les données.
merci flouartistik
effectivement en principe un candidat peut passer plus d'un entretien , si j'ajoute un attribut statu dans ma classe candidat si je veux savoir si un candidat est séléctionné je dois faire un traitement a chaque fois( controle de champ statut) mais moi je veux faire de la sorte que si un candidat pass 1 entretien et y réussi je le retrouve directement dans une autre classe candidatSelectionnee :-)
j'ai pensé donc de faire 3 classes déja cités tt indépendante(pas de class associations) et de faire 3 associations aussi ( 1..*-*) pr candidat et entretien ,(1-0..1) pr candidat et candidatSelectionné et(1..0-1) pr entertien et candidaSelectionné
qu'il ton avis pour cette nouvelle solution?
merci de ton aide
effectivement en principe un candidat peut passer plus d'un entretien , si j'ajoute un attribut statu dans ma classe candidat si je veux savoir si un candidat est séléctionné je dois faire un traitement a chaque fois( controle de champ statut) mais moi je veux faire de la sorte que si un candidat pass 1 entretien et y réussi je le retrouve directement dans une autre classe candidatSelectionnee :-)
j'ai pensé donc de faire 3 classes déja cités tt indépendante(pas de class associations) et de faire 3 associations aussi ( 1..*-*) pr candidat et entretien ,(1-0..1) pr candidat et candidatSelectionné et(1..0-1) pr entertien et candidaSelectionné
qu'il ton avis pour cette nouvelle solution?
merci de ton aide
Ton architecture permet de gérer à la fois les entretiens pour 1 candidat et pour plusieurs candidats.
La classe candidat sélectionné est forcement une classe association car elle fait référence à l'ID de ton candidat et l'ID de ton entretien.
Moi je ferais plutot mon champs status (oui il est chiant ce champs) parce que ça évite de créer et supprimé un objet à chaque entretien.
En plus si le candidat est reçu au premier entretien mais aussi au second, tu vas créer 2 objets différents? Pour pas plutôt faire un champs status enum avec recu premier entretien et recu deuxième entretien.
Du coup tu pourrai avoir le visibilité que tu veux avec un architecture et une maintenabilité assez simple.
Sur ce bon appétit lol
La classe candidat sélectionné est forcement une classe association car elle fait référence à l'ID de ton candidat et l'ID de ton entretien.
Moi je ferais plutot mon champs status (oui il est chiant ce champs) parce que ça évite de créer et supprimé un objet à chaque entretien.
En plus si le candidat est reçu au premier entretien mais aussi au second, tu vas créer 2 objets différents? Pour pas plutôt faire un champs status enum avec recu premier entretien et recu deuxième entretien.
Du coup tu pourrai avoir le visibilité que tu veux avec un architecture et une maintenabilité assez simple.
Sur ce bon appétit lol
