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.
Dans les cas d'utilisation, il y a 3 types d'utilisateur (commercial, administrateur, directeur), l'administrateur peut créer un utilisateur ou le changer de type c'est dire passer de commercial à directeur. le commercial peut réaliser, annuler, et envoyer une offre. le directeur peut valider les offres. créer une classe utilisateur et faire hériter ces trois utilisateurs et les associés un à un à différents objets, n'est ce pas la bonne manière de gérer les profils des utilisateurs?
Tu peux regarder ce document qui devrait t'apporter des renseignements sur la façon de modéliser la gestion des droits en UML.
Pour en revenir à ta réponse:
/!\ d'après ce que je comprends de ton raisonnement (et j'espère me tromper), tu dis "le commercial peut réaliser, annuler, et envoyer une offre" alors c'est pour cette raison que tu modélises une association entre la classe "commercial" et la classe "offre".
En fait j'ai l'impression -comme l'a fait remarquer hed62- que tu essayes de modéliser dans ton diagramme des classes des éléments qui doivent être présentés dans le diagramme des cas d'utilisations...
Si ces associations apparaissent dans le diagramme de classe c'est parce qu'elles doivent être sauvegarder. Si on veut savoir qu'elle commercial à envoyer, annuler ou réaliser, une offre il faut que cette association apparaisse dans le diagramme de classe
Pour les 3 associations dans le nouveau diagramme qui est joins à ce message c'est déjà fait. Par contre les classes commercial, directeur qui hérite de utilisateur n'appairassent que parce qu'elles sont associées à la classe offre. comment dois-je faire si je veux lister les administrateurs du système? dois-je créer une classe administrateur qui hérite de la classe utilisateur même si cette classe n'apporte rien au modèle?
Le problème est le même que pour les classes "commercial" et "directeur". Ces classes n'ont pas d'attributs...
Pour moi ces classes n'ont pas lieu d'être (voir document donné en référence précédemment). Un commercial est un utilisateur lié à un "profil"/"rôle" "commercial".
Pour lister les administrateurs systèmes, il te suffira de chercher tous les utilisateurs ayant un profil "administrateur système".
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.
Partager