Discussion :

[kokumbo]

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.

[hed62]

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.

[kokumbo]

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.

[hed62]

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

Le diagramme de cas d'utilisation est là pour ça

[kokumbo]

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.

[montesq]

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?

[kokumbo]

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.

[montesq]

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.

Personnellement, je créerai une classe "utilisateur" héritant de la classe "personne", ayant comme attributs: identifiant, mdp + "profil". Dans ce cas, je pense qu'il faudrait revoir le positionnement des classes "moniteur" et "commercial".
Qu'en penses-tu? Qu'en pensez-vous?

[kokumbo]

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?

[montesq]

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:

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?

/!\ 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...

[kokumbo]

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

[montesq]

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

Ok, mais dans le cas de l'exmple énoncé, il ne faut pas seulement 1 association entre la classe "commercial" et "offre" mais 3:
- une association pour l'envoi
- une association pour l'annulation
- une association pour la réalisation

[kokumbo]

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?

[montesq]

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".