conseils class diagram

PiNkjeLLy · 08/02/2013, 15h36

Bonjour à tous !

Je suis actuellement sur un projet et j'ai a modéliser le futur système
(j'en ai déja parlé ici, et j'ai listé tous mes UC, docmuentés et créé le diagramme UC, qui correspond aux besoins et attentes du futur système (mais peut être pas tout à fait quant à sa formalisation

)

Quoi qu'il en soit, j'en suis à la phase de modélisation des classes, et ça se gatte encore ... Je ne sais pas comment formaliser certaines règles entre certaines classes grrrrr !!

Mais plutôt qu'un autre long discours, la bête en fichier joint.

Merci pour les réponses

ebrosse_fr · 08/02/2013, 16h02

Salut,

Premiére remarque sur ton diagramme, comment l'as tu fait? Cela ressemble plus à un diagramme de BD qu'a un diagramme de classe ce qui est un peu différent...

J'aurais voulu savoir ce qui manque d'après toi?

A+

PiNkjeLLy · 09/02/2013, 13h03

Merci pour la réponse !

Alors pour le diagramme, je l'ai fait avec Visual Paradigm, mais c'est vrai que j'ai du mal à me défaire des DB, du coup je suis pas sure de bien avoir fait le diagramme de classes. En plus, j'ai bcp de mal à formaliser certaines contraintes, je ne sais pas comment les représenter, appart dans une note ...

Une piste pour m'éclairer ?

ebrosse_fr · 09/02/2013, 14h47

En UML il existe un élément "Contrainte" ensuite cela dépend de ce que tu veux modéliser. Peux tu nous en citer? Quelle est la cible de ta modélisation? Car tu fais apparaitre des clés externe (Id d'autres élément), tu modélises donc une BD ou veux tu modéliser une architecture Java ou dans ce cas les clés n'ont pas de raison d'être.

Derek Corgan · 09/02/2013, 15h17

Bonjour,

ton schema ressemble plus à un MPD qu'à un modèle de classe.

Y'a du boulot...

Meme remarque qu'ebrosse concernant les cles externe.
De plus il n'y a aucune cardinalité.

Les méthodes qui sont Affiliation et Message devraient être dans Compte (le compte connait les messages qu'il a émis et ses affiliation)

Message une relation messageEmetteur et messageDestinaire vers le compte...
Affiliation cette classe se justifie par la nécessité de connaitre l'heure...

Sur les titulaires de compte à revoir (une idée un tituliare de compte est soit un admin, une entreprise, un salarié, un gestionnaire) quelle est la différence entre salarié et gestionnaire ?

Avant tout documente toi sur les diagramme de classe avant d'utiliser un outil.

cdt

PiNkjeLLy · 09/02/2013, 18h09

Citation:

Envoyé par ebrosse_fr

Quelle est la cible de ta modélisation? Car tu fais apparaitre des clés externe (Id d'autres élément), tu modélises donc une BD ou veux tu modéliser une architecture Java ou dans ce cas les clés n'ont pas de raison d'être.

En fait je sais pas trop, on m'a demandé de le faire figurer dans mon rapport de stage donc j'essaie (péniblement) de le faire. Dans ma tête, c'est pour "préparer" mon projet et pour ensuite déboucher sur la création de la BD.

Citation:

Envoyé par Derek Corgan

ton schema ressemble plus à un MPD qu'à un modèle de classe.
Y'a du boulot...

Meme remarque qu'ebrosse concernant les cles externe.
De plus il n'y a aucune cardinalité.

Les méthodes qui sont Affiliation et Message devraient être dans Compte (le compte connait les messages qu'il a émis et ses affiliation)

Message une relation messageEmetteur et messageDestinaire vers le compte...
Affiliation cette classe se justifie par la nécessité de connaitre l'heure...

Sur les titulaires de compte à revoir (une idée un tituliare de compte est soit un admin, une entreprise, un salarié, un gestionnaire) quelle est la différence entre salarié et gestionnaire ?

Avant tout documente toi sur les diagramme de classe avant d'utiliser un outil.

cdt

Oui effectivement, je sens bien que ça ressemble plus à un MPD, mais de tout ce que j'ai pu voir des diagrammes de classes, les shémas étaient petits et concis, du coup même après avoir analysé et documenté mes use cases, j'imagine déjà l'aspect général de la BD.

En ce qui concerne Affiliation et Message, j'ai voulu créer des classes indépendantes d'une part pour stocker un historique, et d'autre part pour indiquer certaines contraintes entre les acteurs comme le Client qui a accès seulement aux infos d'une Boutique, une Affiliation peut avoir lieu entre un Client et une Boutique ou 2 Boutiques, un Client n'a pas accès à l'Admin Site, etc ... (que je n'ai pas réussi à modéliser puisque je les ai insérées dans des notes ...)

Bref je suis totalement larguée

Derek Corgan · 09/02/2013, 20h36

Justement avec de l'héritage sur affiliation tu peux gérer cela,

un classe abstraite qui a pour attribut la date affiliation

de cette classe dérive 2 classe concrete
- AffiliationEntreMagasin : cette classe est en relation avec les 2 magasins affilié (le père et fils)
- AffiliationClientMagasin ; cette classe est en relation avec le magasin et le client.

Si l'attribut père est toujours un magasin alors cet attribut peut être dans la classe mère.

PiNkjeLLy · 10/02/2013, 15h55

Citation:

Envoyé par Derek Corgan

- AffiliationEntreMagasin : cette classe est en relation avec les 2 magasins affilié (le père et fils)
- AffiliationClientMagasin ; cette classe est en relation avec le magasin et le client.

donc si je comprend bien, je créé 2 classes affiliation, chacune avec ses propres membres ?

du coup, le principe que j'avais mis en place d'affiliation entre Compte ne servirait plus ?

ou alors je confond totalement, ça sera une contrainte que j'aurai à mettre en place sur la DB, là je me fiche des contraintes je modélise seulement les cas "réels" entre les acteurs ?

PiNkjeLLy · 11/02/2013, 14h11

Bonjour !

Ce lundi étant un nouveau jour, j'ai apporté quelques modifs à mon diagramme.
Des avis ?

Merci pour les réponses

Derek Corgan · 13/02/2013, 20h46

C'est mieux :
- client/employé gestionnaire etc dérivent ce compte. A priori ce dernier est une classe abstraite.

- Affiliation cardinalité copier /coller de message.
- un Message a émetteur et un (seul?) destinataire. OK. Il n'est pas nécessaire de préciser IdCompteEmetteur/IdCompteDestinatoire (ce n'est pas un MDP!)
- Cardinalité message émis/recu par compte manque (0..n, 1..n ?)
- les méthodes getAllMessage doivent être dans le compte. (cela doit faire unCompte.getAllMessageRecu() et unCompte.getAllMessageEmis();

- Centre d'intéret : je lis un centre intérêt a un seul client, un client à plusieurs CI. Pas de CI partagés ? (relation 1..n)

...
Je te laisse pour le reste.

PiNkjeLLy · 14/02/2013, 16h56

Merci Derek pour la réponse

Je bosse encore dessus, j'ai fait bcp de modifs et j'en ai encore à faire ...
Je poste la V2893 (bon j'en ai peut être pas fait autant, mais pas loin quand même) dès que je pense l'avoir terminé

08/02/2013, 16h02	#2
ebrosse_fr Membre habitué Inscription : octobre 2007 Messages : 68 Détails du profil Informations forums : Inscription : octobre 2007 Messages : 68 Points : 100 Points : 100	Salut, Premiére remarque sur ton diagramme, comment l'as tu fait? Cela ressemble plus à un diagramme de BD qu'a un diagramme de classe ce qui est un peu différent... J'aurais voulu savoir ce qui manque d'après toi? A+
	00

09/02/2013, 13h03	#3
PiNkjeLLy Inscription : septembre 2012 Messages : 24 Détails du profil Informations personnelles : Sexe : Localisation : France, Corrèze (Limousin) Informations forums : Inscription : septembre 2012 Messages : 24 Points : -1 Points : -1	Merci pour la réponse ! Alors pour le diagramme, je l'ai fait avec Visual Paradigm, mais c'est vrai que j'ai du mal à me défaire des DB, du coup je suis pas sure de bien avoir fait le diagramme de classes. En plus, j'ai bcp de mal à formaliser certaines contraintes, je ne sais pas comment les représenter, appart dans une note ... Une piste pour m'éclairer ?
	00

09/02/2013, 14h47	#4
ebrosse_fr Membre habitué Inscription : octobre 2007 Messages : 68 Détails du profil Informations forums : Inscription : octobre 2007 Messages : 68 Points : 100 Points : 100	En UML il existe un élément "Contrainte" ensuite cela dépend de ce que tu veux modéliser. Peux tu nous en citer? Quelle est la cible de ta modélisation? Car tu fais apparaitre des clés externe (Id d'autres élément), tu modélises donc une BD ou veux tu modéliser une architecture Java ou dans ce cas les clés n'ont pas de raison d'être.
	00

09/02/2013, 15h17	#5
Derek Corgan Membre confirmé Inscription : août 2009 Messages : 84 Détails du profil Informations personnelles : Sexe : Localisation : France, Loire Atlantique (Pays de la Loire) Informations forums : Inscription : août 2009 Messages : 84 Points : 222 Points : 222	Bonjour, ton schema ressemble plus à un MPD qu'à un modèle de classe. Y'a du boulot... Meme remarque qu'ebrosse concernant les cles externe. De plus il n'y a aucune cardinalité. Les méthodes qui sont Affiliation et Message devraient être dans Compte (le compte connait les messages qu'il a émis et ses affiliation) Message une relation messageEmetteur et messageDestinaire vers le compte... Affiliation cette classe se justifie par la nécessité de connaitre l'heure... Sur les titulaires de compte à revoir (une idée un tituliare de compte est soit un admin, une entreprise, un salarié, un gestionnaire) quelle est la différence entre salarié et gestionnaire ? Avant tout documente toi sur les diagramme de classe avant d'utiliser un outil. cdt
	00

09/02/2013, 20h36	#7
Derek Corgan Membre confirmé Inscription : août 2009 Messages : 84 Détails du profil Informations personnelles : Sexe : Localisation : France, Loire Atlantique (Pays de la Loire) Informations forums : Inscription : août 2009 Messages : 84 Points : 222 Points : 222	Justement avec de l'héritage sur affiliation tu peux gérer cela, un classe abstraite qui a pour attribut la date affiliation de cette classe dérive 2 classe concrete - AffiliationEntreMagasin : cette classe est en relation avec les 2 magasins affilié (le père et fils) - AffiliationClientMagasin ; cette classe est en relation avec le magasin et le client. Si l'attribut père est toujours un magasin alors cet attribut peut être dans la classe mère.
	00

13/02/2013, 20h46	#10
Derek Corgan Membre confirmé Inscription : août 2009 Messages : 84 Détails du profil Informations personnelles : Sexe : Localisation : France, Loire Atlantique (Pays de la Loire) Informations forums : Inscription : août 2009 Messages : 84 Points : 222 Points : 222	C'est mieux : - client/employé gestionnaire etc dérivent ce compte. A priori ce dernier est une classe abstraite. - Affiliation cardinalité copier /coller de message. - un Message a émetteur et un (seul?) destinataire. OK. Il n'est pas nécessaire de préciser IdCompteEmetteur/IdCompteDestinatoire (ce n'est pas un MDP!) - Cardinalité message émis/recu par compte manque (0..n, 1..n ?) - les méthodes getAllMessage doivent être dans le compte. (cela doit faire unCompte.getAllMessageRecu() et unCompte.getAllMessageEmis(); - Centre d'intéret : je lis un centre intérêt a un seul client, un client à plusieurs CI. Pas de CI partagés ? (relation 1..n) ... Je te laisse pour le reste.
	00

14/02/2013, 16h56	#11
PiNkjeLLy Inscription : septembre 2012 Messages : 24 Détails du profil Informations personnelles : Sexe : Localisation : France, Corrèze (Limousin) Informations forums : Inscription : septembre 2012 Messages : 24 Points : -1 Points : -1	Merci Derek pour la réponse Je bosse encore dessus, j'ai fait bcp de modifs et j'en ai encore à faire ... Je poste la V2893 (bon j'en ai peut être pas fait autant, mais pas loin quand même) dès que je pense l'avoir terminé
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email