Voici en fichier joins mon diagramme de classe, j'avoue que j'hésite à passer à l'étape suivante vu que je suis novice, si des améliorations peuvent être apportées à ce diagramme, je suis ouvert à toutes suggestions et critiques.
Merci d'avance.
Voici en fichier joins mon diagramme de classe, j'avoue que j'hésite à passer à l'étape suivante vu que je suis novice, si des améliorations peuvent être apportées à ce diagramme, je suis ouvert à toutes suggestions et critiques.
Merci d'avance.
Mettre l'accompte et le montant en int, c'est se priver de gérer les centimes
Sinon, sans les règles de gestion et une explication du contexte, difficile de te dire grand chose...
Attention aussi aux héritages multiples, gages de contraintes fortes.
Merci pour ta réponse.J'ai joins une nouvelle version du diagramme de classe.
voici le contexte de l'application.
un centre de loisir qui propose des activités.
- Une activité se déroule dans un lieu L avec un thème, options et services.
- Une activité se décompose en petites activités avec un timing précis
ex: titre de l'activité "nuit à la belle étoile".
- 18h00 Accueil (Activité 1)
- 18h30 soupé (Act. 2)
- 20h30 Épreuve de tir à l'arc...(Act. 3). Tout cela fait parti d'une offre qui est proposée au client. Ensuite il y a les membres du service commercial (Utilisateur)qui peuvent créer les offres et les proposées aux clients. La où je suis hésitant c'est au sujet du "gestion de profil utilisateur" il y a plusieurs profil (commercial, direction, administrateur) avec un niveau d'accès différent et des actions qui sont associées, pour le moment je n'ai pas su représenter ça. concernant l'héritage multiple, je vais passer par les interfaces pour l'éviter. Si il y a des entités ou des associations qui pourraient disparaître ou être modéliser autrement faites moi des suggestions.
Merci.
Le diagramme de cas d'utilisation est là pour çaEnsuite il y a les membres du service commercial (Utilisateur)qui peuvent créer les offres et les proposées aux clients. La où je suis hésitant c'est au sujet du "gestion de profil utilisateur" il y a plusieurs profil (commercial, direction, administrateur) avec un niveau d'accès différent et des actions qui sont associées, pour le moment je n'ai pas su représenter ça![]()
J'avoue ne pas avoir été satisfait par ta réponse, mais je suppose que le diagramme de classe à première vue ne comporte pas d'erreurs grossières, je vais le valider tel quel et te remercie pour ton aide.
Ce que hed62 t'explique, c'est que pour modéliser quels sont les différents profils, et les différents "droits" d'accès à l'application, la meilleure façon est d'utiliser un diagramme de cas d'utilisations.
Toutefois, il me semble que ta question était plutôt : comment modéliser dans le diagramme de classe le fait que certaines "personnes" sont des utilisateurs et que suivant son "profil", l'utilisateur a des droits différents dans l'application?
C'est bien ça, je me suis peut être mal exprimé, je cherche un moyen de le modéliser dans le diagramme de classe, si tu as une idée, elle sera la bienvenue.
Partager