Discussion :

[damdam2017]

bonjour,

j'ai fais ce diagramme de classe mais j'ai besoin de visualiser les disponibilités de chaque salle et je pense qu'il me manque une salle disponibilité ou calendrier.

quelqu'un peut 'il me confirmer cela et me donner des exemples d'attributs que doit contenir ma classe.

j'ai besoin qu'au moment de la demande de reservation, sur le calendrier apparaisse la disponibilité en vert pour la salle sélectionné et en rouge lorsque la salle n'est pas disponible.

merci par avance pour votre aide.

[escartefigue]

Bonjour damdam2017

Si vous consultez les autres sujets de ce forum, vous constaterez que sempiternellement, nous réclamons les règles de gestion qui justifient le MCD.
Voyez par exemple ICI comment rédiger ces règles.

Ensuite, les attributs à positionner dans chaque classe dépendent du besoin. Si on a besoin de connaitre la date de naissance des utilisateurs, il faut l'ajouter, sinon, il est inutile de s'en encombrer.


Concernant les différents types d'utilisateurs

Il est rarement utile d'avoir un identifiant pour chaque sous-type. Si le sous-type n'a pas d'identifiant propre, il hérite alors de celui du sur-type. Par ailleurs, tel que modélisé, tous les utilisateurs sont des personnes physiques, puisque tous ont un nom et un prénom. Or, on voit qu'il existe un sous-type "association" pour lequel ces attributs n'ont pas de sens et un sous-type "professionnels" pour lequel ces attributs n'ont de sens que pour les auto entrepreneurs. Si vous devez gérer des personnes physiques et des personnes morales, il faut positionner les attributs dans les sous-types pertinents.
Vous trouverez ICI un exemple d'héritage avec des personnes physiques et morales sans identifiant propre à chaque sous-type.


Concernant les réservations

Vous trouverez ICI un sujet qui concerne des réservations de chambres d'hotel et LA un sujet qui concerne des réservations de salles et de véhicules.


Concernant les salles

Possiblement, certains équipements sont fixes, d'autres peuvent changer de salle (ex : tel rétroprojecteur peut être affecté à telle salle puis à telle autre).
C'est pourquoi il est préférable de créer une entité-type (classe d'entité) "équipement" et de créer une association à date entre "équipement" et "salle"

La disponibilité de la salle, s'il s'agit de savoir si elle est réservée ou pas, est une redondance avec l'association "réserver". Il faut donc supprimer cet attribut. Pour savoir si une salle est disponible, il suffira, par requête, de vérifier qu'il n'existe pas d'occurrence de "réservation" pour la période considérée et la salle.


À propos de ceci :

j'ai fais ce diagramme de classe mais j'ai besoin de visualiser les disponibilités de chaque salle et je pense qu'il me manque une salle disponibilité ou calendrier.

Il ne s'agit pas en l'occurrence d'un diagramme de classe, mais d'un modèle Merise. Cela étant dit, vu qu'il a visiblement été réalisé avec Looping, passer d'un formalisme à l'autre se fait en un clic


Et à propos de ceci :

j'ai besoin qu'au moment de la demande de reservation, sur le calendrier apparaisse la disponibilité en vert pour la salle sélectionné et en rouge lorsque la salle n'est pas disponible.

À partir du moment où le modèle de données permet de faire des requêtes fiables et performantes, ceci est du ressort du traitement et donc hors de propos dans ce forum.
Chaque chose en son temps, il faut déjà fiabiliser le modèles de données